Blog
Blog
Tardis.dev has become the default answer whenever a serious crypto researcher says they need historical tick data. That default exists for a reason. Tardis solved one of the ugliest problems in this category: keeping years of raw exchange events queryable enough that a strategy team can replay them as if the market were live again. For the right workflow, that is not just useful. It is foundational.
The problem starts when buyers flatten that strength into a broader claim and assume Tardis therefore solves the whole market-data stack. It does not. A replay-first raw-event archive and a live microstructure feature-delivery system do not remove the same bottleneck. They can both be excellent and still belong in different parts of the workflow.
That is why this comparison gets mangled so often. People ask which vendor is better when the real question is which layer of work the team is trying to avoid doing itself. If the missing capability is exact historical replay of order book events, that answer points one way. If the missing capability is live access to pre-computed pressure, liquidity, and execution-context features, that answer points another way.
Tardis earned its reputation by treating the event stream itself as the product. Snapshots, deltas, trades, and quote updates are stored with enough fidelity that a developer can reconstruct how a market evolved over time rather than settling for a bar-level approximation. For execution-sensitive research, that matters because the order of events is often the whole story.
That architecture is especially strong when a team needs to replay a market episode and test logic against the exact event cadence a live system would have observed. If the question is how a strategy would have behaved during a liquidation cascade, a fragmented cross-exchange move, or a spread blowout, replayable raw events are the honest substrate. A candle cannot answer that question. A compressed aggregate cannot answer it either.
Tardis also benefits from clarity of scope. It is obvious what the customer is buying: historical market events and a replay mechanism that can be wired into a backtest or research environment. The product does not pretend that raw replay is the same thing as a finished feature layer. It gives the researcher the inputs and leaves the derived interpretation to the buyer.
That trade is often rational. A well-funded desk with data engineers may prefer raw control. A research team building novel features may want the freedom to define its own transformations instead of accepting a vendor's pre-computed view of the market. In that situation, Tardis is not just adequate. It is structurally aligned.
The split begins as soon as the team's workflow does not stop at historical replay.
A raw-event archive solves the problem of reconstructing the market. It does not automatically solve the problem of querying live microstructure state in a production-friendly way. Those are different jobs. Once a team moves from "show me what happened" to "give me the feature layer now so I can test or deploy against it," the cost of building and maintaining that translation layer becomes the dominant issue.
That is the part many teams underprice. Order Flow Imbalance, liquidity stress, spread regimes, pressure divergence, or cross-venue confirmation are not hard because the formulas are mystical. They are hard because the pipeline has to normalise symbols, reconcile venue differences, handle dropouts, preserve sequence, and stay operational while the market is moving. The feature logic is cheap compared with the plumbing.
DepthSignal is built around removing that plumbing burden. Instead of shipping the raw event stream and expecting the buyer to build the whole interpretation stack, it ships pre-computed microstructure features across a normalised schema. That is a different promise from historical replay. It is not a weaker version of replay. It is a different layer of the stack.
For teams asking short-horizon research questions, that difference changes the time-to-insight dramatically. A desk that wants to compare live pressure across venues does not need to build the feature pipeline before it can ask the first useful question. That is the same reason real-time crypto microstructure data should not be treated like a minor variant of historical tick storage. The decision horizon is different, so the useful product shape is different.
Most strategy teams believe they can build around one data substrate and carry it cleanly from research into production. In practice, that is where the quiet cost shows up.
Historical replay infrastructure is optimized for faithfulness to the past. Live strategy infrastructure is optimized for delivering usable state in the next few seconds. Those priorities overlap, but they do not collapse into each other. A system that is perfect for replay can still be awkward for live feature delivery, and a system that is excellent for live feature queries can still be the wrong tool for event-exact reconstruction years back.
That is why teams so often discover a second build phase after the backtest looks done. The replay environment proved the signal idea, but the live system still needs symbol mapping, live ingestion, derived-feature computation, latency discipline, and operational monitoring. The team thought it was buying a direct bridge from research to deployment. Instead it bought a foundation for one half of the problem.
This is not a Tardis defect. It is a workflow-design error. The mistake is assuming that "data vendor" means "same architecture, different pricing." In reality the architecture often follows the decision horizon. If the live question is about pressure, liquidity, and execution context right now, then the feature layer matters more than the replay layer. If the research question is about reconstructing a past event sequence exactly, then the replay layer matters more than a ready-made feature API.
The practical outcome is that many serious teams end up needing both classes of infrastructure in some form. One answers the historical reconstruction problem. The other answers the live interpretation problem. Pretending one should dominate both usually creates rework instead of simplicity.
Is the primary use case historical replay or live feature consumption? If the team needs exact raw-event reconstruction, Tardis is closer to the requirement. If the team needs live access to normalised microstructure context, DepthSignal is closer.
Does the desk want raw control or faster answers? Tardis gives the raw substrate and leaves the analytical layer to the buyer. DepthSignal gives a computed layer so the buyer can move faster on questions that fit the delivered feature set.
Is the team trying to build novel metrics, or is it trying to use established microstructure signals quickly? If the real work is inventing features from scratch, raw replay is the better fit. If the real work is testing and using known microstructure signals without rebuilding everything, the feature-delivery model is more efficient.
Does the workflow depend on multi-year event reconstruction? If yes, that pushes hard toward a replay archive. If the workflow is dominated by today's research loop and live decision support, then the value shifts toward an API that already exposes derived state. That is also why a team should compare this category alongside how to choose a crypto market data vendor rather than inside a one-line vendor spreadsheet. The expensive mistake is almost always a mismatch between bottleneck and product layer.
DepthSignal does not replace a historical replay archive. If the job is to reconstruct market state from years ago at event level, Tardis is solving the right problem and DepthSignal is not pretending otherwise.
Tardis does not remove the live feature-construction burden for teams that need ready-to-query microstructure context in production. A replay-first architecture can feed that layer, but the buyer still has to own a meaningful amount of translation and operational work.
That distinction becomes even sharper for cross-venue questions. A team studying why one venue is not the whole market eventually runs into the problem described in cross-exchange order flow: raw events from one venue are not enough, and raw events from many venues multiply the plumbing burden before the research question is even addressed.
The point of the comparison is not to crown a universal winner. It is to stop buyers from pretending they are buying the same kind of product when they are not. Tardis is strongest when the workflow ends with high-fidelity replay and historical reconstruction. DepthSignal is strongest when the workflow begins with live feature delivery and fast microstructure research loops. Those are different jobs. Treating them as the same purchase is where the waste starts.
Yes. That is the part of the workflow where Tardis is structurally strongest.
No. It replaces part of the feature-construction burden for live microstructure research and execution-context analysis.
Because both get filed under crypto market data even though they remove different bottlenecks.
Yes. One product can serve replay and reconstruction, while the other serves live feature delivery and faster research iteration.