Product roadmap

Historical and live market news.

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.

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.

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

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

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.

Australian Stocks with ASX and CBOE trades

Real-time and historical FINRA TRACE data. Keywords: Real-time bond market transaction data, fixed income, asset-backed (ABS) and mortgage-backed securities (MBS), U.S. Treasury securities, U.S. Treasury notes, corporate bonds.

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.

This request is to capture all requests for AI skills and tools (i.e Claude skills) related to Databento's APIs.

As described in this issue ticket (https://issues.databento.com/b/6vrl98vl/feature-ideas/incorrect-scaling-of-strike-price-in-definition-schema-for-some-cme-options), CME has inconsistent rules on strike price scaling that varies with product group. There is no systematic way to correct for this and adjustments must be made by hand - this is a faulty issue with CME's own security definition data. Most options trading firms maintain a table of these adjustment/display factors by hand. We decided to make this adjustment under the hood to known products affected by this, so that most of our customers who do not have their own internal adjustment table or are unaware of this underlying CME behavior will not be impacted by this issue. As a downside however, it can be counterproductive for more sophisticated firms that do have their own adjustment/display factors and need to know which strike prices have been adjusted by Databento. At the moment, it appears that the best possible follow-on solution is to provide a separate table of the adjustment/display factors applied by Databento, so firms can revert the data back to the original data.