Product roadmap

Currently, equities is supported via individual prop feeds of each venue. While NASDAQ is sufficient for getting NBBO for most of the time, some users prefer something that will be more in line with actual NBBO from SIPs. This feature request tracks 3 possible modes of consolidation for both historical and live data: Databento server-side consolidation of multiple proprietary feeds Consolidated data from proprietary feed like Nasdaq Basic in lieu of SIP Consolidated data from CTA/UTP SIPs We plan on implementing 1-2 of these three options.

Historical and live market news.

It can be inferred based on a delayed subscription ack, but it would be nice to have an explicit indication when the subscription rate limit has been hit.

Currently, indices are indirectly supported through tradable index instruments on CME futures, ETFs, etc. and we don't provide the index values (non-tradable) themselves. This may be sourced from a feed like the Cboe Global Indices Feed or NYSE Global Index Feed.

To extend support to browser-based applications.

Currently, multi-leg products (spreads, strategies, combos) on CME/ICE are hard to use because our instrument definitions do not provide metadata about each underlying leg. The user has to infer the legs from the symbol. This is a form of lossy normalization, since CME/ICE does provide this in their security definitions in a repeating group, but our fixed instrument definition schemas are forced to discard this—they only provide the the instrument_id of the first underlying instrument through underlying_id. In the meantime, our recommendation to users is to either infer this from the symbol OR download the raw security/instrument definitions from the exchange (e.g. CME's is free on their FTP) OR get a pcap subscription from us. If you need historical secdefs copied from CME (since their FTP site only gives 1 day history), we can provide a courtesy backfill of these for a fixed cost.

Original request from Juan Linares: "Great product but please add dark mode." There are two separate parts to this: Dark mode for the portal and main website (databento.com, databento.com/portal) Dark mode for the docs We can consider this only after Q1 2025 since we're doing a major rebranding of our website which is expected to finish by early April 2025. The new colors will make it easier for us to implement a dark mode.

Data for: Copenhagen Stock Exchange (Nasdaq Copenhagen) Stockholm Stock Exchange (Nasdaq Stockholm) Helsinki Stock Exchange (Nasdaq Helsinki) Iceland Stock Exchange (Nasdaq Iceland) Tallinn Stock Exchange (Nasdaq Baltic) Riga Stock Exchange (Nasdaq Baltic) Vilnius Stock Exchange (Nasdaq Baltic)

It would be great if Japan Exchange Group (Nikkei 225, etc) could be supported. CME Nikkei 225 volume is too low.

Stocks and derivatives data from the Singapore Exchange (SGX)

Hi there! Ive only been working with your service a short time, but im already commited to your platform. Python is a GREAT general purpose language. But I think i am justified when I say that for certain use cases, a "compile to native binary" language like Go is superior for the speed and simplicity (no package dependencies to manage, easier to build out dockerized/container applications) Justification: While there are other compile to native languages (RUST, Haskell, an Elixir i have heard of), Go has a significantly higher developer community. Its will be alot easier to crowdsource for bug, QA, enhancements and fuel adoption...I believe only the bareminimum functionality should be "made official" from you guys. While i think there are some things that should be made simpler than what you provide in your Databento Python SDK, I believe its more important to keep a consistant "bare bones functionality" across all your SDK offerings for accessing your core datasets GO (if you werent aware) allows exposing packages/modules that Python can consume. So you should (in theory) be able to design a top level/ 1 to many code base that can be re-purposed for python (and any other languages) ....Instead of maintaining 2 SDK's... you maintain the one... and port to the other via package exposure)...attached a screenshot (While you provide a pip install package, this approach would allow also make it easier for you to push to other package managers like homebrew, nuget, NPM....without having to refactor and maintain code bases for multiple languages.. Im a long time Go developer... So i 120% would like to volunteer to assist with development and design efforts. Ive already done quite a bit on my own project that I believe others would find useful ( I believe you'd also benefit from having an end user and consumer, aid in designing the final consumer product(s)... You know what they say about starship designers, never actually getting to go into space LOL) Long story short, an official Go SDK would offer "Minimal effort, maximum coverage" and enhanced scalability Thanks in advance!

Follow-up on the frozen job (request 2026-05-25 05:09 PM, OG.OPT + VXN.FUT, Trades): I selected the "Trades" schema by mistake — that is far heavier than I actually need, and the job has been frozen at "Processing — 37%" for hours and has delivered nothing usable. Please: Cancel this job.Ensure it is NOT billed — it produced no delivered data; this was a mis-selected schema on my part, not a completed download. I'm an existing paying customer and I'm resubmitting the correct, lighter request (GLBX.MDP3, ohlcv-1d, OG.OPT) for my real need. I'd appreciate this stuck Trades job being handled as a no-charge correction. Thank you. Subject: Batch job frozen at 37% — request 2026-05-25 05:09 PM (GLBX.MDP3, OG.OPT + VXN.FUT, Trades) Hello, One of my batch jobs is frozen and I need it fixed. Job details: Request time: 2026-05-25 05:09 PM (portal time)Job ID: [INSERT — click the request row in the Download Center]Account email: [INSERT your portal email]Dataset: CME Globex MDP 3.0 (GLBX.MDP3)Schema: TradesSymbols: OG.OPT, VXN.FUTDate range: 2010-06-06 → 2026-05-25 (5832 days)Encoding: DBN | Delivery: Direct download Problem: the job has been stuck at "Processing — 37%" for ~[X] hours and the percentage is NOT advancing. This is a small, low-cost request (Trades schema, two parent symbols), so the stall is not explained by data volume — it looks like a processing fault on your side. For reference: other batch jobs from the same account completed normally (Status: Ready), so it is not an account or connectivity issue — it is specific to this job. Please: Investigate why this job is frozen at 37%.Re-queue / restart it (or tell me how to cancel and re-submit cleanly).Give a concrete ETA. This is blocking my work and a job this size should not take this long. Thanks for a quick fix. Dataset: GLBX.MDP3 (CME Globex MDP 3.0) Schema: ohlcv-1d ← дневные бары, НЕ trades (вот в чём разница) Symbols: OG.OPT (опционы на золото — для metal-IV гейта) stype_in: parent Date range: 2010-06-06 → 2026-05-25 Encoding: CSV (compression: zstd) Delivery: Direct download

The provision of an account-wide notification when a user is exceeding rate limits to the extent that the entire team will be restricted.

This feature would allow the user to request trading calendar information (such as trading session start/end times) via our API. This is especially useful when considering trading sessions that can span multiple UTC dates (and hence the possibility of having multiple trading sessions within a single day). Keywords: Market calendar, trading holidays.

All orders plus last look quotes from 35 major banks and non-bank LPs, on one of the largest FX venues.