Product roadmap

Adding support for the CBOE Complex Options Order Feed, which provides detailed insights into complex order activity across CBOE markets. This includes multi-leg strategy orders, spread data, and intricate order types that are vital for understanding advanced options trading strategies. Key Features: -Real-time and historical data on multi-leg orders. -Visibility into pricing and execution of complex options strategies. -Detailed breakdowns of spread and combination order flows.

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.

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)

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).

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.

e.g. for S&P 500.

futures and futures options OHLC, OI and volume from the LME

From EEX CEF Core feed EEX EOBI feed. This will include order-by-order data as well as less granular formats, such daily settlements, definitions, etc.

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

Currently our ICE Futures Europe coverage only includes commodities and not financial products like Euribor, as stated here. This ticket separately tracks a future dataset that includes the financial products. ICE Futures Europe financial products include: STIRSFTSE 100London Stock OptionsBond DerivativesEuriborSwapnoteEuroswissLong GiltMedium GiltShort GiltSOFRSONIA

Right now you can go from DBN to Pandas dataframe but not the other way around. I want to merge 2 datasets and save it as a DBN file.

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!

An email notification when user spends past the free credit amount.