Product roadmap

To extend support to browser-based applications.

Currently, n and v continuous symbology is supported in historical data but not live data. Live data only supports c (calendar-based) continuous symbology, which is less useful.

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.

This client library makes all our historical and live features easier to integrate in C# on Windows, Linux, and Mac OS. C# is currently already supported through our HTTP API and Raw TCP protocol, which are both language-agnostic.

Add a schema for calculated metrics like options greeks, e.g. implied volatility, delta, etc.

This ticket tracks the feature of releasing historical data as early as permissible. Currently, we embargo historical data strictly at a 24h cutoff to ensure that it is distributed safely as historical data for every venue, thus sidestepping real-time/delayed licensing requirements for our users. However, many venues actually define their "historical" boundary as the same date in venue local timezone OR the session end. So in theory, if a session ends at 8 PM ET, it would be possible to distribute data from the same day at 7.59 PM ET at 8 PM ET. Currently, to get data from within the trading session, you must use the live API (through Raw API or a live client of the Raw API). However, the Raw API can be unwieldy for a range of use cases that require a small amount of data from the current trading session. For example, if the user only needs a few instrument definitions, settlement prices, or wants to update a ticker tape based on subsampled OHLCVs, it is usually preferred to use a request-response model like our HTTP API; setting up and tearing down a stateful TCP subscription for the live API is probably too hefty for this feature. Once released, users should be able to access intraday historical data via HTTP API so long as they have a live data entitlement. See also: https://roadmap.databento.com/b/n0o5prm6/feature-ideas/provide-snapshots-for-historical-and-live-data

Ability to get raw data payloads and historical PCAPs, as opposed to normalized data that is currently available. For example, on CME, there are shortcomings with normalized data: Normalized data schemas do not provide MDOrderPriority, which can be useful for LMM markets or make it easier to handle order quantity down-modifies.Normalized data schemas do not show full message tree of trade summary messages, making it harder and slower to associate passive-side changes after an aggressing trade is reported. This issue arises because of the asynchronous nature of CME's trade reporting vs order update publication; order updates get published after the trade summary. Currently, a user has to use heuristics to detect whether a down-modify/partial cancel is the result of a fill. On other venues, there are other message fields that our normalized format will fail to capture. The main challenge with providing PCAPs and raw data is that it is bandwidth-intensive. Furthermore, the message sizes vary, which throws off our pricing, search, filtering, and merging routine. This will introduce some asymmetry to our API design. A solution to this will likely be in the form of separate endpoint(s) on the historical side, and only be released after we've provided customer VMs.

Data for: Copenhagen Stock Exchange (Nasdaq Copenhagen) Stockholm Stock Exchange (Nasdaq Stockholm) Helsinki Stock Exchange (Nasdaq Helsinki) Iceland Stock Exchange (Nasdaq Iceland) Tallinn Stock Exchange (Nasdaq Baltic) Riga Stock Exchange (Nasdaq Baltic) Vilnius Stock Exchange (Nasdaq Baltic)

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

Via streamlined SBE.

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.

Provide technical indicators and derived data such as RSI, VWAP, SMA, EMA, MACD, etc. Saves time vs. calculating on the client side.

This client library makes all our historical and live features easier to integrate in R on Windows, Linux, and Mac OS. R is currently already supported through our HTTP API and Raw TCP protocol, which are both language-agnostic.

Currently the user portal i.e. Databento browser UI only allows the selection of product groups for futures and options like ES.FUT, ES.OPT, TSLA.OPT, etc. The main reason for this limitation is that our UI is already quite complex to handle multiple asset calsses. Providing individual instrument selection will result in a nested structure where you can go from dataset -> product -> instrument, and there are too many similarities between products and instruments (e.g. AAPL as a product only 1 has instrument, which is also AAPL). All of these create complications in the frontend and UX design that we deferred to later. However, many users prefer to only fetch the lead month futures contract or expiration month. This reduces the size of the data, making it more affordable or easier to access. It also makes the browser UI for useful for pricing pay-as-you-go data requests, since the whole product complex may seem a lot more expensive than the user's actual needs when they fetch via API.

Equity data from TSX with broker IDs (TSX is one of the few markets out there with post-trade transparency)