- PgDog là một proxy đặt phía trước PostgreSQL, cho phép mở rộng Postgres theo chiều ngang thông qua connection pooling, load balancing và sharding mà không cần viết lại ứng dụng
- Họ cho rằng lý do tồn tại của các cơ sở dữ liệu như Mongo hay Dynamo là do vấn đề mở rộng của Postgres, và nếu có thể xử lý các bảng trên 100TB cùng 1 triệu truy vấn mỗi giây thì sẽ không cần cơ sở dữ liệu nào khác
- PgDog đang xử lý hơn 2 triệu truy vấn mỗi giây trong production, đã sharding hơn 20TB trong phạm vi được xác minh, và số lượt Docker pull trên GitHub đã vượt 1,4 triệu
- Đội ngũ ba người, dựa trên kinh nghiệm với các ứng dụng quy mô lớn dùng Postgres và trải nghiệm mở rộng gấp 5 lần của Instacart vào tháng 4/2020, đã giải quyết bài toán sharding Postgres trên RDS, Aurora và EC2
- Đã huy động 5,5 triệu USD từ Basis Set, YC, Pioneer Fund và các quỹ khác, đồng thời đang xây dựng PgDog thành một sản phẩm mã nguồn mở giúp Postgres hoạt động ở mọi quy mô
Gọi vốn và định hướng sản phẩm
- Việc phát triển Postgres bắt đầu từ quan điểm rằng đây là cơ sở dữ liệu duy nhất cần thiết
- Họ cho rằng lý do tồn tại của các cơ sở dữ liệu như Mongo hay Dynamo là vấn đề mở rộng của Postgres
- Họ tin rằng nếu Postgres có thể xử lý tốt các bảng trên 100TB và 1 triệu truy vấn mỗi giây thì sẽ không cần dùng cơ sở dữ liệu khác
- PgDog đặt một proxy phía trước Postgres hiện có để cho phép mở rộng theo chiều ngang
- PgDog có thể được triển khai ở bất cứ đâu, như on-premise hay trong tài khoản cloud của người dùng
- Chỉ cần kéo Docker image và thay
DATABASE_URL, PgDog sẽ đảm nhận phần còn lại
Tình hình hiện tại và bối cảnh thực thi
-
Trạng thái hiện tại
- PgDog hiện đang xử lý hơn 2 triệu truy vấn mỗi giây trên hàng chục môi trường triển khai production
- Trong phạm vi được xác minh, PgDog đã sharding hơn 20TB
- PgDog là mã nguồn mở và bất kỳ ai cũng có thể triển khai
- Số lượt Docker pull trên GitHub đã vượt 1,4 triệu
- Phiên bản mới được phát hành vào mỗi thứ Năm hàng tuần
- Cộng đồng Discord đang phát triển, với việc trả lời câu hỏi và hỗ trợ diễn ra hằng ngày
-
Đội ngũ và cơ sở tạo dựng niềm tin
- PgDog là một startup nhỏ với đội ngũ gồm ba người
- Đội ngũ gồm kỹ sư hạ tầng, kỹ sư ứng dụng và một generalist
- Họ đã xây dựng các ứng dụng dựa trên Postgres và vận hành chúng ở quy mô lớn từ trước khi Postgres được chú ý rộng rãi
- Tại Instacart, họ đã tích lũy kinh nghiệm vận hành Postgres trong giai đoạn công ty mở rộng gấp 5 lần vào tháng 4/2020
- Khi đó, vấn đề lớn nhất là làm sao để Postgres xử lý hàng trăm nghìn đơn giao hàng tạp hóa mỗi phút
- Họ đã sharding Postgres trên RDS, Aurora và EC2, đồng thời giải quyết các vấn đề thực tế bằng những nguyên lý cốt lõi và rất nhiều mã nguồn
- Công nghệ đó hiện được cung cấp dưới dạng sản phẩm mã nguồn mở
-
Cách triển khai và nguồn vốn
- Việc phát triển PgDog không phải là một cú pivot, và mục tiêu duy nhất vẫn luôn là mở rộng Postgres
- PgDog được tạo ra để chạy trong cloud của người dùng, rack colocation, on-premise và cả trên laptop
- PgDog hoạt động ở nơi cần thiết mà không có dependency hay chi phí serverless ẩn
- Nếu bạn có thể cung cấp CPU, mã đa luồng của PgDog sẽ sử dụng toàn bộ CPU
- Họ cho rằng mức độ chấp nhận Postgres sẽ tiếp tục tăng
- Họ đã huy động 5,5 triệu USD từ Basis Set, YC, Pioneer Fund và các nhà đầu tư khác, qua đó có đủ runway cho nhiều năm
- Mục tiêu là giúp Postgres hoạt động đúng nghĩa cho mọi người và ở mọi quy mô
-
Enterprise edition
- Enterprise edition của PgDog đang được phát triển để có thể chạy dễ dàng hơn trên AWS
- Enterprise edition cung cấp hỗ trợ theo SLA từ đội ngũ
1 bình luận
Ý kiến trên Hacker News
Người ta nói lý do tồn tại của các cơ sở dữ liệu như Mongo hay Dynamo là vấn đề mở rộng của Postgres, nhưng sau khi dùng Postgres ở nhiều nơi thì vấn đề ưu tiên số 1 luôn là tính sẵn sàng cao, chứ không phải mở rộng
Một cụm Postgres duy nhất dễ dàng xử lý 100.000 giao dịch mỗi phút, nhưng nếu nút chính chết thì phải bị gọi dậy, chuyển đổi dự phòng sang nút phụ bằng tay, rồi lại thay nút phụ cũng bằng tay
Các công cụ thủ công thì rất khó chịu nhưng ít nhất còn chạy được, còn các giải pháp tự động thì còn chưa tới gần mức đó
Vì thiếu một câu chuyện HA tốt nên tôi thường tránh tự vận hành Postgres nếu có thể
Bộ cân bằng tải có kiểm tra trạng thái và chuyển đổi dự phòng hoạt động sẵn theo mặc định, và giờ đã được kiểm chứng đủ nhiều trong thực tế nên đáng để xem qua
https://github.com/patroni/patroni
Với nhu cầu của tôi thì nó hoạt động rất tốt
Nếu trong phần “Why Us” họ viết rằng “Chúng tôi đã vận hành Postgres tại Instacart, và khi công ty tăng trưởng gấp 5 lần vào tháng 4/2020, vấn đề lớn nhất là làm sao để Postgres xử lý hàng trăm nghìn đơn giao hàng tạp hóa mỗi phút”, thì có lẽ không có phần vì sao là chúng tôi nào tốt hơn thế
Có vẻ một instance Postgres duy nhất cũng xử lý được đủ rồi
SSD enterprise hiện đại, chất lượng cao có thể xử lý khoảng 35.000 lần
fsyncthực tế mỗi giâyTất nhiên không biết đó là do Postgres hay do khiếm khuyết thiết kế nào khác
Về cơ bản tôi muốn hiểu điều này, hiện tại tôi có một DB 4TB trên một máy chủ lớn
Nếu dùng một công cụ proxy như PGDog thì có phải cấu trúc sẽ là chạy 8 máy chủ nhỏ, mỗi máy phụ trách khoảng 500GB, và thêm 1 máy chủ tầm trung làm proxy không?
Dự án hiện tại có lưu lượng ghi rất lớn từ nhiều dịch vụ, còn web app thì đọc từ đó
Giờ đã gần tới điểm mà lập chỉ mục, tối ưu truy vấn, cache và nâng cấp máy chủ cũng không còn giúp được bao nhiêu nữa
Tôi cũng đang xem phương án chuyển phần lớn dữ liệu tĩnh sang ClickHouse để giảm kích thước DB, nhưng muốn nghe xem PgDog hay các giải pháp sharding khác có hữu ích cho mục đích này không
Nếu liên hệ thì rất tốt (lev@pgdog.dev)
Chúng tôi có thể giúp, hoặc ít nhất cho bạn biết hiện tại cái gì chạy được và cái gì không, để bạn nắm rõ các lựa chọn
Nếu đọc tài liệu của pgdog, bạn sẽ thấy rằng bạn cần chỉ cho nó biết phải định tuyến yêu cầu tới máy chủ shard nào; nó không tự động hoạt động như phép màu
Dù vậy nó vẫn có giá trị vì tái sử dụng các kết nối vốn đặc biệt tốn kém trong Postgres
Vì đây không phải phép màu nên bạn cần hiểu chuyện gì đang diễn ra bên trong; ví dụ, không có giao dịch xuyên shard
Sharding rất khó nếu bạn quan tâm tới tính nhất quán dữ liệu, nên trước tiên tôi sẽ xem liệu ứng dụng có thể hưởng lợi từ read replica hay không
Mỗi replica đều có một bản sao đầy đủ của toàn bộ dữ liệu và chỉ ghi vào master; bạn phải tự xác định giao dịch nào có thể chạy trên replica, nơi có thể chậm hơn gần thời gian thực một chút
Ví dụ, các thao tác đọc để dựng trang web thường khá an toàn khi chạy trên replica, nhưng kiểu đọc-sửa-ghi thì không vậy
Tôi tò mò điều này sẽ giúp thế nào với nâng cấp phiên bản chính, nguyên nhân downtime lớn nhất của Postgres
Pooler rất tuyệt cho failover và cân bằng tải, nhưng do nâng cấp nên vẫn đều đặn cần khoảng 10–20 phút downtime một hoặc hai lần mỗi năm
Sao chép logic từ phiên bản cũ sang phiên bản mới có thể hữu ích, nhưng có vẻ vẫn cần phải chuyển mọi thứ sang cụm mới mà không có ghi dở dang hay trạng thái kỳ lạ
Không biết có ai đã từng làm việc này chưa
DB cỡ khoảng 1~1.5TB nhưng lượng thay đổi hay số truy vấn mỗi giây không quá lớn
Về cơ bản là cách được mô tả ở đây: https://www.pgedge.com/blog/always-online-or-bust-zero-downt...
Nếu có cấu hình hạ tầng dạng code, hãy tạo một cụm mới có cấu hình giống hệt, chỉ khác phiên bản chính, nhập schema, bắt đầu sao chép dữ liệu từ bản sao đọc của phiên bản cũ, dừng nhận ghi trên phiên bản cũ (bắt đầu downtime), đồng bộ số thứ tự sequence, rồi chuyển dịch vụ sang cụm mới (kết thúc downtime)
Nếu dùng thứ như CloudNativePG thì một phần quy trình này được tự động hóa bằng công cụ CLI và cú pháp khai báo
Nếu không thì phải tự bỏ thời gian tìm hiểu
Nghe có thể phức tạp, nhưng sau khi luyện trên DB staging và thấy ổn thì chỉ cần làm đúng quy trình đó trên production
Ngoài ra có vẻ Postgres 19 có bản vá cho logical replication một lần dành cho sequence: https://www.depesz.com/2025/11/11/waiting-for-postgresql-19-...
Nếu triển khai cụm theo tuần tự thì downtime rất nhỏ, có thể chỉ khoảng 60 giây
Đến mức này tôi cũng không chắc liệu có ngày nào mình còn được thấy nó không
Tôi vẫn không hiểu vì sao chuyện này không bao giờ được xem là ưu tiên số một tuyệt đối
Chúc mừng gọi vốn, Lev
Bên tôi đang dùng PgDog khá hài lòng
Tôi khá thích việc trong các tính năng proxy, nó xử lý được các thiết lập kết nối khác nhau cho từng connection, ví dụ
statement_timeoutHồi trước khi tìm hiểu RDS Proxy thì có vẻ nó không hỗ trợ, và pgbouncer hình như cũng vậy, nên phải sửa ứng dụng khá nhiều
Với PgDog thì nó hoạt động một cách trong suốt
Tôi tò mò liệu đây có phải thứ đáng để so sánh với multigres của Supabase vừa được công bố không
Tôi thấy có Enterprise Edition, nên muốn biết rõ những tính năng nào không phải mã nguồn mở
Tôi cũng muốn biết liệu có nên kỳ vọng các tính năng mới được thêm vào sẽ là giấy phép EE để đáp lại các nhà đầu tư VC hay không
Thứ nhất là control plane quản lý triển khai đa nút, giúp việc triển khai và sử dụng PgDog dễ dàng hơn với trải nghiệm “chạy là dùng được”
Thứ hai là chất lượng dịch vụ (QoS), tự động chặn các truy vấn xấu để chúng không thể đánh sập cơ sở dữ liệu
Cuối cùng, bạn cũng có thể nhận được hỗ trợ với SLA được bảo đảm tới mức P0
Tính năng mới chia thành hai nhóm
Sharding và vận hành Postgres ở quy mô lớn sẽ luôn là mã nguồn mở, còn quản lý hạ tầng và các tính năng giúp vận hành PgDog ở quy mô lớn một cách dễ dàng sẽ là bản doanh nghiệp
Thật tốt khi thấy PgDog, Neki, multigres xuất hiện
Đúng là đây là vấn đề cốt lõi của Postgres, và việc không có index hint cũng là một vấn đề nên tôi khá trông đợi Postgres 19
Cấu hình hơi khó, nhưng dạo này nhờ AI mà việc cấu hình dễ hơn nhiều
pg_hint_plankhông nằm trong core, nhưng khá hữu dụng khi bạn cần ghi đè plannerCâu “chúng tôi biết đã shard hơn 20TB” có lẽ là lỗi gõ
20TB không lớn đến vậy
Tôi nghĩ họ hẳn đã shard nhiều hơn thế rất nhiều
Mỗi cơ sở dữ liệu có tỷ lệ dữ liệu nóng và dữ liệu lạnh khác nhau, nên nếu không có thêm thông tin thì không thể so sánh được
IOPS có thể là thước đo tốt hơn
RDS có IOPS tối đa khá thấp nếu bạn không chi nhiều hơn rất nhiều cho provisioned IOPS hoặc dùng Aurora
Để so sánh, gần 10 năm trước ở Segment, chúng tôi từng vận hành một instance Aurora PostgreSQL đơn với khoảng 50TB dữ liệu, dùng để lập chỉ mục dữ liệu định danh tiềm năng trong một kho tệp lớn hơn rất nhiều được lưu trên S3
PgDog khá hay
Thú thật là tôi không cần nó, nhưng khi đi bộ đường rừng không có gì để nghe, tôi tình cờ nghe podcast Postgres FM, thấy hứng thú nên đang dùng nó trên Kubernetes on-prem của mình
https://open.spotify.com/episode/6qgpfiW68KcvRASs6649Fb