Replay the market, or query its state? DEBYKO vs Tardis.dev.

1. Two questions, two workflows

A researcher studies a short disruption in BTC perpetuals. Two things to know: what happened inside the order book, and whether the monitoring system had valid data while it happened.

What happened inside the book? Replay. Take trades, book snapshots and incremental updates, apply them in sequence, watch the book evolve. This is Tardis's workflow: incremental_book_L2, trades, reconstructed snapshots, at the granularity of the exchange feed [1][5]. It answers questions about queues, short-lived liquidity and spread dynamics.

What could the system use? State. For each venue at that instant: which value was recorded, when the venue stamped it, when it was received, was it still valid, and if not, why. DEBYKO answers that from its snapshot and history endpoints [8], so every consumer does not rebuild a freshness rule from message timestamps and connection logs.

Neither makes the other unnecessary. Replay gives sequence and granularity. State gives a usable-or-not answer.

2. Both record time. DEBYKO also decides.

A lazy comparison would say DEBYKO has exchange and receipt timestamps and Tardis does not. Wrong. Tardis's normalised datasets carry timestamp (exchange, with a documented fallback) and local_timestamp (arrival at Tardis) [1].

DEBYKO carries the same two times and adds a contract on top: how old the value is by the venue's clock, until when it counts as current, where that horizon comes from, and a status with a reason [6][7]. The horizon is one of measured, documented, assumed, venue_declared (the venue says when the next value comes) or connection.

That matters where feeds differ. Some venues publish on a schedule. Some publish only on change. A quiet feed is not a dead feed. A disconnected one is. DEBYKO tells them apart instead of treating every silent interval the same way.

3. When a value goes stale

This answer did not include that example. Nothing is shown in its place.

The previous value still exists. It is not returned as current. With allow_stale it comes back under withheld, apart from usable values. A consumer that ignores status cannot read an expired number from the value field by accident.

Tardis documents collection incidents and disconnects, and its replay carries disconnect messages [2][3]. It does not hide gaps. It leaves the usability decision to you.

4. History is not one thing

DEBYKO's POST /v2/snapshots/history has three modes [8]. at is the state at named instants. interval is a range sampled at a chosen step. raw is the recorded rows as they arrived.

[
  {
    "received_at": "2026-10-09T18:46:59.662Z",
    "venue_ts": "2026-10-09T18:46:59.558Z",
    "values": {
      "last": 82408.0
    }
  },
  {
    "received_at": "2026-10-09T18:47:09.228Z",
    "venue_ts": "2026-10-09T18:47:09.156Z",
    "values": {
      "last": 82430.0
    }
  },
  {
    "received_at": "2026-10-09T18:47:19.966Z",
    "venue_ts": "2026-10-09T18:47:19.906Z",
    "values": {
      "last": 82446.0
    }
  }
]

So DEBYKO is not sampled snapshots only. raw is not full L2 replay either: what exists depends on the dataset, the collection method, retention and plan. For every incremental book update over a period, Tardis is the documented fit [5]. For whether a funding, mark, ticker or open-interest value was usable at an instant, DEBYKO is the direct one.

One hard limit: DEBYKO's collection began in September 2026. Tardis reaches back to 2019-03-30 for most exchanges on a yearly Business subscription [4]. Point-in-time queries do not conjure years that were never collected. If the research needs 2021, that settles it before API design matters.

5. Live data: who runs the collector

Tardis's live tooling is a server you run. It connects your process to exchange feeds [3]. DEBYKO runs the collectors and serves the values over REST, streams, DQL and MCP. The trade is control for operations: specialised exchange handling argues for your own collectors; cross-venue monitoring argues for a hosted service. Neither model is faster by definition. That needs measuring under your load.

6. Who decides whether data is usable

In an event pipeline you write the rules: arrival times, disconnects, expected cadence. Flexible, and yours to maintain. DEBYKO ships the rule set: present, stale, missing, not_published, off, each with a reason [7]. A missing open-interest value is not zero open interest. A venue that never publishes a field is not a collector that stopped. DQL evaluates conditions across venues under those semantics.

Questions.

Explore DEBYKO.

Sources.

Compared on 2026-10-09 from published documentation.

Tardis.dev

1 Downloadable CSV files: data types, timestamp and local_timestamp — https://docs.tardis.dev/downloadable-csv-files/overview retrieved 2026-10-09

2 Historical data details and collection incidents — https://docs.tardis.dev/historical-data-details/overview retrieved 2026-10-09

3 Replay, disconnect markers, and tardis-machine — https://docs.tardis.dev/tardis-machine/replaying-historical-data retrieved 2026-10-09

4 Billing period and history entitlements — https://docs.tardis.dev/faq/billing-and-subscriptions retrieved 2026-10-09

5 Order books: incremental L2 and reconstruction — https://docs.tardis.dev/faq/order-books retrieved 2026-10-09

DEBYKO

6 A stale value answered as stale — https://debyko.com/stale-market-data retrieved 2026-10-09

7 Statuses, reasons and horizon_source — https://docs.debyko.com/data/freshness/ retrieved 2026-10-09

8 History modes at, interval and raw — https://docs.debyko.com/api/endpoints/ retrieved 2026-10-09

9 Plans and anchors — https://debyko.com/#pricing retrieved 2026-10-09

Absence from the reviewed pages is not evidence that a feature does not exist. DEBYKO and Tardis.dev are independent products. No endorsement or affiliation.