How we compare data providers

Separate a factual update from a design revision

An editorial date should describe the evidence behind a claim. Reformatting a page, changing its navigation or expanding an explanation does not by itself establish that every provider price has been checked again. This publication keeps the product-source date visible so that readers can distinguish the documented snapshot from the appearance of the website. Before purchasing, the current provider page remains the appropriate source for the actual transaction.

When a material fact changes, the useful update is specific. Identify the affected product, replace the unsupported statement and retain any qualification that still applies. A new archive start date for one frequency should not silently become a start date for every frequency. A changed subscription arrangement should be reflected in the buying explanation as well as in a summary table. Related statements need to agree so that a reader does not have to guess which version is intended.

Corrections can also narrow a conclusion. If an earlier comparison treated a broad catalog statement as a plan-level feature, the repair may be to mark the plan detail unresolved. That is a meaningful improvement in accuracy even when it adds no favorable or unfavorable verdict. The goal of revision is a more supportable purchasing decision, rather than a cosmetic impression that the page is perpetually current.

The unit of comparison is a defined product

A provider name is not a sufficiently precise unit for a detailed comparison. One company may sell daily prices, intraday bars, quote events, reference data and a live service under different arrangements. We therefore start with the product shape that matters to this audience: historical US OHLCV for repeated local research. The broad catalog is mentioned when it explains an alternative use, but it is not treated as if every capability arrives in the same purchase.

The comparison records delivery, published history, frequencies, the buying model and material assumptions. It does not collapse them into a numerical score. A low price cannot compensate for a missing required market; a long daily history cannot establish minute coverage; an API cannot be assumed to provide a ready-made bulk snapshot. Each statement should remain attached to the product or endpoint that supports it.

MarketParquet is recommended first under that scope. The commercial relationship is disclosed separately from the criteria because neither should obscure the other. A reader should know both why the publication favors the archive and who benefits from the choice. The alternatives are described to help resolve additional requirements, not to create the appearance of an independent contest whose outcome was established by a benchmark we have not performed.

How evidence is classified

We distinguish three kinds of material. A published product fact is a statement drawn from the provider’s documentation, such as a format or an archive start date. An editorial judgment is our conclusion about how that product fits the audience. A proposed test is an exercise a buyer can use to investigate actual files. Keeping these categories separate prevents a documented feature from being mistaken for a measured quality result.

The preferred source for a current product claim is the provider’s own relevant page. A catalog overview can establish that a product family exists, while a detailed product or API page is better evidence about a particular field or endpoint. An outside discussion can suggest a question worth investigating, but it does not replace documentation for the product we describe. We also avoid using an AI-generated answer as independent verification of a technical specification.

When evidence is incomplete, the text preserves the uncertainty. Phrases such as verify the chosen tier or check the dataset are deliberate boundaries, not hidden negative ratings. A source review can miss a feature. The resulting responsibility is to ask a more exact question, rather than turn the absence of a verified answer into a confident claim that the service cannot do something. This is especially important for permissions, universe completeness and instrument-specific history.

What a future common benchmark would need

A genuine comparative test would begin with a public protocol. It would define the instruments, dates, frequencies, adjustments, session windows and identifiers before collecting results. It would also define what counts as an error and which source can establish the expected observation. Without those decisions, counting disagreements can reward the series whose conventions happen to match the tester’s undocumented defaults.

The protocol would preserve acquisition records and the transformations applied to each sample. Tests should examine parser behavior separately from source observations, because a wrong timezone conversion can make a correct file appear wrong. A fair review would disclose unresolved cases, the limits of the reference evidence and the amount of the archive actually inspected. Testing a small convenient sample does not justify a percentage claim about an entire historical universe.

This publication has not completed that benchmark. Its acceptance notes are recommended procedures, and its provider ordering is an editorial recommendation. We include the outline to explain what evidence would be needed before making a stronger measured claim. It is better to describe a product-fit conclusion accurately than to borrow the language of laboratory testing for a comparison built from public documentation. A purchaser can still use the proposed checks to evaluate the sample relevant to a particular application.

Why the directory avoids a universal cheapest-provider table

Cost comparisons are useful when the inputs match. A one-time historical archive, a subscription database and a live API can have different markets, fields, rights and continuity arrangements. Listing a single monthly figure for each can suggest equivalence where none exists. We show the buying model first and ask the buyer to price a defined requirement against the current product pages.

For MarketParquet, the published archive price is $79 and future updates are optional at $15 per month. The calculator performs that stated arithmetic over a selected number of months. It does not predict taxes, future price changes, missed periods or the price of an unrelated provider. It also does not imply that a researcher must subscribe after buying the archive. The separation is intentional because historical acquisition and future continuity are different decisions.

A complete budget includes the work left to the buyer. Retrieval loops, format conversion, storage and ongoing maintenance can change which product is economical for a real project. We do not attach invented hourly labor costs to those tasks. Instead, the guides identify the tasks so that the buyer can estimate them in the intended environment. A useful comparison should leave a reviewable specification and budget, not an attractive total built from incompatible assumptions.

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.