Product roadmap

The current coverage for EEX (XEEE.EOBI datataset) does not include settlement price and open interest for EEX Japanese power futures.

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.

Support Parquet as a form of encoding, aside from dbn, CSV and JSON.

We've received some requests recently for Binance data. Please upvote if this is of interest. We're still determining whether this is worth the risk.

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

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.

Support AWS S3 as an additional method of delivery, aside from HTTP and FTP.

B3: Brazil Equities and Futures MBO data. Keywords for search purposes: Brasil Bolsa Balcão S.A., Brazilian Mercantile and Futures Exchange (BM&F), BMF, Bovespa (São Paulo Stock Exchange), Cetip (Central of Custody and Financial Settlement of Securities for the organized OTC market).

Macroeconomic data releases, such as: Jobs Inflation, e.g. CPI FOMC

Currently, the cancel action type C is used for both actual order cancellations and trade-related deletions. This makes it hard to construct features based on order cancellations as they need to keep history of trades or fills and ignore cancellations that come after. To solve this, we'll be introducing a delete action type D to delete orders after a trade.

Currently, we only support the standard Python versions and not the free-threaded interpreters. Supporting this will require some work in databento-dbn and perhaps dependencies of the databento package.

Currently any unresolved symbol results in the session ending and the connection being closed. The live API should have non-fatal errors for issues like an unsupported schema and symbols that fail to resolve. This is tracked internally as D-579

This ticket tracksthe setup of Databento's layer 1 network architecture. We anticipate this in Aurora I initially, then several venues in NY4, followed by FR2. At the moment, our data takes at least one layer 3 hop before getting to our capture server. Hardware timestamps are taken on the host. This results in some additional latency (about 500-550 ns for the layer 3 hop) and timestamping jitter. This also results in more inconsistency (typically at the sub-microsecond level) across hosts. The new layer 1 architecture will replace the layer 3 hop, cutting down 500-550 ns to 5 ns, achieve better timestamping consistency between our hosts, and lower jitter from the exchange handoff.

Please consider adding B3 (Brazil) equities and futures market data, both historical and real-time. TooQ Technology (https://tooqtechnology.com/) could be a strong upstream provider. Having B3 fully consolidated within the Databento API (same schema, symbology, and delivery model as other venues) would be extremely valuable for cross-market research, backtesting, and live trading, avoiding the need to stitch multiple vendors.

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.