Databento · Rate Limits

Databento Rate Limits

Databento advertises unlimited API calls and downloads with no per-request fees, so throughput is governed by usage-based billing rather than a hard per-minute request cap. In practice, historical requests are bounded by concurrency limits and by how much data your account and credit/plan allow you to stream, and very large pulls are steered toward the asynchronous Batch API, which materializes flat files rather than streaming synchronously. Live data is a continuous TCP subscription rather than a request-rate surface; its volume is governed by the schemas and symbols you subscribe to. Specific numeric per-account request or concurrency limits are not prominently published.

Databento Rate Limits is the machine-readable rate-limit profile for Databento on the APIs.io network, conforming to the API Commons Rate Limits specification.

It captures 5 rate-limit definitions, measuring requests, bytes, records, days, and stream.

The profile also includes 3 backoff/retry policies defined and response codes documented for throttled.

Tagged areas include Market Data, Financial Data, Historical Market Data, Trading, and Rate Limiting.

5 Limits Throttle: 429
Market DataFinancial DataHistorical Market DataTradingRate LimitingQuotas

Limits

Historical API Calls account
requests
unlimited (no per-request fee)
Databento advertises unlimited API calls; no fixed numeric request-rate cap is published.
Streaming Data Volume account
bytes
usage-based (per credit / plan)
Bounded by billing - per-byte pay-as-you-go, free credit, or subscription depth - not by a request cap.
Synchronous Query Size request
records
steer large pulls to Batch
Very large historical extracts should use the asynchronous Batch API rather than synchronous timeseries.get_range.
Batch Download Retention job
days
30
Batch output files remain re-downloadable for 30 days at no extra cost.
Live Subscription session
stream
continuous
Live is a persistent TCP/DBN subscription; volume is governed by subscribed symbols and schemas, not a request rate.

Policies

Cost Estimation First
Use metadata.get_record_count, metadata.get_billable_size, and metadata.get_cost to pre-size and pre-price a query before streaming.
Prefer Batch for Bulk
Route large historical extracts through batch.submit_job to produce downloadable flat files instead of long synchronous streams.
Backoff Strategy
Clients should implement exponential backoff with jitter and honor Retry-After on 429 responses.

Sources