Năm 2026, cứ dùng Postgres thôi (It's 2026. Just Use Postgres)
(tigerdata.com)Luận điểm cốt lõi
- Lời khuyên lâu nay rằng “hãy dùng công cụ phù hợp” rốt cuộc lại dẫn đến tình trạng bùng nổ cơ sở dữ liệu (sprawl), biến việc vận hành thành địa ngục quản trị. Trong kỷ nguyên AI agent năm 2026, xử lý mọi thứ bằng một cơ sở dữ liệu duy nhất có lợi thế áp đảo. Nói thẳng kết luận trước → với đa số (99%) công ty, chỉ một Postgres là đủ.
Vì sao bây giờ nên đi với một Postgres duy nhất?
- AI agent cần khởi tạo nhanh DB thử nghiệm, fork và debug, nhưng nếu dùng nhiều DB (Pinecone + Elasticsearch + Redis + MongoDB, v.v.) thì gần như bất khả thi.
- Chỉ với một Postgres, chiến lược backup, giám sát, bảo mật và khôi phục sự cố được hợp nhất → tải nhận thức và chi phí ẩn giảm mạnh.
- Dùng nhiều DB khiến các vấn đề như lỗi đồng bộ, độ khó khôi phục tăng vọt và độ phức tạp vận hành tăng gấp 7 lần trở thành thực tế.
Cơ sở cụ thể cho thấy Postgres có thể thay thế các DB chuyên dụng
Các extension của Postgres đã triển khai những thuật toán tương đương hoặc tốt hơn DB chuyên dụng:
- Tìm kiếm → pg_textsearch (BM25) → thay thế Elasticsearch
- Tìm kiếm vector → pgvector + pgvectorscale (DiskANN) → nhanh hơn Pinecone 28 lần và rẻ hơn 75%
- Chuỗi thời gian → TimescaleDB → tương đương hoặc tốt hơn InfluxDB + hỗ trợ đầy đủ SQL
- Tài liệu → JSONB → hiệu năng cỡ MongoDB + đảm bảo ACID
- Dữ liệu địa lý → PostGIS (chuẩn từ năm 2001)
- Hàng đợi → pgmq → có thể thay thế Kafka
- Ngoài ra còn có pg_cron, pgai, v.v. để bao phủ phần lớn nhu cầu
Phản biện các ý kiến phản đối
- “Có những tác vụ mà DB chuyên dụng làm tốt hơn” → đúng, nhưng với 99% doanh nghiệp thì đó là mức thừa thãi, chỉ có ý nghĩa trong 1% trường hợp cực đoan hàng đầu.
- Marketing của các hãng bán DB chuyên dụng chỉ là thứ đã gieo rắc huyền thoại “right tool”, trong khi chi phí vận hành ẩn thực tế và rủi ro phá vỡ tính nhất quán dữ liệu còn lớn hơn nhiều.
Kết luận
- Hãy bắt đầu với Postgres.
- Chỉ thêm độ phức tạp khi nhu cầu đã được chứng minh.
- Năm 2026, cứ dùng Postgres thôi.
(Tiger Data là công ty tạo ra TimescaleDB/pgvector, v.v. nên bài có phần hơi mang tính quảng bá, nhưng logic lập luận và cơ sở benchmark khá thuyết phục.)
8 bình luận
Cụm “right tool for the job” ngay từ đầu hẳn là đã bao hàm cả quy mô công ty, góc độ bảo trì và chi phí, vậy mà từ bao giờ câu đó lại bị diễn giải thành việc phải dùng một công cụ được chuyên biệt hóa cho một tác vụ cụ thể, thật sự tôi không hiểu.
Trước đây cũng đã vậy rồi, nhưng dạo này các dịch vụ như supabase, neon db lại còn hợp hơn cho cả kiểu vibe coding của người không phải lập trình viên nên có vẻ càng được chuộng hơn nữa.
Không thể phủ nhận được.
Trong các phiên bản mới nhất, MySQL cũng đã được cải thiện về nhiều tiện ích nên cũng khá ổn, nhưng dùng PostgreSQL thì có phần tiện hơn.
Nếu là trường hợp muốn tối đa hóa hiệu năng bằng clustered index thì MySQL InnoDB có thể nhỉnh hơn một chút chăng?
MySQL không dùng được sao??
Ngược lại, cũng có ý kiến cho rằng “đến năm 2026 hãy ngừng dùng MySQL”.. https://optimizedbyotto.com/post/reasons-to-stop-using-mysql/
Mấy bài kiểu "dùng
postgreslà làm được hết" cứ định kỳ lại xuất hiện nhỉKhi nghĩ xem giữa Postgres và công việc kinh doanh của chúng ta, bên nào dễ tổn thương hơn...
Nếu bỏ qua các yếu tố khác thì xét riêng ở khía cạnh bảo trì thuần túy, đây có thể là một lợi ích.
Tuy vậy, nếu tính cả nhân sự đã tuyển, các công cụ liên quan, nhân sự sẽ tuyển trong tương lai, cũng như xung đột nội bộ có thể phát sinh từ quan điểm này, thì tôi vẫn băn khoăn liệu đây có thật sự là một ý kiến tốt hay không.
Thay vì xem đó là điều đúng một cách tuyệt đối, có lẽ tốt hơn là chọn giải pháp phù hợp với tình hình của tổ chức thôi haha