PostgreSQL 40 năm: Cha đẻ cơ sở dữ liệu và người giữ lửa cộng đồng nói gì về AI doanh nghiệp
Michael Stonebraker, người tạo ra Postgres năm 1986, và Bruce Momjian của nhóm phát triển PostgreSQL cùng phân tích vì sao AI doanh nghiệp cần một cơ sở dữ liệu quan hệ không bị công ty nào chi phối. Họ chỉ ra giới hạn thực tế của mô hình ngôn ngữ lớn với dữ liệu có cấu trúc và hé lộ những gì PostgreSQL 19 mang lại.

PostgreSQL 40 năm: Cha đẻ cơ sở dữ liệu và người giữ lửa cộng đồng nói gì về AI doanh nghiệp
Michael Stonebraker giới thiệu Postgres tại Đại học Berkeley năm 1986. Bốn thập kỷ sau, cơ sở dữ liệu do ông sáng tạo đã trở thành lựa chọn hàng đầu cho một thế hệ dự án AI. Thế nhưng chính ông lại là một trong những người hoài nghi sắc bén nhất về cách các dự án đó đang được xây dựng.
Trong loạt nội dung AI & Data Horizons của EnterpriseDB (EDB), vị giáo sư MIT từng đoạt giải Turing và Bruce Momjian — đồng sáng lập kiêm thành viên nhóm nòng cốt của Nhóm Phát triển Toàn cầu PostgreSQL — cùng đưa ra một luận điểm chung: tương lai thuộc về những hệ thống linh hoạt mà không gãy vỡ, và những cộng đồng không bị bất kỳ công ty nào nắm quyền kiểm soát.
Từ 80% xuống... 0%
Ví dụ đầu tiên của Stonebraker là text-to-SQL — lời hứa rằng người dùng doanh nghiệp có thể đặt câu hỏi bằng tiếng Anh thông thường và nhận câu trả lời từ kho dữ liệu. Các bộ kiểm chuẩn công khai như Spider và BIRD báo cáo độ chính xác trên 80%.
Nhóm của ông thử làm điều tương tự trên kho dữ liệu của chính MIT — 1.400 bảng thông tin sinh viên, giảng viên, tòa nhà và lương — với các truy vấn thật lấy từ nhật ký SQL.
"Chúng tôi nhận được độ chính xác bằng không. Không phải 80, không phải 70, không phải 40 — mà là số không."
Thêm AI dạng tác tử, truy xuất và kỹ thuật gợi ý chỉ đưa con số lên mức vài chục phần trăm. Việc liệt kê mọi bảng và điều kiện kết nối cho mô hình giúp chạm ngưỡng 30%. "Vẫn chưa đủ sẵn sàng cho giờ phát sóng chính."
Lý do là những vấn đề quen thuộc của mọi hệ thống doanh nghiệp:
- Không có dữ liệu huấn luyện, vì kho dữ liệu không nằm trên internet công khai
- Dữ liệu đặc thù: tòa nhà của MIT đánh số chứ không đặt tên
- Lược đồ đã thoái hóa thành tên bảng, tên cột khó hiểu và các view chồng chéo
- Truy vấn thật khó hơn truy vấn kiểm chuẩn
Nhóm của ông đã công bố bộ kiểm chuẩn riêng mang tên Beaver và cho biết chưa ai vượt qua được mức độ chính xác trong khoảng 30%.
Dùng mô hình đúng việc nó giỏi
Theo Stonebraker, vấn đề sâu xa hơn nằm ở kiến trúc. Mô hình ngôn ngữ lớn giỏi xử lý văn bản, nhưng "thứ chúng không làm được là kết nối dữ liệu có cấu trúc" — vốn chiếm phần lớn những gì doanh nghiệp nắm giữ.
Khi làm việc với Sở Giao thông Munich, nhóm của ông nhận ra rằng để trả lời một khiếu nại của người dân về thời gian đèn tín hiệu ở vạch sang đường, cần kết hợp quy định pháp lý, bản vẽ CAD, lịch tàu điện và bản đồ khu vực trường học. Điều phối việc đó bằng một mô hình ngôn ngữ ở trung tâm là "cực kỳ tốn kém".
Giải pháp của nhóm — hệ thống Rubicon — chỉ dùng mô hình cho phần văn bản, sau đó chuyển kết quả thành bảng và giao phần còn lại cho một công cụ xử lý dạng bảng. Bộ điều phối "trông giống một bộ tối ưu hóa truy vấn". Theo Stonebraker, cách này rẻ hơn 10 lần và chính xác hơn đáng kể so với các khung tác tử xoay quanh mô hình.
Ông dự đoán AI dạng tác tử sẽ trượt từ đỉnh cao kỳ vọng xuống thung lũng thất vọng trước khi một góc nhìn cân bằng hơn xuất hiện. Doanh nghiệp rất ghét tính phi tất định: phê duyệt một khoản vay rồi đảo ngược khi rà soát lại, thì "đó gọi là một vụ kiện".
Các tổ chức cũng cần được bảo vệ khỏi những tác tử chạy loạn. Theo ông, các rào chắn bên trong cơ sở dữ liệu phần lớn đã có sẵn: hàng thập kỷ kiểm soát truy cập, nhật ký đầy đủ và các trigger có thể dừng giao dịch ngay lập tức. Các tác tử thao tác nhiều dữ liệu nên nằm trong lớp dữ liệu dưới dạng hàm do người dùng định nghĩa, miễn là công cụ gỡ lỗi và quản lý phiên bản được cải thiện.
Stonebraker cũng thẳng thắn về giới hạn của công nghệ tiên phong: các mô hình đã dùng hết dữ liệu huấn luyện thật trên internet, và ông không biết doanh nghiệp nào cho phép mô hình huấn luyện trên dữ liệu độc quyền của mình. Ông gọi AGI là "chiêu tiếp thị" của các nhà cung cấp mô hình nền tảng để biện minh cho định giá của họ.
Không ai sở hữu nó
Vậy tại sao là Postgres? "Postgres là câu trả lời xuyên thiên hà cho mã nguồn mở," Stonebraker nói. Đặc điểm độc nhất của nó là "không bị bất kỳ công ty nào kiểm soát". EDB, Microsoft, Google và nhiều bên khác đều đóng góp committer, và không ai nắm quyền dẫn dắt.
Ông xác định mốc trỗi dậy của Postgres là thời điểm Oracle mua lại MySQL, khi "mọi người đều nói: công ty chi phối". Với doanh nghiệp, tính độc lập đó chính là nền tảng của chủ quyền dữ liệu: duy trì quyền kiểm soát cách thức và nơi vận hành hệ thống dữ liệu của mình.
Momjian mô tả cấu trúc tương tự từ bên trong. Postgres không có văn phòng, không có tài sản, không có pháp nhân, vậy mà vẫn sản sinh ra "phần mềm tốt hơn cả những công ty tỷ đô". Công cụ dự báo của dự án chính là cộng đồng, nơi sớm nhận ra nhu cầu từ Trung Quốc, Nga và Mỹ.
"Chúng tôi chỉ cần một người cực kỳ thông minh trên thế giới, và người đó cho chúng tôi biết họ nghĩ gì."
Thiết kế để uốn cong
Cả hai chuyên gia đều mô tả một triết lý thiết kế ưu tiên tính linh hoạt hơn vài phần trăm tốc độ cuối cùng. Stonebraker xây Postgres để có thể mở rộng, và đó là lý do nó tiếp nhận JSON, tìm kiếm toàn văn, GIS và giờ là AI mà không cần viết lại.
Momjian bổ sung một lời kêu gọi khác từ thập niên 1990: dựa vào hệ điều hành thay vì nuốt chửng nó — điều khiến Postgres trở thành lựa chọn tự nhiên cho điện toán đám mây. Ông phản đối những tối ưu hóa đổi lấy 5 hay 10% hiệu năng bằng cái giá của sự cứng nhắc, vì một hệ thống chỉnh sai có thể mất tới 40%.
"Nếu bạn lái xe Formula One tới siêu thị, thì chẳng có chỗ nào để đặt túi đồ."
Dự án hoạch định trên tầm nhìn mà ít nhà cung cấp nào theo kịp: "Chúng tôi nhìn vào tác động sẽ ra sao sau 5 năm, 10 năm nữa."
PostgreSQL 19 mang đến điều gì?
Bản phát hành mới thể hiện rõ kỷ luật đó. Một số tính năng từng được giới thiệu trước — gồm truy vấn đồ thị thuộc tính SQL và việc gộp, tách phân vùng — đã bị rút lại, vì độ tin cậy phải đặt lên trước. Quy trình rà soát có AI hỗ trợ đang phát hiện vấn đề nhanh hơn; bản vá tháng 8/2026 cho PostgreSQL 18 xử lý 28 lỗ hổng CVE.
Những gì còn lại đều mang tính thực dụng:
- REPACK CONCURRENTLY cho các bảng đang bận
- Autovacuum song song thông minh hơn
- Đồng bộ sequence cho nhân bản logic
- Plan Advice của Robert Haas, cộng tác viên nòng cốt — câu trả lời của cộng đồng cho kiểu gợi ý tối ưu hóa của Oracle mà họ từng từ chối suốt nhiều năm. Momjian nói: "Ai đó đã tìm ra cách làm mà không có những điểm trừ."
Cơ sở dữ liệu là bộ nhớ của AI
Hai người không đồng quan điểm về tốc độ AI sẽ tự viết SQL. Momjian kỳ vọng các tác tử sẽ tạo cơ sở dữ liệu và sinh phần lớn mã lệnh. Stonebraker cho rằng điều đó sẽ không xảy ra bên trong doanh nghiệp cho đến khi dữ liệu được ghi chép đầy đủ, các silo được mở ra và những rào cản chính trị thay đổi.
Nhưng họ đồng ý về đích đến: AI cần một hệ thống quan hệ để có tính bền vững và bộ nhớ. Theo Momjian, đó là "một yếu tố thay đổi cuộc chơi".
Bốn mươi năm sau, người sáng tạo và người giữ lửa vẫn đặt cược vào cùng một cơ sở dữ liệu. Với các doanh nghiệp Việt Nam đang bước vào giai đoạn ứng dụng AI, bài học rút ra khá rõ ràng: hạ tầng dữ liệu mở, có thể mở rộng và không bị khóa vào một nhà cung cấp duy nhất nên được đặt làm nền tảng trước, thay vì chạy theo những lời hứa hào nhoáng của mô hình ngôn ngữ.


