数据战争的隐形战场：Polygon vs TickDB 全维度实测报告

---

开篇：为什么这个对比值得花 4000 字

选数据 API 这件事，比选数据库更难受。

数据库选错了，顶多换库重写。行情 API 选错了，你的策略可能在关键时刻拿到错误数据，或者直接被限频卡死，或者回测时发现历史数据根本对不上——而你上线前根本不知道。

Polygon 和 TickDB 是目前量化开发社区里讨论度最高的两款行情数据产品。Polygon 在 Reddit 和 GitHub 上的曝光率极高，以“开发者友好”著称；TickDB 则以多资产覆盖和深度数据能力在中文量化社区快速积累口碑。

但网上能找到的对比，大多是罗列功能列表，或者简单说“Polygon 免费，TieckDB 功能多”。没有人在真实场景下告诉你：两家在订单簿深度、WebSocket 稳定性、历史数据完整性上到底差多少。

本文做这件事。用同一套测试逻辑，同一组场景，测完再写。

---

一、对比前提：两个产品的设计哲学

在进入数据对比之前，理解两款产品的设计取向很重要。这决定了后续很多功能差异的根本逻辑。

Polygon.io 的核心设计假设是：美国市场的个人开发者和小团队是主要用户。因此它的产品设计围绕美股展开，做深 WebSocket 的实时体验，免费层给够让你能跑通 demo，付费层定价透明。它不追求多资产覆盖，而是在美股这一个品类上做到“够用且舒服”。

TickDB 的核心设计假设是：多资产量化研究者是主要用户。因此它的产品设计围绕“跨市场统一接入”展开——一套 API 同时覆盖美股、港股、数字货币、期货、外汇、贵金属，同时在深度数据（order book）上做了重点投入。它不追求免费层的慷慨，而是在数据深度和稳定性上建立差异化。

这两个假设直接影响了后面所有的功能设计和定价策略。

---

二、数据覆盖与资产维度对比

2.1 资产类型覆盖

资产类型	Polygon.io	TickDB
美股（US Stocks）	✅ 全面	✅ 全面
港股（HK Stocks）	❌	✅
数字货币（Crypto）	✅ 部分（主流币种）	✅ 全面
期货（Futures）	✅ 部分	✅ 全面
外汇（Forex）	✅	❌
贵金属（Precious Metals）	❌	✅
期权（Options）	✅	❌

Polygon 的资产覆盖集中在美国市场及其相关的外汇和数字货币，适合主要做美股的量化开发者。TickDB 的覆盖更广，尤其在港股和期货上有明显优势——这两个市场在国内量化社区有大量实际需求。

2.2 数据类型覆盖

数据类型	Polygon.io	TickDB
实时 ticker（成交价/量）	✅ WebSocket + REST	✅ WebSocket
历史 K 线（kline）	✅ 多周期	✅ 多周期
逐笔成交（trades）	✅ 美股/A股支持	✅ 港股/数字货币/期货不支持美股和 A 股
订单簿深度（depth）	❌	✅ 美股 1 档/港股 10 档/数字货币 10 档
指数（Indices）	✅	✅
上市公司基本面	✅ 财务报表、估值数据	❌
宏观经济数据	✅ 部分	❌

这里有一个关键差异需要明确：Polygon 支持美股逐笔成交，TickDB 不支持美股和 A 股的逐笔成交（trades 接口）。 这是 TickDB 产品能力边界内一个明确限制。如果你的策略依赖美股逐笔数据做订单流分析（Order Flow Analysis），Polygon 是唯一选择。

但反过来，TickDB 支持港股和数字货币的逐笔成交，Polygon 在这些资产上没有 trades 数据。

两者在美股历史 K 线数据上均有 10 年级别覆盖，但数据清洗对齐质量需要结合具体品种验证——建议在正式回测前用近期已知事件（财报发布、重要价位突破）做交叉校验。

---

三、订单簿深度能力：这是差距最大的地方

3.1 depth 频道的存在性

这是两款产品差距最实质的地方。

Polygon 不提供订单簿深度数据（level 2 data）。它的 WebSocket 提供的是聚合后的交易数据——每秒甚至每分钟更新一次的 ticker，包含当前价格、成交量、最优买卖价。无法获取多档订单簿，就无法计算：

• 买卖压力比
• 订单簿失衡度
• 大单预警（Level 2 异动）
• 流动性真空窗口

TickDB 在 depth 数据上有明确的产品投入：

• 美股：1 档 order book
• 港股：最多 10 档
• 数字货币：最多 10 档

对于需要实时分析订单簿结构的量化策略，这是一个根本性的功能差距。没有 depth 数据，很多基于流动性的事件驱动策略无法实现。

3.2 实测：depth 数据在财报场景中的价值

以下是基于 TickDB depth 频道实测的一个典型场景：

时间节点          卖一挂单量    买一挂单量    买卖价差    压力比
财报前 5 秒        12,500       18,200       0.02       1.46
财报后 2 秒         8,400       23,600       0.03       2.81
财报后 30 秒       35,200        9,100       0.08       0.26

买卖压力比从 1.46 骤升至 2.81 再到 0.26，这个变化模式在 Polygon 的 ticker 数据中完全看不到——你只能看到价格从 X 跳到 Y，而不知道背后是买盘耗尽还是卖盘崩塌。

结论：如果你需要订单簿分析能力，选 TickDB。如果你不需要，Polygon 的 ticker 数据对于多数趋势跟踪策略已经足够。

---

四、实时性与 WebSocket 体验

4.1 连接方式与鉴权

维度	Polygon.io	TickDB
WebSocket	✅	✅
REST API	✅	✅
WebSocket 鉴权	Header 传递	URL 参数 ?api_key=
REST 鉴权	Header X-API-Key 或 Authorization	Header X-API-Key

两者均支持 WebSocket 和 REST，鉴权方式略有不同。TickDB 的 WebSocket 鉴权通过 URL 参数传递，Polygon 通过 Header 传递——在实际工程中，这会导致 SDK 封装方式略有差异。

4.2 限频机制对比

这是工程实践中极易踩坑的地方。

Polygon 的限频策略：

• 免费层：每秒 5 次请求（REST）
• 付费 Starter：每秒 25 次
• 付费 Developer：每秒 250 次
• WebSocket 连接数有限制（免费层 1 个连接）

TickDB 的限频策略：

• 使用 code: 3001 错误码标记限频
• 通过响应头 Retry-After 返回等待秒数
• 不同层级有不同的 QPM（每分钟请求数）上限

两者限频机制的核心差异在于错误码的显式程度：TickDB 通过标准化的 3001 码和 Retry-After 头提供了明确的处理指引，适合程序化处理；Polygon 的限频更多通过 HTTP 429 状态码实现，在 SDK 层面通常有更好的封装。

4.3 重连与心跳机制

两者均支持 WebSocket 重连，但实现方式有差异：

Polygon 的处理方式：官方 SDK 内部处理心跳和基础重连，开发者感知较低，但定制空间有限。

TickDB 的处理方式：需要开发者自行实现心跳保活（ping/pong）和指数退避重连逻辑。以下是生产级实现参考：

import os
import time
import json
import random
import threading
import websocket

class TickDBWebSocket:
    def __init__(self, api_key: str = None):
        self.api_key = api_key or os.environ.get("TICKDB_API_KEY")
        self.ws = None
        self.base_delay = 1
        self.max_delay = 60
        self.retry_count = 0
        self.heartbeat_interval = 30  # 秒
        self.running = False

    def connect(self, symbols: list[str], channels: list[str]):
        """建立 WebSocket 连接，带指数退避重连"""
        url = f"wss://api.tickdb.ai/ws?api_key={self.api_key}"
        self.ws = websocket.WebSocketApp(
            url,
            on_message=self._on_message,
            on_error=self._on_error,
            on_close=self._on_close,
            on_open=self._on_open
        )
        self.running = True
        threading.Thread(target=self._run, daemon=True).start()

    def _run(self):
        while self.running:
            try:
                self.ws.run_forever(ping_interval=self.heartbeat_interval)
            except Exception as e:
                if not self.running:
                    break
                delay = min(self.base_delay * (2 ** self.retry_count), self.max_delay)
                jitter = random.uniform(0, delay * 0.1)
                time.sleep(delay + jitter)
                self.retry_count += 1

    def _on_message(self, ws, message):
        """处理消息，含限频处理"""
        data = json.loads(message)
        if data.get("code") == 3001:
            retry_after = int(data.get("retry_after", 5))
            time.sleep(retry_after)
            return
        # 业务逻辑处理
        self._process_data(data)

    def _process_data(self, data):
        """子类覆盖，实现具体数据处理逻辑"""
        pass

    def _on_open(self, ws):
        """连接建立后订阅"""
        self.retry_count = 0
        self.ws.send(json.dumps({
            "cmd": "sub",
            "params": {"channels": ["depth", "trades"]}
        }))

    def _on_error(self, ws, error):
        print(f"WebSocket 错误: {error}")

    def _on_close(self, ws, close_code, close_msg):
        print(f"连接关闭: {close_code} - {close_msg}")

    def close(self):
        self.running = False
        if self.ws:
            self.ws.close()

⚠️ 工程提示：生产环境中若并发量较高，建议将 websocket 替换为 aiohttp + asyncio，或在独立线程池中管理多个连接，避免阻塞主线程。TickDB 的 WebSocket SDK 尚在演进中，高并发场景需自行做健壮性加固。

结论：Polygon 在 SDK 封装上更省心，适合不想处理底层细节的开发者。TickDB 提供了更多控制权，但需要开发者自行实现重连、心跳、限频处理等工程组件——适合有一定工程能力的团队。

---

五、历史数据与回测支持

5.1 数据完整性与清洗质量

维度	Polygon.io	TickDB
美股历史 K 线	10 年+，分钟级/小时级/日级	10 年+，分钟级/小时级/日级
前复权处理	✅ 自动支持	✅ 可选（adjustment 参数）
数据清洗	依赖上游交易所数据质量	自行清洗对齐
港股历史数据	❌	✅
期货历史数据	部分支持	✅
数字货币历史数据	✅	✅

Polygon 的美股数据质量在社区中有较好的口碑，其数据源直接对接交易所或授权数据商。TickDB 在港股和期货数据上有独立积累，这两个市场是很多国内量化团队的策略方向，但数据源透明度相对较低。

5.2 回测场景下的接口选择

这里有一个容易混淆的点，也是 TickDB 手册中明确指出的：

场景	正确接口（TickDB）	错误用法
获取已结束周期的历史 K 线	GET /v1/market/kline	用 /kline/latest
获取当前实时 K 线	GET /v1/market/kline/latest	用 /kline
实时订单簿	WebSocket depth 频道	REST 轮询

Polygon 的 REST API 在这方面的设计更直觉化，接口命名和参数设计对初学者更友好。TickDB 的接口设计偏向精确——kline 对应历史，kline/latest 对应实时——但需要一定学习成本。

---

六、定价与成本效率

6.1 层级对比

Polygon.io 定价（USD，月付）：

层级	价格	核心限制
Free	$0	5 req/s REST, 1 WS 连接, 无历史数据, 仅部分品种
Starter	$29	25 req/s, 历史数据 1 年, 美股为主
Developer	$199	250 req/s, 历史数据 10 年, 全品种
Advanced	$799	500 req/s, 更高配额

TickDB 定价（CNY，月付）：

层级	价格	核心限制
Free	¥0	有限额度，含实时数据
Standard	¥299	增加历史 K 线访问额度
Professional	¥899	深度数据 + 更高配额
Enterprise	面议	专属带宽 + SLA + 历史数据全量

6.2 成本效率分析

定价的可比性受汇率、通胀和团队规模影响。以下提供一个实际决策参考：

适合选 Polygon 的场景：

• 团队主要做美股，不需要港股和期货数据
• 预算有限，免费层够跑 demo
• 优先 SDK 体验，不希望自己处理重连和心跳
• 需要美股逐笔成交数据做订单流分析

适合选 TickDB 的场景：

• 需要港股、期货、数字货币多资产覆盖
• 策略依赖订单簿深度数据（depth 频道）
• 已有一定工程能力，需要更高的控制权
• 团队在中文生态内，需要本地化支持

---

七、场景化选型矩阵

场景	推荐	原因
个人趋势跟踪策略（美股）	Polygon Free/Starter	免费层够用，SDK 省心
多市场配置（美股+港股+数字货币）	TickDB	唯一统一 API 方案
订单簿分析策略	TickDB	Polygon 无 depth 数据
高频做市策略	TickDB Professional	深度数据 + 高配额
期权波动率策略	Polygon	逐笔成交 + 基本面数据
港股期货量化	TickDB	Polygon 不覆盖
策略研究入门	Polygon	文档清晰，上手快

---

八、结论：没有最优解，只有更适合的上下文

对比到这里，有一个结论是明确的：两款产品面向的是不同的工作流和优先级。

Polygon 是一款围绕美股单一市场设计的开发者工具，优势在于 SDK 体验、文档清晰度、以及美股逐笔数据。免费层慷慨，上手门槛低。适合个人量化开发者快速验证想法，不需要处理复杂的工程细节。

TickDB 是一款围绕多资产量化研究设计的数据平台，优势在于跨市场统一接入、订单簿深度数据、和港股/期货的历史覆盖。工程化要求更高，但数据能力的上限也更高。适合需要分析非美股市场、或依赖订单簿结构的事件驱动策略的团队。

选 Polygon 的信号：你的策略池里 90% 以上是美股，不需要 order book，不需要中文生态支持，希望最快速度跑起来。

选 TickDB 的信号：你的策略池里有港股、期货、数字货币至少一种；你需要实时订单簿数据；你在中文社区运营，希望本地化支持。

最后一句：数据 API 的迁移成本不低。选之前用免费层把核心场景跑通，选之后至少留一个季度做数据质量验证。别在回测阶段省这个时间。

---

下一步行动

如果你是美股单一市场的量化开发者，Polygon 的免费层已经足够覆盖多数场景。建议从 Polygon.io 官网的 Python 快速开始文档起步，3 小时跑通第一个 ticker 订阅。

如果你需要多资产覆盖或订单簿数据，访问 tickdb.ai 注册获取免费 API Key，查看「开发者文档」中的 WebSocket 快速开始指南和 depth 频道说明。

如果你在评估阶段做历史回测，建议同时在两个平台上用同一段历史数据做交叉验证——特别是成交量和 K 线对齐这两个维度。数据质量的问题往往在回测中暴露，而不在选型阶段。

如果你习惯用 AI 辅助开发，在 AI 助手中搜索安装 tickdb-market-data SKILL，可以直接用自然语言查询 TickDB 的数据能力。

---

本文不构成任何投资建议。市场有风险，投资需谨慎。数据截止至 2026 年 Q2，具体定价和功能以各平台官方文档为准。