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.

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.

This serves as a master list of all other snapshot-like features on our roadmap. The scope of this ticket is potentially very large and ambiguous so we've broken this down into smaller tickets that you can follow separately. (Historical only) https://roadmap.databento.com/b/n0o5prm6/feature-ideas/add-historical-endpoint-for-latest-snapshot-of-any-schema. This would allow a user to get the latest published value of any given schema, within the boundaries allowed by licensing/entitlements/historical embargo window. The main benefit of this is for creating ticker tape or latest quote features, e.g. on a web app, after we start exposing intraday data over the historical/HTTP API (https://roadmap.databento.com/roadmap/expose-intraday-and-current-trading-session-historical-data-over-historical-http-api-and-clients). Likely endpoint names for this would be either timeseries.get_last or timeseries.get_snapshot. (Historical only) https://roadmap.databento.com/b/n0o5prm6/feature-ideas/provide-snapshots-as-of-specified-time-in-historical-api. Likely endpoint names for this would be either timeseries.get_last or timeseries.get_snapshot.(Live only) https://roadmap.databento.com/roadmap/add-periodic-mbo-book-snapshots-to-live-api. This allows a user to get the last published value of any given schema at a specified time. The main benefit of this would be to allow customers to subsample the data on server side and reduce cost, though the benefit is diminished with feature 5 on this list. Note that this would allow a user to emulate (1) relatively well since a user could potentially just pass in their current clock time or some time slightly ahead of the clock time. However, their underlying implementations would be different and (1) and (2) would likely be released separately. Likely endpoint names for this would be either timeseries.get_last_asof or `timeseries. (Live only) https://roadmap.databento.com/b/n0o5prm6/feature-ideas/allow-live-api-clients-to-request-for-mbo-snapshot-recovery. This provides resilience to gaps or data errors originating from Databento side. It could also be used for recovery of book state caused by client-side issues or disconnection, but would be less quick than feature (4) on this list.(Both historical and live) https://roadmap.databento.com/roadmap/fixed-interval-mbp-1-summaries-eg-1-minute-bbo-or-subsampled-bbo. The purpose of this is more to provide customers a convenience over fetching or subscribing MBP-1 and subsampling and forward filling the MBP-1 data themselves, which could be very expensive given the size of MBP-1 data and how the customer has no idea how far to look back for the "last" MBP-1 update prior to the 1 second or 1 minute refresh interval. Some of these are in development, hence the status of this entire ticket, however you should check on each individual one in case the specific feature you're looking for is still in Considering state.

Make our historical and live APIs easier to integrate from Java.

Only regular trading hours are supported currently.

At the moment, options data users have to rely on fetching the definition schema and filtering for symbols that they're interested in using fields like expiration, asset, underlying_product, instrument_class, group, and strike_price. It would be convenient to fetch the options or options chains with particular conditions on expiration and strike price without going through the definition schema. This would be similar to smart symbology for futures. Note that even after this feature is released, we still recommend users to use definition as it gives more control and transparency over the symbology resolution.

National Stock Exchange (NSE) and Bombay Stock Exchange (BSE) data.

Australian Stocks with ASX and CBOE trades

This request is to make the API documentation available for download so it can be referenced offline.

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.

Exchange fees, e.g. clearing, rebates, etc. (e.g. for CME Group and Eurex) Also in parallel, a similar dataset that's useful would be historical borrow costs.

Especially for US equities trading activity during non-US hours.

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

The current guide (https://databento.com/docs/architecture/performance-optimization) was written pre-launch and now best practices have drifted a bit.