Product roadmap

Historical and live market news.

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.

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). Keywords: Market calendar, trading holidays.

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.

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.

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.

Documentation for how to use the the order book from MBO data for visualizing the evolution of limit order book over time as heatmap. For instance every 10 seconds a snapshoot of the order book of historical 6E futures data is taken. Now a heatmap (exp.: Seaborn) is generated, showing price levels on y axis and timeincrements of 10 seconds on the x axis. The color intensity of the boxes depends on the size of the limitorders. Maybe this idea is an good example for implementing the heatmap with json, d3, ...

Australian Stocks with ASX and CBOE trades

For our live data, Databento plans on supporting two transport layers ("Raw" TCP, WebSocket) and two data encodings (DBN, JSON). This idea is for supporting a gRPC API for consuming live data. This would require both a new transport layer (gRPC-flavored HTTP/2) and a new data encoding option (Protocol Buffers).

The Eurex dataset (XEUR.EOBI) has availability from 2025-03-10. This request is to backfill this dataset with more history. A source of this history has not been identified, we will update this ticket when/if it is accepted with details.

Please expose the following additional option data in the instrument definitions schema. This is essential for accurate backtesting. Trade cut-off and Settlement anchor times: These aren't quite the same as contract expiry. Given these are venue and contract specific, having these would help capture if it's AM or PM settled, while also providing the exact time a backtest should use to stop trading the contract, as well as allowing it to use the correct underlying price when simulating settlement; for example some options may use 4:00 PM ET close as the settlement anchor even if trading continues until 4:15 PM ET, while others stop trading on the prior day and use the official opening prices on expiration morning. There is already an open roadmap item for trading calendars: https://roadmap.databento.com/b/n0o5prm6/feature-ideas/trading-calendar-information But this is specific to the instrument. There is already an open roadmap item for contract family tagging: https://roadmap.databento.com/b/n0o5prm6/feature-ideas/tag-options-contracts-as-weekly-monday-tuesday-etc-monthly-eom-quarterly-in-instrument-defs But that by itself wouldn't provide exact trade cut-off and settlement anchor times. Exercise style: American vs European. This cannot be determined accurately/deterministically from symbology alone. Contract class: Ordinary listed vs FLEX. If FLEX messages are added to OPRA (as per https://roadmap.databento.com/b/n0o5prm6/feature-ideas/add-support-for-opra-flex-messages), then this would be useful to distinguish. I'm not sure where this fits best in the schema. security_type seems inappropriate, and instrument_class also seems inappropriate, since Call and Put already exist and these new attributes need to coexist alongside them. So perhaps this belongs either: a) in a new option-specific subtype/metadata section, or b) as direct fields in the instrument definition itself.

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

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