Product roadmap

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.

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.

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

It can be inferred based on a delayed subscription ack, but it would be nice to have an explicit indication when the subscription rate limit has been hit.

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

Historical and live market news.

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)

Stocks and derivatives data from the Singapore Exchange (SGX)

Hi there! Ive only been working with your service a short time, but im already commited to your platform. Python is a GREAT general purpose language. But I think i am justified when I say that for certain use cases, a "compile to native binary" language like Go is superior for the speed and simplicity (no package dependencies to manage, easier to build out dockerized/container applications) Justification: While there are other compile to native languages (RUST, Haskell, an Elixir i have heard of), Go has a significantly higher developer community. Its will be alot easier to crowdsource for bug, QA, enhancements and fuel adoption...I believe only the bareminimum functionality should be "made official" from you guys. While i think there are some things that should be made simpler than what you provide in your Databento Python SDK, I believe its more important to keep a consistant "bare bones functionality" across all your SDK offerings for accessing your core datasets GO (if you werent aware) allows exposing packages/modules that Python can consume. So you should (in theory) be able to design a top level/ 1 to many code base that can be re-purposed for python (and any other languages) ....Instead of maintaining 2 SDK's... you maintain the one... and port to the other via package exposure)...attached a screenshot (While you provide a pip install package, this approach would allow also make it easier for you to push to other package managers like homebrew, nuget, NPM....without having to refactor and maintain code bases for multiple languages.. Im a long time Go developer... So i 120% would like to volunteer to assist with development and design efforts. Ive already done quite a bit on my own project that I believe others would find useful ( I believe you'd also benefit from having an end user and consumer, aid in designing the final consumer product(s)... You know what they say about starship designers, never actually getting to go into space LOL) Long story short, an official Go SDK would offer "Minimal effort, maximum coverage" and enhanced scalability Thanks in advance!

Apart from CME/Comex the most important exchanges for metals (prices, inventory, warehouse movements etc) are: LME, LBMA, SHFE, Dalian, and for all recycled commodities it is Davis Index. It would be a massive help if you can provide even just end of day data with historical data from these platforms to start with. Live feeds and delayed feeds are obvious next steps but EOD data would be a massive first step.

The provision of an account-wide notification when a user is exceeding rate limits to the extent that the entire team will be restricted.

Hello, I want to offer a future term structure curve on our website and within our Windows tool Tradility. It should work like the one presented on vixcentral but it should also allow for other underlyings (e.g. CL). It needn't be real time. 15 min delay is fine. I would like to know which product I should acquire to get started. Kind regards Daniel

Is there a way that I can add (a la carte) live logins? Right now the documentation suggests I can log into only 2 devices concurrently with the standard plan. As I am scaling my solution to additional products on additional servers, I am in a position where currently I require one additional login. It appears my only options are to sign up for a second standard account to get two more logins, or to move to plus which grants unlimited logins. Can I work out a way to just get a 3rd login added to my current plan?