Product roadmap

Support Parquet as a form of encoding, aside from dbn, CSV and JSON.

The Intraday Open-Close dataset classifies every options trade across Cboe exchanges by participant, side, position, and size, delivering intraday (1-minute or 10-minute) volume analytics to track market behavior and positioning.

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)

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

To extend support to browser-based applications.

It might be possible to obtain CME trading session hours systematically in historical captures of the instrument definition messages, as embedded in tag-1682=MDSecurityTradingStatus. This ties to another proposed feature here.

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

Stocks and derivatives data from the Singapore Exchange (SGX)

Brazil Equities and Futures MBO data.

Could we add support to make the result of DBNStore.to_df a Polars dataframe as well? Perhaps the function signature could just be overloaded with a to_polars: bool argument. Something like: In Python @overload def to_df(self, to_polars: Literal[False]) -> pd.DataFrame: ... @overload def to_df(self, to_polars: Literal[True]) -> pl.DataFrame: ... Or, maybe to_df is split into two different functions to_pandas and to_polars. Either way, it would be helpful to avoid having to do pl.from_pandas(store.to_df().reset_index(drop=False)). Plus, Polars can convert to pyarrow-Pandas zero-copy, but not the other way around.

Our continuous contract symbology does not behave the same as continuous contracts provided on retail charting apps, which create a continuous series by applying a constant offset on each rollover month to the lead month contract. Our philosophy is generally to provide raw prices because: (a) adjustments are opaque and may introduce vendor errors, (b) this gives you flexibility to do your own custom rollover adjustments, (c) the adjusted prices will throw off certain feature/signal calculations, (d) in practice you can't hold an instrument through the roll anyway, so adjusted prices may underestimate slippage that you'll experience from crossing the spread on the legs or the listed spread. (e) there's no single rollover rule that we expect to be preferred by all customers for all symbols, e.g. rollover rule for a symbol with term structure like SR3 or a physical commodity with seasonality and more than the common quarterly expiration schedule. However, we may consider providing something like this either: a) as a convenience feature to support legacy use cases that require adjusted continuous contracts b) as a code example to show how the user can compute the appropriate price adjustment themselves

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.

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

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.

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