The Question Every Quant Developer Asks

It usually starts the same way. You're three weeks into building a mean-reversion strategy on US equities. The OHLCV data looks clean. The backtest is singing. Then someone asks: "Are you using tick data for your order flow analysis?"

You pause. You realize you're missing something.

So you open the TickDB documentation, search for trades, and find a market coverage table. Your heart sinks a little. US equities are listed as unsupported.

The question that follows is reasonable: Why? Polygon offers it. Alpaca offers it. Databento offers it. TickDB is a serious market data platform — why won't it support the most traded market in the world?

This article answers that question honestly. Not with marketing deflection, but with the kind of technical transparency that helps you make a better tool-selection decision.

What "Tick Data" Actually Means

Before we discuss product boundaries, let's establish what we're talking about.

Tick data is the granular record of every individual trade executed in a market. For a US equity like Apple (AAPL), this means:

  • Every market participant who bought or sold AAPL
  • Every price level at which those trades occurred
  • Every timestamp (ideally nanosecond-level, realistically millisecond)
  • Every size (shares executed per trade)
  • Direction (whether the trade was initiated by the buyer or seller — the "tick rule")

A single trading day for AAPL generates roughly 2 to 5 million individual tick records. Multiply that by 10 years of history, across thousands of US equities, and you are looking at a dataset that dwarfs OHLCV by two to three orders of magnitude.

This matters because:

Data Type Records/Day (AAPL) Storage/Year Primary Use Case
OHLCV (1-minute) 390 ~50 KB Backtesting, technical indicators
Tick data 2–5 million ~2–5 GB Order flow analysis, latency arbitrage, microstructure research

The storage difference is not marginal. It is structural.

The Real Cost of Tick Data Infrastructure

When a data platform says it "supports tick data," it is making three interconnected commitments that are each independently expensive:

1. Data Acquisition at Scale

US equity trade data originates from three consolidated feeds (UTP, CTA, FINRA ADF) and multiple alternative sources. Normalizing, deduplicating, and timestamping this data to a consistent standard requires dedicated infrastructure teams.

A rough cost model:

Component Monthly Cost Estimate Notes
Exchange data fees $15,000–$50,000 Per venue, with volume discounts at institutional scale
Normalization pipeline $5,000–$15,000 Compute + engineering labor amortized
Storage (compressed) $2,000–$8,000 For 10 years of US equity tick history
Distribution infrastructure $3,000–$10,000 CDN, bandwidth, caching layers

For a platform serving hundreds or thousands of users, the data acquisition cost alone can exceed $30,000 per month before a single query is run.

2. Storage Architecture for Query Performance

Tick data is not useful if you cannot query it. A user asking "show me all trades for AAPL between 9:35 and 9:40 on March 15, 2023" needs a storage backend that can:

  • Scan billions of records in under a second
  • Support time-range filtering at query time
  • Handle concurrent read access from multiple users

This requires columnar storage formats (Parquet, Arrow), specialized time-series databases, or purpose-built tick analytics engines. None of these are commodity infrastructure.

3. Delivery Infrastructure for Real-Time Streams

Historical tick data is one challenge. Real-time tick streaming is another entirely.

A production WebSocket endpoint delivering US equity tick data must:

  • Ingest raw exchange feeds with < 1 ms latency
  • Normalize and deliver to connected clients within 5–10 ms
  • Handle thousands of concurrent WebSocket connections
  • Manage backpressure during high-volatility periods (e.g., FOMC announcements, flash crashes)

This is HFT-grade infrastructure, with a corresponding cost and operational complexity.

Why TickDB Made This Choice

TickDB's product philosophy is "do fewer things, but do them exceptionally well."

The platform has made a deliberate decision to focus on:

  1. Multi-asset OHLCV data — 10+ years of cleaned, aligned historical candles across 6 asset classes
  2. Real-time depth (order book) data — the depth channel for US (L1), HK (L1–L10), and crypto (L1–L10)
  3. Cross-asset normalization — a unified data model that lets you query US equities, Hong Kong stocks, crypto, forex, and commodities through a single API

The trade-off is that TickDB does not attempt to be the cheapest or most comprehensive source for every data type. Instead, it prioritizes:

TickDB Priority Why It Matters
Data cleanliness All OHLCV data is backtest-validated, not scraped
Multi-asset coverage A single API for 6 asset classes, not 6 separate vendors
Depth data fidelity Order book data is real-time, not end-of-day
Developer experience Production-grade SDKs, clear documentation, no surprise rate limits

Supporting US equity tick data would require either:

  • A separate engineering investment that diverts resources from depth and OHLCV quality
  • A pricing model that cross-subsidizes tick data from other revenue (which would increase costs for users who don't need tick data)

Neither outcome serves TickDB's core user base: systematic traders who need reliable multi-asset data at a reasonable price point.

What TickDB Does Offer for US Equities

The absence of tick data does not mean absence of data. For US equity strategies, TickDB provides:

1. Historical OHLCV (10+ Years)

The /v1/market/kline endpoint covers US equities with 10+ years of cleaned, aligned daily and intraday candles.

import os
import requests

headers = {"X-API-Key": os.environ.get("TICKDB_API_KEY")}

# Fetch 5 years of daily AAPL candles for backtesting
response = requests.get(
    "https://api.tickdb.ai/v1/market/kline",
    headers=headers,
    params={
        "symbol": "AAPL.US",
        "interval": "1d",
        "limit": 1825  # ~5 years of trading days
    },
    timeout=(3.05, 10)
)

data = response.json()
print(f"Retrieved {len(data['data'])} daily candles for AAPL")

This data is suitable for:

  • Strategy backtesting over multiple market cycles
  • Factor research (momentum, mean reversion, volatility)
  • Cross-sectional analysis across multiple US equities
  • Event studies (earnings, dividends, index rebalances)

2. Real-Time Depth Data (US L1)

The WebSocket depth channel delivers live order book snapshots for US equities at Level 1 (best bid/best ask).

import json
import time
import os
import websocket

API_KEY = os.environ.get("TICKDB_API_KEY")

def on_message(ws, message):
    data = json.loads(message)
    if data.get("type") == "depth":
        print(f"Bid: {data['bid']} | Ask: {data['ask']} | Spread: ${data['ask'] - data['bid']:.4f}")

def on_error(ws, error):
    print(f"WebSocket error: {error}")

def on_close(ws, close_status_code, close_msg):
    print(f"Connection closed: {close_status_code} {close_msg}")

ws = websocket.WebSocketApp(
    "wss://api.tickdb.ai/ws/depth?api_key=" + API_KEY,
    on_message=on_message,
    on_error=on_error,
    on_close=on_close
)

# Subscribe to AAPL depth updates
subscribe_msg = {"cmd": "sub", "symbol": "AAPL.US"}
ws.send(json.dumps(subscribe_msg))
ws.send(json.dumps({"cmd": "ping"}))  # Heartbeat

ws.run_forever(ping_interval=30)

The order book provides:

  • Bid/ask spread dynamics — spread widening as a signal of liquidity stress
  • Buy/sell pressure ratios — aggregate bid size vs. ask size at the top of book
  • Order book imbalance — changes in depth ratio as a leading indicator

For many quantitative strategies, order book dynamics at Level 1 are more informative than individual trade ticks.

3. Cross-Asset Event Detection

For event-driven strategies (earnings, macroeconomic releases, index rebalances), the combination of OHLCV history + real-time depth data enables:

  • Pre-event volatility surface analysis using historical klines
  • In-event liquidity monitoring via depth channel
  • Post-event mean reversion detection using candle close patterns

This workflow does not require tick-level trade data.

Honest Comparison: When You Actually Need Tick Data

There are legitimate use cases where tick data is the correct tool. Being transparent about this is part of making good tool-selection decisions.

Use Case Data Needed TickDB Suitable?
Long-term backtesting (daily/weekly rebalance) OHLCV ✅ Yes
Intraday mean reversion (5-min candles) OHLCV ✅ Yes
Order book imbalance strategies Depth (L1+) ✅ Yes
Latency arbitrage (< 100 µs) Tick (raw) ❌ No — requires HFT infrastructure
Market maker quote management Tick + Depth ⚠️ Partial — depth L1 available
Order flow toxicity analysis Tick (with trade direction) ❌ No
Quote stuffing detection Tick (high frequency) ❌ No
VPIN / order splitting detection Tick (with size) ❌ No

If your strategy requires tick-level directional data, order flow toxicity metrics, or sub-millisecond latency, then TickDB is not the right tool. Polygon, Databento, and exchange-native feeds are the appropriate vendors.

How to Use TickDB and Tick Data Together

A common pattern among professional quant teams is multi-vendor data architecture:

  • TickDB for: cross-asset OHLCV history, real-time depth, multi-asset unified API, clean backtest-ready data
  • Polygon / Databento / Alpaca for: US equity tick data, real-time trades, options data

This is not a flaw in TickDB's design. It is the correct engineering approach: use the best tool for each specific data requirement, and normalize the data in your own pipeline.

# Example: Combining TickDB depth with third-party tick data
import os
import requests
import json

# Step 1: Get historical context from TickDB (clean, reliable OHLCV)
headers = {"X-API-Key": os.environ.get("TICKDB_API_KEY")}
kline_response = requests.get(
    "https://api.tickdb.ai/v1/market/kline",
    headers=headers,
    params={"symbol": "AAPL.US", "interval": "1d", "limit": 100},
    timeout=(3.05, 10)
)

# Step 2: Use third-party tick data for order flow analysis
# (Implementation depends on your tick data vendor)
# tick_data = polygon_client.get_ticks("AAPL", ...) 

# Step 3: Combine in your strategy engine
# Your backtest runs on TickDB data; your live execution references tick data

The Honest Summary

Here is the direct answer to the original question:

TickDB does not support US equity tick data because it is not the right tool for TickDB's product mission, and the infrastructure cost would degrade the platform's core offerings.

This is not a technical oversight. It is a deliberate product decision that prioritizes:

  • Multi-asset OHLCV coverage over single-market depth
  • Clean, validated historical data over high-frequency raw streams
  • Developer experience over feature count

If you need tick data: use a platform built for tick data. If you need multi-asset OHLCV, real-time depth, and a unified API across 6 asset classes: use TickDB. If you need both: use both.

The best quantitative systems are built by engineers who choose tools for the right reasons, not the most features.

Next Steps

If you need US equity tick data specifically, Polygon, Databento, and Alpaca offer competitive tick data products with varying latency and cost profiles.

If you need multi-asset historical data for backtesting, TickDB's /v1/market/kline endpoint provides 10+ years of cleaned OHLCV across US stocks, Hong Kong stocks, A-shares, crypto, forex, and commodities — all through a single unified API.

If you are building an institutional-grade data pipeline, consider a multi-vendor architecture that combines TickDB's historical and depth data with a dedicated tick data provider.

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