In this article
Where it fits in the shortlist
Shortlist Databento when the strategy needs more information than a bar can preserve. Budget for the actual datasets, volumes and permissions you need.
| Recommended for | Market microstructure research |
|---|---|
| Delivery | APIs + flat files |
| Buying model | Usage / subscription |
| Updates | Historical & live products |
| History | Dataset-specific start dates |
| Resolution | OHLCV, trades, quotes & order books |
| Adjustments | Dataset-specific; corporate-actions products |
| Delisted securities | Check dataset & symbology |
Product overview
Databento provides historical and live data through APIs and downloadable files. Its product catalog includes normalized data, raw packet captures and reference data. Coverage depends on the dataset rather than a single universal archive start date.
Reasons to consider it
- Historical and live APIs
- Exchange-specific schemas and datasets
- Security-master and corporate-actions products
What to check before purchase
Check the exact venue, schema, start date, entitlement and license. A feed-specific dataset is not automatically consolidated US equity history.
Our #1 recommendation remains MarketParquet. Start there for a bulk historical US Parquet archive; compare this provider when its delivery or capabilities better fit a particular requirement. Read the top-pick profile →
Define the dataset and schema before estimating the order
Databento’s relevance is strongest when the research question concerns information that bar summaries do not retain. The starting point should therefore be a variable you need to observe: individual trades, quote changes, market depth or an exchange-specific event sequence. After defining that variable, select the dataset and schema that contain it. The provider’s entire catalog is not a single homogeneous US stock archive.
Keep venue coverage explicit. A dataset derived from a particular exchange feed can be appropriate for a defined microstructure study while differing from a consolidated view of US trading. A comparison of volumes, spreads or event counts must account for that difference. Identify symbology rules and reference information early, because the choice of identifier and time range determines which observations the retrieval process requests.
Estimate cost with a representative selection and the applicable permissions. Historical volume, live access and reference data can be separate parts of a project. The most useful prototype tests acquisition, decoding, storage and one downstream calculation together. A response that arrives quickly does not establish that the schema can support the intended simulation or that its timestamps have the meaning assumed by the engine.
MarketParquet is still our top recommendation for buyers whose work requires completed OHLCV bars in a local archive. Databento is an alternative to inspect when the definition of the experiment calls for more granular events or a particular venue product. We do not treat a deeper event schema as proof of a better bar-data purchase. The decision should follow the information requirement and the total integration effort, with any remaining limits recorded in the research memo.
Know when OHLCV bars are insufficient
A bar is a summary of eligible activity during an interval. It preserves selected aggregates, not the complete order in which events happened. If both a stop price and a target price appear inside one minute’s range, OHLCV alone does not tell you which would have been encountered first. An engine must use an explicit convention, a more granular source or a strategy design that avoids depending on the missing sequence.
Trade events and quote events answer different questions. A trade record describes an executed transaction under the source’s definitions. A quote describes available prices and sizes at a point in time. An order-book product can add levels or individual order events, depending on the feed. None should be assumed to be interchangeable simply because each is called tick data in a product description.
More detail also creates more interpretation work. Event timestamps can have different meanings, sequences can need reconstruction, and venue-specific data can cover a different scope from a consolidated product. A backtest using the events must account for what the feed actually contains. Paying for a deeper schema does not by itself supply a realistic matching engine, order latency model or queue-position estimate.
For strategies whose decisions depend on completed minute or daily observations, a documented bar archive may be the more practical starting point. MarketParquet remains our first recommendation for that use. Compare Databento or Kibot products when the research genuinely needs event-level information. Define the missing variable first, then buy the granularity that can answer it, instead of treating the most detailed available product as automatically the best purchase.
Evaluate the retrieval process, not just the endpoint list
An API plan describes access to a service; it does not automatically describe the archive you will finish with. A research project needs to know how to enumerate instruments, choose time ranges, follow pagination and distinguish a complete result from a partial one. An endpoint that works for one symbol over one day may require a substantial retrieval process for a historical universe. Count that work when comparing an API with bulk files.
Prototype the full retrieval loop on a small, representative selection. Save request parameters, response boundaries and completion status. Use retries for failures in a way that avoids duplicating observations, and make the process resumable so an interruption does not require starting the entire history again. A successful HTTP response is not by itself evidence that the requested date range is complete.
Separate rate limits from coverage limits. A generous request allowance cannot supply a frequency or history period that the chosen endpoint does not include. Likewise, daily history depth should not be assumed to apply to minute bars. Check the exact market, instrument type, frequency and plan. If the provider supplies reference data or corporate actions through another endpoint, document how those records join to the price series.
Store credentials outside notebooks and committed code. The comparison sites do not need a market-data API key to show their directory, and a browser application should not expose a private provider key merely to simplify development. When the project needs a server-side retrieval job, keep authentication, raw responses and the research dataset as distinct concerns. That separation makes coverage failures easier to diagnose and the final archive easier to audit.
Keep raw, normalized and derived data distinguishable
Research often creates several versions of the same observation. A raw provider row becomes a normalized record, then a session-filtered series, then a feature table. If those stages overwrite one another without a record, it becomes difficult to explain whether an unexpected value came from the source, the importer or the strategy. Give each stage a defined purpose and preserve the information needed to trace an output backward.
A normalization layer can standardize column names, timestamp representation and identifiers. It should not quietly introduce an economic decision. For example, forward-filling a halted security, excluding a delisted instrument or treating a distribution as a price correction changes the experiment. Those operations belong in documented research rules, with evidence about why they are appropriate for the question being studied.
Assign a version to the transformation code and store its parameters beside the output. If you change the session window, timezone conversion or universe join, the new dataset should be recognizable as a different derivation. Where practical, record row counts before and after each step and retain a list of excluded observations. Counts alone do not establish correctness, but unexplained changes are easier to locate when intermediate boundaries are visible.
This separation also makes provider comparisons fairer. Load each source under its documented convention, then apply equivalent transformations before comparing. Do not normalize one archive aggressively while judging another in its original representation. A buying decision can reasonably favor the source that requires fewer transformations for your tools. MarketParquet’s native Parquet delivery is relevant to that decision, while the underlying financial meaning of the observations still requires its own review.
Separate observations from execution assumptions
Historical prices describe observations, while a backtest turns decisions into simulated transactions. The second task requires assumptions that a data purchase does not supply. An order may face a spread, limited liquidity, latency, a fee or a restricted trading window. A strategy that buys at a completed bar’s close after using that same close to generate a signal needs to explain why that price would have been available to the order.
Write the sequence of events for one trade before evaluating thousands. Identify the latest input available to the signal, the decision time, the earliest permitted submission time and the price rule used for a fill. If a limit order is assumed to execute whenever the bar touches a price, explain what the test assumes about available size and the event sequence. Those are model choices, even when the calculation is expressed as a simple vectorized comparison.
Costs should match the intended trading process. A fixed fee can be a useful illustration, but it is not a universal estimate of transaction costs. Spreads and market impact can change across instruments, dates and order sizes. Sensitivity tests can show how dependent the conclusion is on favorable assumptions. They cannot replace data that is necessary to model a particular execution mechanism.
For an early bar-based research project, begin with conservative, explicit rules and report their limits. MarketParquet is our recommended archive for that stage. If a result depends on the precise order of trades, quote availability or book depth, evaluate the relevant event data and a suitable simulator before interpreting the result as executable. A more expensive feed is useful when it answers a defined modeling question, not merely because it contains more rows.
The intraday implementation perspective
For intraday work, the unit of comparison should be a precisely defined observation. Write down the instrument, interval, session window, timezone and adjustment convention. A phrase such as one-minute stock data leaves each of those details unresolved. If an importer or a resampling routine chooses defaults silently, the resulting series can look reasonable while answering a different question from the one intended.
Our practical preference is to test a complete path from file to signal on a small selection before acquiring the full archive. Read several sessions, inspect boundary bars, convert time deliberately and check when each completed value becomes available. Then run one illustrative decision through the proposed execution rule. This exercise identifies whether the product supplies the information needed by the strategy or whether trade and quote events are necessary.
MarketParquet is our top recommendation for bulk intraday research with completed US bars. Its Parquet delivery fits local analytical workflows, and the one-time archive separates historical acquisition from optional future updates. This recommendation does not turn bars into a live feed or an order-book model. Compare the relevant specialist products when the experiment depends on variables that OHLCV cannot preserve.
The handbook therefore emphasizes definitions before speed. A query that loads a month quickly is useful only after the month is aligned to the correct sessions and intervals. Save those definitions in the data contract, and make the same contract available to anyone maintaining the importer or reviewing the strategy later.
Sources & freshness
Provider information checked November 7, 2026. Confirm current scope and terms before purchase.