目錄

• 怎麼評估一個分析資料庫(真正重要的標準)
• 比較表
• 逐項分析

  • DuckDB —— 更多人應該最先考慮的對手
  • StarRocks —— 如果你的資料是正規化的,認真的替代
  • Apache Druid —— 強大但維運昂貴
  • Apache Pinot —— 面向使用者分析之王
  • TimescaleDB(TigerData)—— 不強迫你遷移的替代
  • BigQuery 和 Snowflake —— 零維運,帳單可變
  • 特別提名:Apache Doris 和 Tinybird
• 結論:按你的情況選什麼
• 我選錯後學到的東西
• 結論
• 常見問題

  • ClickHouse 最好的替代是什麼?
  • ClickHouse 還是 DuckDB?
  • ClickHouse 還是 BigQuery?
  • StarRocks 比 ClickHouse 好嗎?
  • Apache Druid 在 2026 年還值得嗎?

怎麼評估一個分析資料庫(真正重要的標準)

在表格之前,先把軸定下來。我見過太多人按 benchmark 選、又因為維運後悔的。

真實維運成本。 不是授權價格——大多數是開源的——而是你每個月要花多少小時保它活著。這是單幹時權重最大的標準,也是比較文章裡最看不見的標準。

部署模式。 一個二進位?一個六種行程的叢集?只能用雲託管?這決定了你能不能在一台 20 歐的 VPS 上起步,還是需要 Kubernetes。

接入延遲。 一個事件多久之後能被查到?秒、分鐘還是小時。只有你真的需要即時的時候才重要;很多人以為自己需要,其實並不。

並發。 能扛多少同時查詢?做面向客戶的產品內分析時是關鍵;如果是三個內部人看的 dashboard,無關緊要。

規模化時的成本模型。 按用量計費(BigQuery、Snowflake)對比固定伺服器(自架 ClickHouse)。前者在用量低時很美好,在有人開著 dashboard 自動刷新時很恐怖。

生態和驅動成熟度。 如果你疊的是 Python 或 Node,有沒有官方用戶端?連 Metabase 或 Grafana 痛不痛苦?

比較表

讀這張表時請知道,每個儲存格都是簡化,細節在後面的小節裡。

	ClickHouse	DuckDB	StarRocks	Apache Druid	Apache Pinot	TimescaleDB	BigQuery / Snowflake
型別	分散式欄式 OLAP	嵌入式(行程內)OLAP	欄式 MPP OLAP	即時 OLAP	即時 OLAP	PostgreSQL 延伸	託管雲數倉
授權	Apache 2.0	MIT	Apache 2.0	Apache 2.0	Apache 2.0	Apache 2.0 / TSL	專有
最小部署	1 個二進位	1 個程式庫	Frontend + Backend 節點	6 種行程 + ZooKeeper	Controller、Broker、Server + ZooKeeper	Postgres + 延伸	僅 SaaS
維運難度	低—中	無	中	高	高	很低	無(你付錢)
彙總查詢效能	極佳	極佳(單節點)	極佳	很好	很好	好	好—很好
複雜 JOIN	很好	極佳	極佳(它的強項)	有限	有限(在改善)	極佳(它是 Postgres)	極佳
串流接入	好(Kafka engine、MV)	不適用	好	極佳	極佳(它的強項)	好	中(批次優先)
接入—查詢延遲	秒	不適用	秒	亞秒	亞秒	即時	分鐘
高並發	很好	低(一個行程)	很好	好	極佳	中	好但貴
UPDATE / DELETE	有限(輕量 mutation)	是	是(它的強項)	非常有限	非常有限	完整	是(代價高)
SQL 方言	自有、大幅擴充	Postgres 相容	MySQL 相容	自有 SQL	自有 SQL	純 PostgreSQL	標準 SQL
實用規模	TB—PB	GB—幾百 GB	TB—PB	TB—PB	TB—PB	GB—幾十 TB	PB
成本模型	固定伺服器	免費(跑在你的行程裡)	固定伺服器	固定伺服器(貴)	固定伺服器(貴)	固定伺服器	按用量
對單幹獨立開發者的契合度	✅ 是	✅ 是	⚠️ 要費力	❌ 否	❌ 否	✅ 是	⚠️ 帳單風險

逐項分析

DuckDB —— 更多人應該最先考慮的對手

DuckDB 是一個行程內分析資料庫:沒有伺服器,作為程式庫跑在你的應用裡,就像分析版 SQLite。pip install duckdb 你就拿到一個向量化欄式引擎。

明確贏的地方: 絕對的簡潔。零維運、零連接埠、零備份要設。直接查 Parquet 和 CSV,原生整合 pandas 和 Polars,SQL 方言相容 PostgreSQL,所以你不用學新語法。對本地資料分析、notebook、ETL、或小型應用的分析後端,很難被打敗。

輸的地方: 它本質上是一個行程。不為幾十個並發使用者提供資料,不水平擴充,不是為接收多源持續寫入的共享服務設計的。如果你需要那些,MotherDuck 作為雲層存在,但那時你已經進入另一種模型了。

我的看法: 如果你的資料集裝得下一塊磁碟,而查詢是你的後端或你自己從 notebook 發起的,先從 DuckDB 起,而不是 ClickHouse。這是大家最抗拒、又最常是對的的推薦。複雜度是「沒有它就會痛」的時候才加上去的。

實用的邊界是你需要一個服務而不是一個程式庫的時候:多個寫入方、多個並發讀取方、資料在一台機器上放不下、要保留數年。那裡你跨到 ClickHouse。

StarRocks —— 如果你的資料是正規化的,認真的替代

StarRocks 是一個欄式 MPP 資料庫,與 ClickHouse 共享很多理念,但在兩個關鍵點上不同。

贏的地方: 多表 JOIN 和即時更新。StarRocks 從一開始就假設你會查詢正規化的星狀 schema,有一個成熟的、基於成本的 JOIN 重排最佳化器。如果你來自傳統數倉、有事實表和維度表、又不想全部反正規化,它更合適。它還相容 MySQL 協定,意味著任何 MySQL 用戶端都能不用特殊驅動就連上。

輸的地方: 生態和社群比 ClickHouse 小。現成的整合少,半夜兩點出問題時 Stack Overflow 上的答案少,已經熟悉它的工程師少。而且最小安裝涉及兩種節點(frontend 和 backend),不是一個二進位。

我的看法: 它是技術上最能和 ClickHouse 對標的替代。如果你的負載是「很多 JOIN 和頻繁更新的數倉」,認真評估它。如果你的負載是「我按時間彙總的事件洪流」,ClickHouse 仍然更簡單、上線更快。

Apache Druid —— 強大但維運昂貴

Druid 多年在大規模做即時時序分析,而且做得好。它的架構是為從 Kafka 接入並即時可查而精調的。

贏的地方: 亞秒延遲的串流接入,以及「熱」資料(近期、在記憶體)和「冷」資料(歷史、在深度儲存)之間的清晰分離。對於長期保留的大規模監控使用情境,這個設計是有道理的。

輸的地方: 維運複雜度。Druid 需要 Coordinator、Overlord、Broker、Router、Historical 和 MiddleManager,加上協調用的 ZooKeeper 和 metadata store。這是六種行程加兩個外部依賴。它是一個需要專職人員的叢集。而且 JOIN 仍是它的弱項,資料模型也較不靈活。

我的看法: 對獨立開發者或小團隊,Druid 直接不可行。不是因為技術差——它不差——而是因為它的維運成本除非在非常大的規模上,否則攤不回來。值得一提的是,包括 Lyft 在內的幾家知名公司都以「降低成本、簡化架構」為由,從 Druid 遷到了 ClickHouse。

Apache Pinot —— 面向使用者分析之王

Pinot 誕生於 LinkedIn,為給數億使用者提供「誰看了你的檔案」。這種 DNA 很明顯:它針對超高並發下的毫秒延遲做了最佳化。

贏的地方: 如果你在產品裡做一個分析功能,幾千使用者同時查、延遲 SLA 嚴格,Pinot 有最專門為此設計的架構。星狀索引、倒排索引、為這種模式調校的分區。

輸的地方: 和 Druid 一樣,維運複雜度高(Controller、Broker、Server,加 ZooKeeper)。對探索性臨機查詢不夠靈活:它在你事先知道查詢模式、能為它們建索引時發光,而不是在你想探索時。

我的看法: 對一個很具體、而小專案幾乎沒有的問題來說,是優秀工具。如果你不是在給超過一千個並發使用者提供分析,ClickHouse 用 20% 的複雜度給你 90% 的結果。

TimescaleDB(TigerData)—— 不強迫你遷移的替代

TimescaleDB 是 PostgreSQL 針對時序的延伸。2025 年 6 月公司改名為 TigerData,但開源延伸仍叫 TimescaleDB。

贏的地方: 它就是 PostgreSQL。你的全部知識、你的驅動、你的工具、你的備份、你的 ORM、你和應用表的 JOIN,全部繼續運作。它加上「hypertable」(按時間自動分區)、連續彙總和欄式壓縮。而且因為是 Postgres,你有完整 ACID 交易和無痛的 UPDATE/DELETE。

輸的地方: 在超大體量彙總上的效能不在 ClickHouse 那個級別。它底下還是 Postgres,帶著一個用欄式壓縮打補丁的列式引擎的限制。在幾十 TB 上,差距很明顯。

我的看法: 被追新的人低估了。如果你已經在用 Postgres、資料是時序、問題是幾十或幾百 GB 而不是 TB,TimescaleDB 大概是你能做的性價比最高的決定。你用一個延伸而不是一個新服務做遷移。你不加的複雜度,就是你不用維護的複雜度。

BigQuery 和 Snowflake —— 零維運,帳單可變

託管雲數倉徹底消除維運問題。沒有伺服器,沒有升級,沒有備份。你寫 SQL,然後付錢。

贏的地方: 幾乎無限擴充而不用想基礎架構,與雲生態其他部分深度整合,以及在資料治理、權限和合規上巨大成熟度。如果你是一家有預算、希望團隊專注業務的公司,這是一個說得過去的決定。

輸的地方: 定價模型。你按掃描資料量(BigQuery)或運算時間(Snowflake)付錢,而兩種模型都正好懲罰互動式分析的典型模式:大量頻繁的小查詢。每 30 秒自動刷新的 dashboard 可能產生不成比例的帳單。而且查詢延遲很少降到幾百毫秒到秒以下,使它們不適合嵌入到產品裡的分析。

我的看法: 對 bootstrap 的專案,帳單可變的風險是業務風險,不是技術風險。我見過 BigQuery 成本超過其他所有基礎架構加在一起專案。一台用 ClickHouse 的專屬伺服器成本已知且平穩,這在你的帳單不多時很有價值。合理例外:如果你的資料已經在 Google Cloud、查詢量低且零星,BigQuery 可能比維護一台伺服器更便宜。

特別提名:Apache Doris 和 Tinybird

Apache Doris 和 StarRocks 非常相似(同源),出於同樣理由值得一看。Tinybird 是建在 ClickHouse 之上的託管層,在你的查詢上加 API——如果你想要 ClickHouse 又不想維運、還想加一層產品,值得一試。

結論:按你的情況選什麼

把上面翻譯成具體推薦。

你在 notebook 裡探索資料,或不到 50 GB —— DuckDB。 沒得討論。零維運、出色效能、熟悉的 SQL。

你已經在用 PostgreSQL,資料是時序的,量級是幾十 GB —— TimescaleDB。 你加的是一個延伸而不是一個服務。最無聊、大概也最正確的選項。

你有事件洪流、想自架、單幹或小團隊 —— ClickHouse。 效能和維運複雜度的最佳點。VPS 上的一個二進位能扛下大多數專案永遠用不到的量。

你在產品裡給幾千並發使用者做分析 —— 先 ClickHouse,不夠再 Pinot。 從簡單開始;只有 SLA 真的需要時才遷。

你的 schema 是個帶很多 JOIN 和更新的正規化數倉 —— StarRocks。 它的 JOIN 最佳化器是它對 ClickHouse 的真正優勢。

你有預算、有團隊、想要零基礎架構 —— BigQuery 或 Snowflake。 從第一天就設好成本告警。

你需要超大規模的亞秒接入、有專職 SRE —— Druid 或 Pinot。 如果你沒有專職 SRE,這一行不是給你的。

我選錯後學到的東西

我有兩次選了最強大的工具而不是最合適的,兩次都付了代價。

第一次,我給一個有 1200 萬筆的專案搭了個叢集。1200 萬。DuckDB 本來能從一個檔案毫秒級回答那些查詢。我花了一個週末設定了一個解決我並沒有的問題的東西。

第二次我按 benchmark 選。資料庫 benchmark 測的是實驗室條件下的查詢延遲;它們測不出你會花多少小時除錯接入,也測不出社群小到你的錯誤哪兒都搜不到有多痛。一個資料庫的真實成本是它偷走你的時間,而不是它替你省下的毫秒。

我現在的標準,按順序:第一,選能解決你今天問題的最簡單選項;第二,驗證它有清晰的退路(你能匯出成 Parquet 嗎?);第三,只有那時候才看效能。如果最簡單的選項在一年內撐不住,你到時候再遷——而到那時你會更清楚自己需要什麼。

結論

沒有「最好的 OLAP 資料庫」。只有對你的資料量、你的團隊、你的預算最好的那一個,而對大多數小專案,這個答案是 DuckDB 或 ClickHouse,而不是更複雜的選項。

ClickHouse 在這個圖景裡占據一個非常特殊的位置:分散式系統的效能,加上單體應用的維運複雜度。這種組合很罕見,這也是為什麼當專案已經長到超過 DuckDB 能給的,它仍然是我的預設選項。

如果你已經決定用 ClickHouse,下一步是真正把它用好:ClickHouse 進階指南 講具體化檢視、projection、編碼,以及把平庸的 ClickHouse 和快的 ClickHouse 區分開的一切。如果你還沒裝,先看 ClickHouse 是什麼、怎麼安裝。

---

常見問題

ClickHouse 最好的替代是什麼?

看情況。裝得下一台機器的資料集用 DuckDB,需要複雜 JOIN 和頻繁更新用 StarRocks,已經在用 PostgreSQL 就用 TimescaleDB,優先最低延遲加超高並發就用 Apache Pinot。

ClickHouse 還是 DuckDB?

資料裝得下一塊磁碟、查詢由單一行程發起,用 DuckDB。需要共享服務、多源並發寫入、或要擴充到一台機器之外,用 ClickHouse。

ClickHouse 還是 BigQuery?

想要平穩可預測的成本和毫秒級延遲,用 ClickHouse;寧願零維運、查詢量低且零星、資料已經在 Google Cloud,用 BigQuery。

StarRocks 比 ClickHouse 好嗎?

在多表 JOIN 和即時更新上,一般是。在部署簡單、社群規模和整合生態上,ClickHouse 保持優勢。

Apache Druid 在 2026 年還值得嗎?

在有專職基礎架構團隊的非常大規模上,值得。對中小專案,它的維運成本很少能對 ClickHouse 證明自己。