Product roadmap

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

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.

It would be helpful if OPRA trade conditions were included in the normalized schemas. This is useful information that's currently lost during normalization. Also include the "message type" of each last sale message. Similar to: https://roadmap.databento.com/roadmap/us-equity-trade-condition-codes

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

Kalshi is a regulated exchange where you can trade on the outcome of real world events: https://kalshi.com/

First take the DTCC released PCF files, then combine with you corporate actions data to define precisely the creation, redemption, tracking and intraday calc baskets. The real art here is calculating the estimated daily cash component from corp acts. to be used in the intraday calc basket. That is value add that clients will pay for and need. What is CIL today? What corporate action did the sponsors miss? When are ETF dividends? When are component dividends? When is the sponsor fee removed from cash? Other providers charge ~$60k per year for a buggy product.

Fetching the cost for a single (ticker, date) pair across all US equity venues is slow enough to be a real UX problem in our application. We quote one MBO ticker-day across the ~14 lit venues (each its own dataset: XNAS.ITCH, ARCX.PILLAR, EDGX.PITCH, XNYS.PILLAR, BATS.PITCH, MEMX.MEMOIR, EPRL.DOM, EDGA.PITCH, BATY.PITCH, XBOS.ITCH, XPSX.ITCH, XASE.PILLAR, XCHI.PILLAR, XCIS.PILLAR), and the whole quote regularly takes 10–20 seconds. What's slow. The bottleneck is metadata.get_cost itself, not our client. We issue all ~14 calls fully in parallel (one per venue/dataset), so the wall-clock is just the slowest single call. Timing one get_cost in isolation (POST /v0/metadata.get_cost, dataset=XNAS.ITCH, symbols=AAPL, schema=mbo, stype_in=raw_symbol, one trading day) we see: run 1: 19.7 s (returned HTTP 500)run 2: 13.6 srun 3: 9.3 s So a single cost lookup is a ~10–20 s server-side operation, and it intermittently 500s under that load. For comparison, metadata.get_dataset_range and metadata.list_schemas return in well under a second — only get_cost is expensive, which suggests it's doing a full scan/sizing of the requested slice rather than reading precomputed metadata. We've already optimized everything on our side (call get_cost directly without the list_schemas/get_dataset_range pre-flight; full parallelism; connection reuse), so the remaining latency is entirely the endpoint. Requested improvements (any one would help, roughly in order of preference): A batched cost endpoint that accepts multiple datasets in one request — e.g. POST /v0/metadata.get_cost taking a list of datasets (or a "all equity venues for this symbol/day" mode) and returning a cost per dataset. Today get_cost accepts multiple symbols but only one dataset, which forces N separate calls for a multi-venue equity quote. Batching would also let you parallelize/cache server-side far more efficiently than N independent client calls.Make a single get_cost materially faster — if the cost is being computed by scanning the slice, a precomputed or approximate per-dataset/per-day size index would cut this from ~10 s to sub-second. Even a sampled estimate (with a documented error bound) would be fine for pre-download sizing; we don't need exact bytes to show the user an estimate and gate on a cost limit.Fix the intermittent 500s under concurrent metadata load — at our (modest, ~14 parallel) request volume we see get_cost return 500 fairly often, which forces a retry and adds another ~10 s. Context / impact. We pre-flight get_cost purely to show users a per-venue and aggregate dollar estimate before they commit to a (paid) download. The slow quote is the single biggest friction point in that flow. A batched or precomputed-size path would turn a 10–20 s wait into something near-instant and remove the 500-retry tail.

Hello Databento team, I wanted to suggest a small API feature that would be useful for developers who automate historical data downloads. It would be very helpful if the API could return my account’s current balance, such as credits remaining or the current amount owed so far for the billing period. The main reason is budget control. I may want to set a monthly cap for how many credits I use or how much money I spend on data. If my application could check the current balance through the API, it could automatically stop downloading data before exceeding that limit. This would be especially useful because historical data downloads can take time, and I like being able to let downloads continue while I am away from the computer without having to constantly monitor the portal. Since the API already has access to my account and Databento knows the current pricing and usage so far, this would make automated data downloads much safer without requiring constant manual monitoring. Thanks for considering it.

Hello Databento team, I wanted to suggest a small API feature that would be useful for developers who automate historical data downloads. It would be very helpful if the API could return the account’s current balance, such as credits remaining or the current amount owed so far for the billing period. The main reason is budget control. I may want to set a monthly cap for how many credits I use or how much money I spend on data. If my application could check the current balance through the API, it could automatically stop downloading data before exceeding that limit. This would be especially useful because historical data downloads can take time, and I like being able to let downloads continue while I am away from the computer without having to constantly monitor the portal. Since the API already has access to my account and Databento knows the current pricing and usage so far, this would make automated data downloads much safer without requiring constant manual monitoring. Thanks for considering it.

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.

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.