Tại hội nghị PGConf.dev 2025 Global Developer Conference, Bohan Zhang từ OpenAI đã chia sẻ các best practice của OpenAI khi sử dụng PostgreSQL, mang đến cái nhìn sâu sắc về cách sử dụng database của một trong những công ty unicorn nổi tiếng nhất hiện nay.
Tại OpenAI, chúng tôi sử dụng kiến trúc
unshardedvớione writervàmultiple readers, chứng minh rằng PostgreSQL có thể scale một cách hiệu quả khi lượng tải read cực lớn (heavy read).PGConf.dev 2025, Bohan Zhang từ OpenAI
Bohan Zhang là thành viên team Infrastructure của OpenAI, học trò của giáo sư nổi tiếng Andy Pavlo tại CMU, và cùng ông đồng sáng lập OtterTune.
Bối cảnh
PostgreSQL đóng vai trò là database chính hỗ trợ phần lớn các hệ thống quan trọng của OpenAI. Nếu PostgreSQL gặp sự cố, nhiều dịch vụ thiết yếu của OpenAI sẽ trực tiếp bị gián đoạn và điều này đã xảy ra không ít lần, các lỗi liên quan đến PostgreSQL đã từng gây ra nhiều sự số cho ChatGPT trong quá khứ.
OpenAI sử dụng managed database trên Azure (Azure Database for PostgreSQL), áp dụng kiến trúc primary-replica replication cổ điển của PostgreSQL mà không cần sharding. Kiến trúc này bao gồm một primary database và hàng chục replica. Đối với một service như OpenAI với hàng triệu active user, khả năng scalability là một vấn đề đáng quan tâm.
Thách thức
Trong kiến trúc primary-replica PostgreSQL của OpenAI, khả năng scale cho các request đọc rất tốt. Tuy nhiên, đối với các write requests, nó đã trở thành một bottleneck. OpenAI đã triển khai nhiều phương án tối ưu, chẳng hạn như offloading write loads(chuyển các write request) bất cứ khi nào có thể, tránh thêm services mới vào primary database.
Thiết kế Multi-Version Concurrency Control (MVCC) của PostgreSQL tồn tại một số vấn đề đã được biết đến, ví dụ như table bloat và index bloat. Việc tunning các tiến trình vacuuming khá phức tạp, vì mỗi lần write databasae sẽ tạo ra một version mới hoàn toàn cho record đó, kể cả khi lúc update record có sẵn, và khi truy cập index cũng có thể cần thêm visibility check. Những vấn đề này tạo ra thử thách khi scale các read replicas: ví dụ, việc tăng Write-Ahead Logging (WAL) có thể dẫn đến replication lag lớn hơn, và khi số lượng replica tăng đáng kể, network bandwidth có thể trở thành bottleneck mới.
Các biện pháp OpenAI đã triển khai
Để giải quyết những vấn đề này, OpenAI đã nỗ lực trên nhiều phương diện:
Kiểm soát tải của Primary Database
Chiến lược tối ưu hóa đầu tiên tập trung vào việc giảm và phân phối đều tải cho cácwrite request cho primary database, bao gồm:
- Chuyển các thao tác ghi không quan trọng sang các hệ thống khác để giảm áp lực lên
primary database. - Giảm thiểu các thao tác ghi không cần thiết ngay từ application level.
- Áp dụng cơ chế
lazy writesđể phân phối đều cho các đợt ghi dữ liệu đột biến - Kiểm soát chặt chẽ tần suất trong quá trình
data backfilling.
Ngoài ra, OpenAI cố gắng chuyển càng nhiều read request càng tốt sang các replicas. Đối với những truy vấn read bắt buộc phải thực hiện trên primary database (vì là một phần trong read-write transaction), việc tối ưu hiệu suất trở thành yếu tố quyết định.
Tối ưu hóa Query
Chiến lược tối ưu thứ hai của OpenAI tập trung vào việc cải thiện query layer. OpenAI đã thực hiện các biện pháp sau:
-
Kiểm soát thời gian trong các transactions: Các
long transactionsthường gây cản trở quá trìnhgarbage collectionvà tiêu tốn nhiều tài nguyên hệ thống. OpenAI đã giải quyết vấn đề này bằng cách cấu hình nhiều loạitimeoutskhác nhau, bao gồmsession level,statement levelvàclient level, để ngăn chặn tình trạng"Idle in Transaction"kéo dài. -
Tối ưu các truy vấn phức tạp: Các
multi-join queriesphức tạp (như truy vấn kết hợp 12 bảng cùng lúc) cũng đã được OpenAI phân tích và tối ưu hóa đặc biệt, để tăng hiệu suất. -
Thận trọng với ORM: Bài thuyết trình nhấn mạnh rằng việc sử dụng các
ORM(Object-Relational Mapping) thường tạo ra các truy vấn không hiệu quả. OpenAI khuyến nghị cần sử dụngORMmột cách thận trọng và có chọn lọc để tránh ảnh hưởng đến hiệu suất database.
Giải quyết Single Point of Failure
Primary database là một single point of failure: khi nó gặp sự cố, mọi thao tác ghi đều bị block hoàn toàn. Tuy nhiên, với kiến trúc multi replica, hệ thống vẫn duy trì khả năng đọc ngay cả khi có sự cố. Cụ thể:
- Nếu một
read-only replicagặp vấn đề, các ứng dụng dễ dàng chuyển sang đọc từ cácreplicakhác mà không bị gián đoạn. - Phần lớn các request quan trọng của OpenAI là
read-only, nó giúp hệ thống duy trì hoạt động ngay cả khiprimary databasedown tạm thời.
OpenAI còn triển khai phân chia độ ưu tiên của request:
- Các request
high-priority requestsđược định tuyến đến cácread-only replicaschuyên dụng. - Cách tổ chức này giúp bảo vệ các request quan trọng khỏi bị ảnh hưởng hiệu năng từ các request ít quan trọng hơn(
low-priority requests).
Quản lý Schema
Biện pháp thứ tư là chỉ cho phép các lightweight schema change (thay đổi schema nhỏ) trên cluster này. Điều này có nghĩa là:
- Nghiêm cấm việc tạo bảng mới hoặc đưa các workload mới vào hệ thống
- Cho phép thêm hoặc xóa column (với giới hạn timeout là
5 giây), nhưng bất kỳ operation nào yêu cầufull table rewriteđều không được phép. - Cho phép tạo hoặc xóa index, nhưng bắt buộc phải sử dụng options
CONCURRENTLY
Một vấn đề khác được đề cập là cáclong-running query (>1s) trong quá trình hoạt động có thể liên tục block schema change, cuối cùng khiến chúng fail. Giải pháp là để tầng ứng dụng tối ưu hóa hoặc chuyển những query đó sang read replica để schema change ở primary không bị block.
Kết quả
- Scale Azure-hosted PostgreSQL để xử lý hàng triệu QPS (read và write) trên toàn bộ cluster, hỗ trợ các dịch vụ quan trọng của OpenAI.
- Thêm hàng chục
replicas(khoảng 40) mà không làm tăngreplication lag. - Triển khai
read-only replicastrên các khu vực địa lý khác nhau trong khi vẫn duy trì độ trễ thấp. - Chỉ gặp một
SEV0 incidentliên quan đến PostgreSQL trong 9 tháng qua. - Dự trữ đủ capacity cho tăng trưởng tương lai
Case study sự cố
OpenAI cũng chia sẻ một số case study về các issues họ đã gặp phải:
Case đầu tiên liên quan đến cache failure dẫn đến cascading effect ảnh hưởng đến toàn hệ thống.
Incident thứ hai đặc biệt thú vị: khi CPU usage tăng lên mức cực cao, một bug đã xảy ra. Điều đáng chú ý là ngay cả sau khi mức sử dụng CPU đã trở lại bình thường, WALSender process vẫn tiếp tục xoay vòng trong một vòng lặp vô hạn thay vì gửi WAL logs đúng cách đến replica, dẫn đến replication lag ngày càng tăng.
Đề xuất cải tiến cho PostgreSQL
Cuối cùng, Bohan đưa ra một số vấn đề và feature request tới PostgreSQL developer community:
-
Về quản lý index: Các indexes không được sử dụng thường gây ra
write amplificationvà tăngmaintenance overhead. OpenAI muốn loại bỏ các indexes không cần thiết, nhưng để giảm thiểu rủi ro, họ đề xuất một tính năng Disable cho indexes. Tính năng này sẽ cho phép theo dõiperformance metricsđể đảm bảo hệ thống vẫn ổn định trước khi quyết định loại bỏ vĩnh viễn index. -
Về observability:: Hiện tại,
pg_stat_statementschỉ cung cấpaverage response timecho mỗi query type, thiếu các chỉ số vềp95vàp99 latency. OpenAI mong muốn có thêm metrics chi tiết nhưhistogramsvàpercentile latenciesđể giám sát hiệu suất tốt hơn. -
Về schema changes: OpenAI đề xuất PostgreSQL nên ghi lại lịch sử của các sự kiện thay đổi schema, như việc thêm/xóa columns và các DDL operations khác.
-
Về monitoring view semantic: Họ phát hiện một session có
state = Activevàwait_event = ClientReadtồn tại hơn 2 giờ. Điều này cho thấy connection vẫn hoạt động trong thời gian dài sauQueryStart, và các connection như vậy không thể bị dừng bởiidle_in_transaction timeouts. Họ muốn biết liệu đây có phải là bug và làm thế nào để xử lý nó. -
Tối ưu hóa default parameters: OpenAI nhận xét rằng các giá trị mặc định của PostgreSQL hiện tại quá lỗi thời. Họ đề xuất nên có những default parameters tốt hơn hoặc áp dụng
heuristic-based settingsphù hợp với phần cứng hiện đại.
Góc nhìn từ chuyên gia
Bình luận của Lao Feng
Mặc dù PGConf.Dev 2025 chủ yếu tập trung vào phát triển, nhưng thường cũng có những chia sẻ thực tế từ phía người dùng như OpenAI. Những chia sẻ này đặc biệt hữu ích đối với các core developers, bởi nhiều người chưa có cơ hội tiếp xúc với cách PostgreSQL được triển khai trong các môi trường production thực tế đầy khắc nghiệt.
Từ cuối năm 2017, Lao Feng đã quản lý hàng chục PostgreSQL clusters tại Tantan, một trong những hệ thống lớn và phức tạp nhất internet Trung Quốc thời bấy giờ. Lúc đó, core cluster lớn nhất của họ sử dụng 1 master và 33 replicas và xử lý khoảng 400,000 QPS. Lao Feng cũng gặp bottleneck tương tự ở single-node write performance và đã giải quyết bằng database sharding và table sharding ở tầng ứng dụng.
Có thể nói rằng những vấn đề gặp phải và các giải pháp áp dụng trong bài thuyết trình của OpenAI đều là những thứ họ đã từng xử lý trước đây. Tất nhiên, điểm khác biệt lớn nhất là phần cứng hiện đại ngày nay mạnh mẽ hơn nhiều so với 8 năm trước. Điều đó cho phép một startup như OpenAI sử dụng một PostgreSQL cluster duy nhất, không sharding hay partitioning để vận hành toàn bộ hệ thống của họ. Đây là minh chứng rõ ràng cho quan điểm rằng distributed databases thường là một vấn đề không cần thiết.
OpenAI hiện đang sử dụng PostgreSQL trên Azure với cấu hình server cao cấp. Hệ thống bao gồm hơn 40 replicas (kể cả cross-region replicas) và xử lý khoảng 1 triệu QPS (đọc + ghi). Họ sử dụng Datadog để giám sát, và các dịch vụ của họ truy cập cluster thông qua PgBouncer connection pooling phía ứng dụng từ bên trong Kubernetes.
Vì OpenAI là một khách hàng strategic-level, đội ngũ Azure PostgreSQL luôn hỗ trợ OpenAI sát sao. Tuy nhiên, ngay cả với các nhà cung cấp dịch vụ database hàng đầu, người dùng vẫn cần chuyên môn vững về ứng dụng và vận hành. Ngay cả với đội ngũ xuất sắc của OpenAI, họ vẫn gặp phải những pitfalls trong quá trình vận hành PostgreSQL trên thực tế.
High availability không được đề cập trong bài trình bày, có lẽ vì Azure PostgreSQL đã đảm nhiệm. OpenAI sử dụng Datadog để giám sát và thú vị là dù với nguồn lực tài chính dồi dào, họ vẫn cho rằng Datadog "đắt một cách vô lý".
Sau hội nghị, Lao Feng đã có buổi trò chuyện dài với Bohan và hai nhà sáng lập database khác. Rất tiếc không thể chia sẻ chi tiết cuộc trò chuyện thú vị đó!
Q&A của Lao Feng
Về các vấn đề và các tính năng mới do Bohan đưa ra, Lao Feng đưa ra một số câu trả lời bên dưới. Thực tế, hầu hết các chức năng mà OpenAI đang tìm kiếm đã tồn tại trong PostgreSQL ecosystem, chỉ là nó có thể không có sẵn trong core PostgreSQL hoặc trên Azure Database for PostgreSQL.
Về việc disable Indexes
PostgreSQL thực sự có một tính năng để vô hiệu hóa indexes. Bạn chỉ cần set trường indisvalid thành false trong system catalog pg_index. Thao tác này khiến planner bỏ qua index đó, nhưng index vẫn được cập nhật trong các DML operations. Về mặt kỹ thuật, đây cũng chính là cơ chế được sử dụng trong quá trình tạo concurrent index thông qua các cờ isready và isvalid.
Tuy nhiên, OpenAI không thể áp dụng phương pháp này vì Azure Database for PostgreSQL không cấp superuser permissions, nên không thể sửa đổi trực tiếp system catalogs.
Quay lại mục tiêu ban đầu: Sợ xóa nhầm index, vấn đề này có cách giải quyết đơn giản hơn, kiểm tra qua monitoring views để chắc chắn index không được sử dụng trên cả primary và replicas.
Sử dụng Pigsty monitoring system, bạn có thể quan sát quá trình live index switching cho các bảng PGSQL.
CREATE UNIQUE INDEX CONCURRENTLY pgbench_accounts_pkey2
ON pgbench_accounts USING BTREE(aid); -- Mark the original index as invalid (won’t be used) but still maintained
UPDATE pg_index SET indisvalid = false
WHERE indexrelid = 'pgbench_accounts_pkey'::regclass;
Về Observability
pg_stat_statements khó có thể sớm hỗ trợ P95 hoặc P99 percentile metrics, vì điều này sẽ làm tăng memory footprint của extension lên hàng chục lần. Mặc dù server hiện nay có thể xử lý được, nhưng nhiều nơi vẫn khá dè dặt và không chịu thay đổi. Lao Feng đã trao đổi với người maintain pg_stat_statements và cả Jelte (người maintain pgbouncer), và cả hai đều xác nhận tính năng này khó được triển khai trong tương lai gần.
Tuy nhiên, vẫn có một số giải pháp thay thế:
- Extension
pg_stat_monitorcung cấppercentile latency metricschi tiết (mặc dù cần cân nhắc performance overhead) - Sử dụng
eBPFđể thu thậpRT metricsmột cách thụ động - Thêm giám sát độ trễ query vào data access layer của tầng ứng dụng
Giải pháp ưu việt nhất có lẽ là dùng eBPF-based side-channel collection, nhưng vì OpenAI đang sử dụng Azure PostgreSQL mà không có quyền truy cập server, nên phương án này không khả thi.
Về schema change record
Thực ra, PostgreSQL logs đã hỗ trợ tính năng này, chỉ cần set log_statement thành ddl (hoặc mod/all), và tất cả DDL statements sẽ được ghi lại. Extension pgaudit cũng cung cấp chức năng tương tự.
Tuy nhiên, OpenAI có thể muốn một system view có thể truy vấn qua SQL. Trong trường hợp đó, lựa chọn khác là sử dụng CREATE EVENT TRIGGER để log DDL event trực tiếp vào data table. Extension pg_ddl_historization cung cấp cách dễ dàng hơn nhiều để làm điều này, và Lao Feng đã compile và package extension này.
Đáng tiếc là việc tạo event triggers cũng yêu cầu quyền superuser privileges. AWS RDS có xử lý đặc biệt cho phép điều này, nhưng Azure PostgreSQL dường như không hỗ trợ.
Về ngữ nghĩa monitoring view
Trong ví dụ của OpenAI, State = Active nghĩa là backend process vẫn trong lifecycle của một SQL statement và chưa gửi ReadyForQuery message tới frontend, nên PostgreSQL vẫn coi statement là "chưa kết thúc". Kết quả là các resource như row locks, buffer pins, snapshots và file handles vẫn được coi là "in use".
WaitEvent = ClientReadcó nghĩa là process đang đợi input từ client. Khi cả hai xuất hiện cùng nhau, thường là COPY FROM STDIN đang chờ, hoặc do TCP blocking, hoặc bị stuck giữa BIND và EXECUTE. Vì vậy, khó xác định đây có phải bug hay không, việc này phụ thuộc vào connection đang thực sự làm gì.
Một số có thể tranh luận rằng waiting for client I/O nên được tính là "idle" từ góc độ CPU. Nhưng State theo dõi trạng thái thực thi của statement, không phải việc process có đang sử dụng CPU hay không. Một query có thể ở Active state trong khi không chạy trên CPU (khi WaitEvent là NULL), hoặc có thể loop trên CPU chờ client input (tức ClientRead).
Giải pháp cho vấn đề này: trong Pigsty, khi PostgreSQL được truy cập thông qua HAProxy, primary service có maximum connection lifespan (ví dụ 24 giờ) được set ở load balancer level. Trong các môi trường có quy định khắt khe hoặc đòi hỏi siệu suất hoạt động cao, có thể giảm xuống còn 1 giờ. Khi connection vượt ngưỡng này, nó sẽ bị ngắt.
Lý tưởng nhất là client-side connection pool nên chủ động quản lý connection lifetime và chủ động ngắt thay vì bị ngắt kết nối. Đối với offline read-only services, có thể không cần thiết lập parameter này, để cho phép những ultra-long query chạy hai ba ngày.
Lao Feng không chắc Azure PostgreSQL có hỗ trợ tính năng này hay không
Về Default Parameters
PostgreSQL có default parameters cực kỳ cổ lỗ sĩ. Ví dụ, nó default chỉ 256 MB memory (và có thể set thấp đến 256 KB!). Ưu điểm là PostgreSQL có thể start và chạy trong hầu như bất kỳ môi trường nào. Nhược điểm? Lao Feng đã thấy production setup với 1 TB physical memory vẫn chạy với cấu hình default 256 MB. (Nhờ double buffering, nó thực sự chạy khá lâu.)
Nhìn chung, Lao Feng nghĩ rằng các giá trị mặc định này không phải là một điều tệ. Vấn đề này có thể được giải quyết bằng dynamic configuration linh hoạt hơn. Azure Database for Postgres và Pigsty đã cung cấp heuristicsđược thiết kế tốt cho việc thay đổi các initial parameters.
Tuy nhiên, tính năng này vẫn có thể được build vào PostgreSQL command-line tool. Ví dụ, trong quá trình initdb, tool có thể auto-detect CPU, memory, disk size và type, và để thiết lập giá trị mặc định phù hợp.
Self-Hosting?
Thách thức thực sự của OpenAI không đến từ PostgreSQL, mà từ những hạn chế khi sử dụng PostgreSQL được quản lý trên Azure. Một giải pháp là chuyển sang IaaS của Azure hoặc cloud khác để triển khai self-hosted PostgreSQL clusters trên các instance với local NVMe SSD.
Thực tế, Pigsty được Lao Feng xây dựng đặc biệt, để giải quyết các vấn đề của PostgreSQL ở quy mô tương tự, về cơ bản nó là một self-hosted Azure Database for Postgres solution. Và nó có khả năng mở rộng tốt. Nhiều vấn đề mà OpenAI đã gặp phải hoặc sẽ gặp phải đã có giải pháp và đã có solution trong Pigsty, một dự án open-source và miễn phí.
Nếu OpenAI quan tâm, Lao Feng rất sẵn lòng hỗ trợ. Tuy nhiên, đối với công ty đang phát triển nhanh như họ, việc tối ưu infrastructure database có thể không phải ưu tiên hàng đầu. May mắn là, họ có những DBA PostgreSQL xuất sắc, những người có thể tiếp tục thúc đẩy, khám phá và cải thiện hệ thống hiện tại.
Bài biết này được dịch từ bài báo của Lao Feng: