ClickHouse vs Postgres cho analytics: điểm hòa vốn thực sự

Nếu bảng Postgres của bạn chưa đến 50 triệu dòng, không cần đọc tiếp — Postgres với index đúng cách là đủ. Từ 100 triệu dòng trở lên, ClickHouse bắt đầu thắng rõ rệt: nhanh hơn 8× đến 361× trên các câu query analytical, lưu trữ ít hơn 10× trên cùng dataset. Chi phí vận hành là có thật. Bài này phân tích điểm hòa vốn nằm ở đâu và quá trình migration trông như thế nào.

Bài này dành cho ai

Các team kỹ thuật đang chạy analytics trên bảng Postgres từng nhanh và giờ không còn nhanh nữa. Hoặc các team đang lên kế hoạch cho event pipeline sẽ đạt 100M+ dòng trong năm nay và muốn tránh một cuộc migration đau đớn về sau.

Nếu mối quan tâm chính của bạn là tính toàn vẹn giao dịch, JOIN phức tạp trên schema chuẩn hóa, hoặc team dưới năm người không có data engineer chuyên trách — ở lại với Postgres. Phần kết luận có ma trận đầy đủ.

ClickHouse là gì

ClickHouse là database column-store được xây dựng cho OLAP. Điểm khác biệt cốt lõi so với Postgres: thay vì lưu từng hàng thành một đơn vị, ClickHouse lưu từng cột thành một đơn vị. Câu query SUM(revenue) không bao giờ đọc user_agent hay session_id — nó chỉ đọc đúng những bytes cần thiết.

Storage engine mặc định là MergeTree. Dữ liệu được ghi xuống disk dưới dạng columnar parts và liên tục được merge nền. Deduplication, pre-aggregation, và TTL expiration đều xảy ra trong quá trình background merge, không phải tại thời điểm query. Đánh đổi: đọc rất nhanh, nhưng ghi thực tế là append-only. Cập nhật từng dòng là batch rewrite, không phải point mutation.

ClickHouse cũng áp dụng nén LZ4 theo mặc định, với các codec tùy chọn theo domain (Delta cho timestamp, Gorilla cho số thực). Cùng dataset 100M dòng tốn ~100 GiB trên Postgres thì chỉ tốn ~9.26 GiB trên ClickHouse — nén khoảng 10×, đo trên dataset ClickBench (99,997,497 dòng, AWS c6a.4xlarge, ClickHouse 25.7 so với PostgreSQL 17.5).

So sánh trực tiếp

Tốc độ truy vấn

Micro-benchmark từ fiveonefour.com chạy workload 4 câu query analytical (aggregation, statistics, sampling) trên dữ liệu theo dõi máy bay qua 100 lần lặp. Cả hai database trên Docker container tương đương 4 GB / 2 CPU:

Số dòng	ClickHouse	Postgres + index	Kết quả
10K	27.9 ms	12.9 ms	Postgres (2.2×)
50K	75.5 ms	60.5 ms	Ngang nhau
1M	121.1 ms	1,067 ms	ClickHouse (8.8×)
10M	453 ms	7,595 ms	ClickHouse (16.8×)

Postgres thắng ở dataset nhỏ. Điểm giao thoa nằm khoảng 50K–100K dòng cho analytical workload. ClickHouse bứt xa từ đó trở đi.

Trên dataset giá nhà tại Anh (~5 triệu dòng), khoảng cách càng rõ hơn:

Query	Postgres	ClickHouse	Chênh lệch
Giá trung bình (5.01M dòng)	28,535 ms	79 ms	361×
Tra cứu postcode theo thành phố (424K dòng)	543 ms	77 ms	7×
Biến động giá London theo thời gian	8,904 ms	62 ms	144×

Với 5M dòng cho full-table aggregation, Postgres mất 28 giây. ClickHouse mất 79 ms. Đây không phải cải thiện biên — đây là một trải nghiệm hoàn toàn khác.

Lưu ý về schema design: benchmark fiveonefour phát hiện chỉ thay đổi thứ tự ORDER BY đã giúp một câu query ClickHouse giảm từ 4,191 ms xuống 75 ms trên 10M dòng — cải thiện 55× chỉ từ một thay đổi schema. Engine này thưởng cho schema đúng và phạt nặng nếu bạn thiết kế sai.

Throughput ghi dữ liệu

ClickHouse được xây dựng cho batch insert throughput cao. Hệ thống distributed tracing của Shopee ghi 3 triệu dòng mỗi giây trên 20 CPU core, tìm kiếm trên 30B+ dòng trong vài giây. Cloudflare ghi 11 triệu dòng mỗi giây vào ClickHouse cho HTTP và DNS analytics pipeline. Đây là số liệu production thực tế, không phải benchmark trong phòng lab.

Postgres xử lý bulk insert hiệu quả, nhưng ở quy mô lớn nó tụt lại: mỗi lần ghi phải duy trì MVCC state, WAL records, và cập nhật index song song. ClickHouse ghi vào columnar part trên disk và hoãn phần còn lại cho background merge.

Với workload append-only (event stream, log, metrics), đây là lý tưởng. Với workload cần UPDATE hoặc DELETE thường xuyên, mô hình batch-mutation của ClickHouse sẽ gây phức tạp.

Lưu trữ

Số liệu ClickBench trên cùng dataset 100M dòng:

ClickHouse: 9.26 GiB (LZ4 columnar)
PostgreSQL: ~100 GiB (row-store với TOAST mặc định)

Với 10 TB dữ liệu analytics trên Postgres, ClickHouse tương đương khoảng 1 TB. Chi phí lưu trữ tích lũy nhanh ở quy mô lớn.

JOIN và schema chuẩn hóa

Đây là điểm yếu của ClickHouse. Postgres xử lý schema chuẩn hóa và multi-table JOIN một cách tự nhiên. ClickHouse thiếu data shuffling cho large distributed JOIN — hơn 3–4 JOIN có thể gây RAM spike hoặc crash. Pattern chuẩn trong ClickHouse là denormalize thành wide flat tables trong quá trình ETL, nghĩa là data model trông hoàn toàn khác với schema chuẩn hóa của Postgres.

Nếu các câu query analytics của bạn dùng nhiều JOIN lồng nhau, bạn chỉ có hai lựa chọn: cơ cấu lại data model (tốn công) hoặc chịu phạt hiệu năng (tốn thời gian). Cả hai đều không miễn phí.

Độ phức tạp vận hành

Postgres là một daemon. ClickHouse trên single node vẫn quản lý được. ClickHouse phân tán đòi hỏi ClickHouse Keeper (một lớp coordination dựa trên Raft), monitoring riêng biệt, và mô hình vận hành khác.

Còn có khoảng cách về hệ sinh thái. Postgres có 30 năm tooling — pgAdmin, ORMs, Liquibase, PostgREST, và các đảm bảo ACID đã được kiểm chứng trong production. ClickHouse là một database thứ hai cần vận hành, không phải thay thế trực tiếp cho Postgres.

Postgres chưa hết bài

Trước khi chuyển sang ClickHouse, hãy xem Postgres có thể làm gì khi được tối ưu đúng cách:

Range partitioning + BRIN indexes: BRIN index chỉ tốn ~100 KB cho một cột timestamp. Kết hợp với time-based partitioning, range scan có thể bỏ qua toàn bộ partition theo tháng/năm mà không cần full table scan.
TimescaleDB: Nén columnar và automatic time partitioning ngay trong Postgres. Được ghi nhận cải thiện 1,000× trên time-series workload so với Postgres thuần.
pg_mooncake: Bảng columnstore bên trong Postgres. Đứng trong top 10 ClickBench tính đến 2025/2026.

Với TimescaleDB hoặc pg_mooncake, Postgres vẫn cạnh tranh được đến ~500M dòng cho time-series có cấu trúc tốt. Điểm hòa vốn không chỉ là số dòng — đó là số dòng kết hợp với độ phức tạp query, concurrency, và năng lực của team.

Phân tích điểm hòa vốn

Yếu tố	Ở lại với Postgres	Chuyển sang ClickHouse
Số dòng	< 50M	> 100M
Kiểu query	Point lookup, N dòng gần nhất, JOIN phức tạp	GROUP BY, COUNT DISTINCT, time-series aggregation
Kiểu dữ liệu	Schema chuẩn hóa, UPDATE/DELETE thường xuyên	Append-only events, logs, clickstream
Team	< 5 kỹ sư, không có data infra chuyên trách	5+ người với năng lực data/infra
SLA query	Dashboard dưới 5 giây là chấp nhận được	Yêu cầu dashboard dưới 1 giây
Ngân sách	Ưu tiên single-DB đơn giản	Có thể chịu được chi phí infra + bảo trì gấp 2×

Vùng 50M–100M dòng thực sự mơ hồ. Dưới 50M, overhead của ClickHouse lớn hơn lợi ích. Trên 500M dòng cho các query nặng về aggregation, ClickHouse thường là lựa chọn đúng. Ở khoảng giữa, hãy benchmark các query cụ thể của bạn trước khi quyết định.

Các phương án migration

Ghi song song

Ứng dụng ghi vào Postgres (nguồn dữ liệu chính xác) và ClickHouse (analytics layer) đồng thời. Triển khai đơn giản. Rủi ro: logic ghi phức tạp hơn, và sự phân kỳ khi gặp lỗi đòi hỏi logic đồng bộ lại.

CDC qua PeerDB hoặc ClickPipes

PeerDB (tự host) và ClickPipes (ClickHouse Cloud managed) đọc Postgres logical replication và đẩy thay đổi vào ClickHouse gần real-time. PeerDB đã di chuyển 1 TB dữ liệu Postgres trong 2 giờ. Cả hai đều xử lý replication INSERT, UPDATE, và DELETE.

Đây là phương án được khuyến nghị cho hầu hết các migration production. Postgres vẫn là hệ thống vận hành; ClickHouse phục vụ analytics layer.

Batch ETL

Export định kỳ từ Postgres (COPY hoặc custom query) → flatten/transform → bulk INSERT vào ClickHouse. Toolchain đơn giản hơn, nhưng có độ trễ. Chấp nhận được nếu analytics của bạn có thể chịu độ trễ 15 phút.

Truy vấn trực tiếp qua hàm `postgresql()`

Dành cho migration một lần hoặc đồng bộ không thường xuyên:

INSERT INTO clickhouse_table
SELECT * FROM postgresql('host:5432', 'mydb', 'events', 'user', 'password')
WHERE created_at > '2024-01-01'

Hữu ích để chuyển dữ liệu lịch sử mà không cần duy trì CDC pipeline lâu dài.

Kết luận

Dùng Postgres cho đến khi không còn dùng được nữa. Khi các query dashboard liên tục mất 5–10 giây trên 100M+ dòng và bạn đã thử partitioning và TimescaleDB, ClickHouse là bước tiếp theo phù hợp.

Trường hợp	Chọn
< 50M dòng, OLTP + OLAP hỗn hợp	Postgres
50M–500M dòng, time-series	Postgres + TimescaleDB (cân nhắc ClickHouse nếu query chậm)
> 100M dòng, nặng aggregation, append-only	ClickHouse
Schema chuẩn hóa với 5+ JOIN	Postgres — ClickHouse sẽ khiến bạn khổ
Analytics pipeline chuyên biệt với team hỗ trợ	ClickHouse
Team nhỏ, cần single-DB đơn giản	Postgres

Kết quả thực tế đều khớp với ma trận này. Skool giảm từ vài phút xuống vài giây trên 100M+ dòng/ngày mà không cần tối ưu thêm. PostHog đã rời bỏ Postgres sau khi nó không còn chịu được quy mô. Reco loại bỏ 90% workload Postgres và giảm chi phí. Shopee tìm kiếm trên 30B+ dòng trong vài giây cho distributed tracing. Xu hướng nhất quán: ClickHouse thắng ở analytics quy mô lớn, Postgres thắng ở dữ liệu vận hành. Hầu hết team production đều chạy cả hai. Nếu bạn đang đánh giá Postgres so với database quan hệ khác, xem thêm Postgres vs MySQL 2026.

Dịch vụ hosting

Nếu ClickHouse là lựa chọn phù hợp, ClickHouse Cloud giúp giải phóng gánh nặng vận hành — không cần cài đặt Keeper, không cần quản lý cluster. Giá bắt đầu từ ~$0.22/giờ tính theo compute unit cộng với chi phí lưu trữ; lưu ý rằng tháng 1/2025 đã có mức tăng ~30% so với các gói trước, và không có gói miễn phí vĩnh viễn (chỉ dùng thử 14–30 ngày).

ClickHouse tự host trên server đơn 16 core / 64 GB RAM xử lý được 10–50B dòng mà không cần overhead của clustering. Với các team ở Việt Nam hoặc Đông Nam Á đang đánh giá chi phí, một VPS $100/tháng là điểm khởi đầu khả thi cho hầu hết workload ở quy mô SaaS.

Nếu bạn quyết định ở lại với Postgres, Neon và Supabase cung cấp managed Postgres sẵn sàng cho production. Mô hình serverless của Neon phù hợp với workload analytics bursty có scale-to-zero; Supabase tích hợp sẵn auth, realtime, và storage cho các team muốn một backend platform đầy đủ. Xem thêm Neon vs Supabase: so sánh chi tiết để chọn managed provider phù hợp.

Lưu ý

Các benchmark được trích dẫn đều từ nguồn công khai; phần cứng, hình dạng query, và thiết kế schema đều ảnh hưởng đến kết quả. Hãy benchmark workload cụ thể của bạn trước khi migrate.
Thiết kế schema trong ClickHouse quan trọng hơn trong Postgres. Mức cải thiện 55× chỉ từ một thay đổi ORDER BY trong benchmark fiveonefour là cảnh báo rõ ràng: sai schema là đắt để sửa sau.
Giá ClickHouse Cloud thay đổi theo thời gian — xác minh mức giá hiện tại trước khi ước tính ngân sách.
Bài viết này có chứa affiliate links (ClickHouse Cloud, Neon, Supabase). Được đánh giá độc lập; trạng thái affiliate không ảnh hưởng đến kết luận.