Product roadmap

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)

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.

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.

National Stock Exchange (NSE) and Bombay Stock Exchange (BSE) data.

At present, there is no mechanism through which a customer can cancel a batch download request once that request has been submitted. This ticket is to track the release of a feature that would allow customers to cancel batch download requests if those requests have not yet been completed.

Data for Deutsche Boerse Equities, including all schemas (MBO, MBP, ohlcv, etc.) Captured at Equinix FR2 primary colo.

SHFE - ShangHai Futures Exchange https://www.shfe.com.cn/eng/

I subscribed to US Equities Standard by mistake, please switch my plan to CME Globex MDP 3.0 Standard or refund

Hello Databento team, We receive GLBX.MDP3 (mbp-1) over the Live API from an AWS instance in the Chicago Local Zone (public IP 16.56.134.11) using five parallel sessions, and from an AWS instance in Tokyo using one more session. Several times over the past week all five Chicago sessions stopped receiving data at the same moment for 6 to 52 seconds, while the Tokyo session kept receiving normally. No data was lost - it arrived late - but the gap is long for us. We caught the latest event, on 2026-10-23 at 05:11 UTC, with ICMP probes and a TCP header capture, and it looks like a network problem between AWS Chicago and Lumen rather than on your gateway. We would appreciate your view from your side, and your help with Lumen, since we are not their customer. Sessions (gateway 209.127.153.140:13000) Chicago, from 16.56.134.11: session_id 2952877339, 3446806811, 791281060, 1849621801, 238573745 (connected 2026-10-17, no reconnects since). For earlier dates please look them up by our IP and time.Tokyo: session_id 238574248, same gateway IP, not affected. What we saw on 2026-10-23 (UTC) 05:11:21.6 ICMP echo from our Chicago instance to the Lumen router 4.69.148.254 and to 209.127.153.140 starts to fail; echo to AWS internal hops and to 1.1.1.1 / 8.8.8.8 keeps working.05:11:23.775 Last inbound TCP segment on all five sessions; then no inbound segment for 29.5-30.0 s.~05:11:46.6 Echo to the Lumen router and to the gateway works again.05:11:53.3-53.8 Data resumes on each session at the last acknowledged byte, starting with one segment and doubling per RTT. It looks like retransmission-timeout recovery on your server: it had unacknowledged data in flight, and none of it reached us.At the same time from Tokyo, ICMP to the same Lumen router 4.69.148.254 and to 209.127.153.140 had zero loss, and session 238574248 was on time. Our traceroute from Chicago: four AWS hops, AWS border 99.83.70.225, Lumen 4.69.148.254 (1.2 ms), 209.127.153.140 (2.8 ms). Earlier events looked the same (all five Chicago sessions silent at once, Tokyo on time): 2026-10-21 22:30:09-22:31:01 (52 s); a TCP keepalive we sent at 22:30:39 was answered, but data resumed only at 22:31:012026-10-17 02:50 (6.6 s) and 09:20 (7.2 s); 2026-10-19 00:33 (6.4 s) Questions Do your logs show retransmissions or timeouts toward 16.56.134.11 on 2026-10-23 05:11:23-05:11:53 UTC and 2026-10-21 22:30:09-22:31:01 UTC?Did you see any issue on your Lumen connectivity in Chicago at those times, or similar reports from other customers in AWS Chicago?Could you raise it with Lumen?Is there a way to reach the gateway from AWS Chicago that avoids this interconnect (another address or carrier, a cross-connect, or a private connectivity option)? We can share the ping logs and packet captures if useful. Thank you, Sergei

it isnt clear i needed opra i need that not the databento us equities

I would like to buy /NQ 1 min DT OHLCV csv 2019 -> present

Sign the Windows .pyd files in the databento-dbn wheels and the dbn.exe and dbn_c.dll files in the GitHub release so Windows Smart App Control doesn't block them.

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.