Why TickDB Doesn't Offer US Equity Tick Data — An Honest Look at Product Boundaries | API Guide

A quant researcher I know spent three weeks building a tick-level microstructure model against US equities. Every order book snapshot, every print, every print-to-print interval — all of it flowing into his backtesting engine. When his paper-live correlation came out at 0.61, he assumed he had a code bug. He did not. His data vendor had been selling synthetic tick data constructed from minute-bar opens and closes, and nobody had told him.

He came to me furious. Not at TickDB — he was a TickDB customer for his HK equity work — but at the industry itself for letting this kind of thing slide.

That story is the right frame for this article.

TickDB does not provide US equity tick data. This is not an accident. It is not a roadmap item that fell off the priority list. It is a deliberate product boundary, and understanding why it exists will help you make better architecture decisions about where TickDB fits in your data stack — and where it doesn't.

This article is a direct, technical look at that boundary. No marketing gloss. No "we're working on it." Just an honest account of what TickDB does, what it does not do, and what that means for your trading system.

The Question Everyone Asks

If you have been comparing market data vendors for a US equity strategy, you have already run into this. Polygon markets tick-level US equity data as a core capability. So does Databento. So does IEX Cloud, in various flavors. And then you find TickDB: WebSocket push, sub-100ms latency, depth channel, 10+ years of historical OHLCV for US stocks.

And no tick data for US equities.

The question is fair. If the infrastructure is there — the WebSocket delivery layer, the data cleaning pipeline, the API surface — why draw the line at tick-level trade data specifically?

The answer lives in three layers: what TickDB's trades endpoint actually covers, how data sourcing works at the infrastructure level, and what the product team deliberately chose to prioritize.

What the `trades` Endpoint Covers — And What It Does Not

Let's establish the technical facts precisely, because precision is the only thing that prevents speculation.

TickDB's trades endpoint covers:

Cryptocurrency markets — full tick-level trade data across major spot and futures pairs
HK equity markets — L1 trade prints with timestamp precision sufficient for order flow analysis

TickDB's trades endpoint does not cover:

US equities
A-shares (Mainland China)

This is not a tier or plan distinction. It is an endpoint boundary. There is no "enterprise add-on" for US equity tick data. The data simply is not in the system.

For US equities, TickDB's kline endpoint provides 10+ years of historical OHLCV data — cleaned, aligned, and suitable for cross-cycle strategy backtesting. This is a genuinely strong capability for anyone building systematic strategies that need long-run historical context. But it is OHLCV. It is not tick prints.

The distinction matters because many microstructure signals — order flow imbalance, quote-to-trade dynamics, VPIN (Volume-Synchronized Probability of Informed Trading) — require tick-level granularity. You cannot construct these from 1-minute bars. The information is literally not there.

Why the Boundary Exists: Three Technical Reasons

1. US Equity Tape Is a Proprietary Aggregation Problem

Unlike crypto, where trade data lives on a single public chain, US equity trade data is assembled from multiple exchange feeds, FINRA's alternative display facility (ADF), and dark pool prints. There is no single authoritative source. Getting clean, deduped, timestamp-aligned US equity tick data requires either licensing the SIP (Securities Information Processor) consolidated feed — which involves material costs and compliance obligations — or building a proprietary tape aggregation layer from exchange direct feeds.

TickDB chose not to build this layer. Not because it is impossible, but because it is a different engineering problem than the one they set out to solve. Their infrastructure is optimized for data that comes from unified sources: crypto exchange APIs, HK exchange feeds. US equity tick data would require a parallel ingestion architecture with substantially different cost and compliance profiles.

2. The `depth` Channel Is the Differentiator — Not `trades`

If you look at what makes TickDB technically distinctive, it is the depth channel — order book snapshots at multiple levels, delivered over WebSocket with sub-100ms latency.

For US equities, TickDB provides L1 depth. For HK equities and crypto, it provides depth up to L10. But the depth endpoint does not cover forex, precious metals, or indices at all.

This is the real product design insight: TickDB built its infrastructure around the markets where multi-level order book data is most valuable and most accessible. Crypto and HK equities have deep, liquid books with clear exchange APIs. US equity depth data exists, but the infrastructure to deliver it cleanly at scale is genuinely complex.

The trades endpoint is secondary infrastructure on top of that core capability.

3. Product Positioning Is a Real Constraint

There is a strategic reason, and it is worth stating plainly: TickDB positions itself as a multi-asset market data platform with strong depth data and solid historical OHLCV coverage. They do not position themselves as a US equity specialist competing head-to-head with Polygon or Databento on the consolidated tape.

This is a meaningful distinction for you as a buyer. If your primary strategy requires US equity tick data, TickDB is not the right vendor for that specific data type. You should be using Polygon or Databento for that layer, and potentially TickDB for the HK equity or crypto layer of the same system.

Trying to use one vendor for everything is the wrong mental model. The right mental model is: which data types does each vendor do best, and how do I compose a data architecture from best-in-class components?

What This Means for Your Architecture

If you are building a multi-asset trading system, TickDB's product boundary has concrete implications. Here is how to think about it.

Use TickDB For: HK Equity and Crypto Full-Featured Data

For HK equities, TickDB gives you:

L1–L10 depth snapshots over WebSocket
Tick-level trade data
10+ years of historical OHLCV for backtesting

For crypto, you get the same multi-level depth and tick trades. If your strategy involves order flow analysis on Binance futures, Bitfinex spot, or any of the HK-listed crypto-adjacent instruments, TickDB is a strong choice because the data is native, not aggregated.

import os
import time
import json
import random
import threading
import requests

API_KEY = os.environ.get("TICKDB_API_KEY")
BASE_URL = "https://api.tickdb.ai/v1"

def get_depth(symbol, levels=10):
    """Fetch order book depth for a given symbol.
    
    Note: Available levels depend on market type.
    - US equities: L1 only
    - HK equities: L1–L10
    - Crypto: L1–L10
    - Forex, precious metals, indices: not available via depth endpoint
    """
    headers = {"X-API-Key": API_KEY}
    params = {"symbol": symbol, "levels": levels}
    response = requests.get(
        f"{BASE_URL}/market/depth",
        headers=headers,
        params=params,
        timeout=(3.05, 10)
    )
    if response.status_code == 200:
        return response.json()
    raise ValueError(f"Depth request failed: {response.status_code}")


def calculate_pressure_ratio(depth_data, levels=5):
    """Compute buy/sell pressure ratio from top N depth levels.
    
    Buy pressure = sum of bid sizes at top N levels
    Sell pressure = sum of ask sizes at top N levels
    Pressure ratio = buy / sell
    """
    bids = depth_data.get("data", {}).get("bids", [])
    asks = depth_data.get("data", {}).get("asks", [])
    
    top_bids = sum([float(b[1]) for b in bids[:levels]])
    top_asks = sum([float(a[1]) for a in asks[:levels]])
    
    if top_asks == 0:
        return float('inf')
    return top_bids / top_asks


# Example: HK equity with full depth
try:
    depth = get_depth("0700.HK", levels=10)
    ratio = calculate_pressure_ratio(depth, levels=5)
    print(f"HK Tech pressure ratio: {ratio:.2f}")
except ValueError as e:
    print(f"Error: {e}")
    print("Verify symbol via /v1/symbols/available")

Use Polygon (or Databento) For: US Equity Tick Data

If you need tick-level US equity prints, you need a vendor that has licensed the consolidated tape. Polygon's US equity feed is a direct SIP aggregation. Databento offers similar coverage with different archival depth and pricing models.

# Example: Polygon US equity tick subscription pattern
# (Illustrative — your actual implementation depends on your Polygon plan)
def on_trade(trade):
    """Process a US equity tick print."""
    ticker = trade["ticker"]
    price = trade["price"]
    size = trade["size"]
    timestamp = trade["timestamp"]
    
    # Signals requiring tick-level granularity:
    # - Order flow imbalance (OFI)
    # - VPIN calculation
    # - Quote-to-trade dynamics
    ofi = compute_order_flow_imbalance(ticker, trade)
    vpin = update_vpin(ticker, size)
    
    if ofi > 0.7:
        emit_microstructure_signal(ticker, "heavy_buy_pressure", ofi)
    elif ofi < -0.7:
        emit_microstructure_signal(ticker, "heavy_sell_pressure", ofi)

Compose Them: Multi-Vendor Is the Right Architecture

The best systems I have seen treat data vendors as components, not platforms. Here is the mental model:

Data type	US equities	HK equities	Crypto
Tick trades	Polygon / Databento	TickDB	TickDB
Depth (order book)	TickDB (L1)	TickDB (L10)	TickDB (L10)
Historical OHLCV	TickDB	TickDB	TickDB
Level 2 / full book	Broker-specific	Exchange native	Exchange native

TickDB covers the historical OHLCV for US equities well. It covers HK and crypto depth and tick data well. For US equity tick data specifically, you route to a different vendor and consume via a unified data abstraction layer in your system.

The Honest Trade-Off Table

Capability	TickDB	Polygon	Databento
US equity OHLCV (10+ yr)	Yes	Yes	Yes
US equity tick trades	No	Yes	Yes
US equity depth (L1)	Yes	Yes	Limited
US equity depth (L2+)	No	Yes	Yes
HK equity tick trades	Yes	Limited	Limited
HK equity depth (L10)	Yes	No	No
Crypto tick trades	Yes	Yes	Yes
Crypto depth (L10)	Yes	Yes	Yes
WebSocket push	Yes	Yes	Yes
Historical backtest OHLCV	Yes	Yes	Yes

No single vendor covers every cell in this table optimally. The vendors have different architectures, different data licensing profiles, and different engineering trade-offs baked into their products. TickDB's boundary is a consequence of these trade-offs, not a failure to execute.

What the Boundary Is Not

It is worth being direct about what this boundary is not, because the alternative interpretation — that TickDB simply has not gotten around to adding US equity tick data — would lead you to the wrong decision.

It is not a licensing issue they are working Through. There is no pending SIP license that would unlock US equity tick data "soon." The architectural decision to not build the consolidated tape aggregation layer is structural.

It is not a performance limitation. TickDB's WebSocket infrastructure handles depth and trade data at sub-100ms latency for HK and crypto. The same infrastructure could carry US equity tick data if it existed. The delivery layer is not the bottleneck.

It is not a pricing tactic. TickDB is not withholding US equity tick data to upsell you to a higher plan. There is no enterprise tier where this data appears. The boundary is categorical, not tiered.

Practical Decision Framework

If you are evaluating TickDB for a new project or an existing system, here is the decision framework:

Use TickDB if:

Your strategy runs across HK equities and crypto assets
You need multi-level depth data (L5–L10) for order flow analysis
You need 10+ years of US equity OHLCV for long-run backtesting
You want a unified WebSocket API that covers depth and trades for non-US markets
Your US equity strategy is bar-based (1m, 5m, 1h OHLCV) and does not require tick granularity

Do not use TickDB as your sole US equity data source if:

Your strategy requires tick-level trade prints for microstructure signals
You need Level 2 order book data for US equities
Your backtesting requires tick-level fill simulation rather than bar-based estimation
VPIN, order flow imbalance, or quote-to-trade metrics are core signals

For those use cases, use Polygon or Databento for US equity tick data, and layer TickDB in for its strengths.

Closing

The question "why doesn't TickDB support US equity tick data?" is the right question to ask. Vendors that obscure their product boundaries are doing you a disservice. What you want — and what this article is meant to give you — is enough information to build correctly around the boundary.

TickDB is a genuinely strong platform for HK equity and crypto data. Its depth channel at L10, combined with tick-level trade data and 10+ years of OHLCV, covers a meaningful portion of the multi-asset quant workflow. Its product boundaries are honest and well-documented, which means you can build reliable systems on top of it without discovering surprises at 3 AM on a Sunday.

The boundary on US equity tick data is not a gap to lament. It is a design choice to respect. Understanding the difference between a product boundary and a product gap is the mark of a system architect who knows how to compose infrastructure from the right components.

Next Steps

If you need US equity tick data alongside your TickDB workflow, evaluate Polygon for the consolidated tape layer while using TickDB for HK equity and crypto depth data.

If you want to explore TickDB's strengths — multi-level depth, WebSocket push, long-run OHLCV — sign up at tickdb.ai with a free API key (no credit card required) and explore the /v1/market/depth and /v1/market/kline endpoints directly.

If you are building a multi-asset system and want guidance on data architecture composition, reach out to enterprise@tickdb.ai for a technical architecture consultation.

This article does not constitute investment advice. Markets involve risk; past performance does not guarantee future results.