Product roadmap

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.

Hi, is there any chance that we will see Euronext paris futures expansion (CAC40, Milling Wheat, Corn, Rapeseed ... futures) thanks

Data for Eurex, including all schemas (MBO, MBP, ohlcv, etc.).

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.

To extend support to browser-based applications.

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

Support AWS S3 as an additional method of delivery, aside from HTTP and FTP.

B3: Brazil Equities and Futures MBO data. Keywords for search purposes: Brasil Bolsa Balcão S.A., Brazilian Mercantile and Futures Exchange (BM&F), BMF, Bovespa (São Paulo Stock Exchange), Cetip (Central of Custody and Financial Settlement of Securities for the organized OTC market).

Hello, I'd really like high quality equities data for european exchanges like xetra, so I created this feature request. Maybe others are interested in that as well. Even EOD would be nice as a start. Kind regards,

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!

The legacy live usage-based plans allowed users to access L2/L3 data. However L2/L3 were pulled from the Standard plan. One possibility to increase the value of the Standard plan is to offer limited access to L2/L3, perhaps gated by a quota on symbol subscriptions per account, etc.

Request for supporting Japanese market data. Tokyo Stock Exchange (TSE)

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.

Full depth of book feed for Cboe Futures Exchange (CFE). CFE contains volatility futures and corporate bond index futures, such as VIX futures (VX, VXM).

e.g. for S&P 500.