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.

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.

Only regular trading hours are supported currently.

Add trade reporting modifier flags, e.g. those found in CTS sale conditions here: https://www.nyse.com/publicdocs/ctaplan/notifications/trader-update/cts_output_spec.pdf Similar to: https://roadmap.databento.com/b/n0o5prm6/feature-ideas/include-opra-trade-conditions

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.

Historical and live market news.

A schema to encompass useful EOD information in various forms. Currently, users have to extract EOD prices from ohlcv-1d. However, this is aligned to UTC midnight. Users who want EOD data based on session end or other specific conventions, e.g. 3:45 PM ET (to avoid auction) have to extract this from ohlcv-1h or ohlcv-1m data. This could be provided either in the form of a new endpoint, new schema (e.g. 'ohlcv-eod' or 'eod'), or more session/market calendar functionality.

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.

Currently, our API uses UTC time for all trading venues. So for example, the open price of ohlcv-1d for a given date, say start='2022-09-12', will be 2022-09-12T00:00+0 for two different venues in two different timezones (e.g. NASDAQ, LSE). There are advantages to this approach: This is useful for synchronizing time series across multiple venues, e.g. for a global equities portfolio. It's easier for programmatic timezone conversions. The time parameters are always in 1 timezone and consistently unaffected by daylight savings; it's generally easier to map from UTC to any preferred timezone. Downsides: This is inconvenient for users who are only trading 1 venue. This is inconvenient for users who just want to do a quick manual lookup; have an exploratory Excel workflow; or have a charting use case. For example, most people know off the top of their head that 09:30 ET is the start of regular trading hours on NASDAQ, but they might not know what that time is in UTC. It is tricky to map from opening/closing prices in UTC 00:00 day to opening/closing auction price. On some venues, opening/closing auctions may be extended and don't always align with a fixed time. Moreover, most trading venues don't use midnight as the start of the trading session and have trading sessions spanning two days. For example, CME's trading session for Monday actually starts on Sunday in Chicago time. A potential solution to this is to extend our API and portal functionality, while keeping the current UTC-based time as default behavior: Add advanced customization that lets users specify time in "market time zone". Add advanced customization that lets users specify dates in "trading session date". Extend API methods to accept start/end time in "market time zone", without the user having to do lower-level timezone conversions themselves. e.g. A flag like tz='local'. Extend API methods to accept start/end time in "trading session date".

The current coverage for EEX covers futures and options on futures, but gas spot contracts are not currently part of the coverage. In the scope of this ticket, add support for EEX gas spot contracts under the XEEE.EOBI dataset.

Currently we support subscribing/requesting to individual symbols (e.g., ESM6, AAPL, TSLA), or individual products (e.g., ES, ZS, TSLA.OPT), but it could also be useful to do this on a channel basis. Credit: Leo on Databento Slack community. Databento notes: At the moment you have the back out the channel groupings from the instrument definitions, which is a bit tedious especially if there are a large number of instruments on a given channel, exceeding the per request symbol limit. The purpose will be quite different from venues like CME which group instruments by related product group vs., for example, equity options where the channels are based on load and constantly get rebalanced. It may not make sense to have this feature everywhere.Another way to do this currently is through our pcaps, which could be easier to break out by channel depending on the user's workflow.

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.