Postgres 19 chậm tiến độ và nguyên nhân xuất phát từ AI

Quay lại Blog/Postgres Postgres 19 chậm tiến độ và nguyên nhân bắt nguồn từ AI Các mô hình ngôn ngữ lớn (LLM) phát hiện lỗi nhanh hơn tốc độ xử lý của đội ngũ phát triển Robert Haas – Committer của Postgres, Databricks Ngày 21/10/2026 Đăng ký nhận thông tin cập nhật Chỉ nhận các bản tin mới nhất. Cam kết không gửi thư rác. Đăng ký Trong một thập kỷ qua, thời điểm phát hành các phiên bản lớn của PostgreSQL diễn ra rất đều đặn và có thể dự đoán trước: không sớm hơn trung tuần tháng 9 và không muộn hơn giữa tháng 10. Tuy nhiên, năm nay tình hình đã thay đổi. PostgreSQL 19 nhiều khả năng sẽ không thể ra mắt trước tháng 11, và không loại trừ khả năng dự án sẽ tiếp tục hoãn thời điểm phát hành. Bên cạnh đó, năm nay, một số tính năng tương đối lớn đã bị thu hồi (revert) vào giai đoạn khá muộn của chu kỳ thử nghiệm beta: các tính năng UPDATE/DELETE FOR PORTION OF, SQL Property Graph Queries (SQL/PGQ), và ALTER TABLE … MERGE PARTITION/SPLIT PARTITION đều bị hủy bỏ trong khoảng thời gian từ ngày 27/8 đến ngày 15/9. Dù việc thu hồi các tính năng lớn ngay sau giai đoạn "đóng băng tính năng" (feature freeze - diễn ra vào ngày 8/4 hằng năm) không phải là hiếm, việc hàng loạt tính năng quan trọng bị rút khỏi bản phát hành vào thời điểm muộn như vậy là điều bất thường. Điều gì đã dẫn đến thực trạng này? Câu trả lời ngắn gọn là do sự xuất hiện của LLM. Mọi phần mềm đều chứa lỗi, và cơ sở mã nguồn của PostgreSQL vừa đồ sộ, phức tạp, lại có tuổi đời lâu năm. Lịch sử git của hệ thống – được chuyển đổi từ CVS – đến nay đã trải dài hơn 30 năm, trong khi những dòng mã đầu tiên được viết từ một thập kỷ trước đó nữa. Khối lượng mã nguồn là khổng lồ, và lượng lỗi tồn tại trong đó cũng rất lớn. Thực tế này vốn luôn tồn tại và không cản trở sự phổ biến hay thành công của PostgreSQL. Điểm khác biệt hiện nay là việc tìm ra các lỗi đó đã trở nên dễ dàng hơn rất nhiều. Việc khắc phục lỗi cũng thuận lợi hơn, song tốc độ xử lý chưa thể theo kịp tốc độ phát hiện. Làn sóng vá lỗi dồn dập Từ ngày 8/4/2025 đến ngày 25/9/2025, đã có 1.037 commit vào nhánh master của PostgreSQL và 724 commit vào nhánh REL_18_STABLE. Trong cùng khoảng thời gian năm 2026, số lượng commit vào nhánh master đạt 1.443 lượt và nhánh REL_19_STABLE là 1.169 lượt. Nói cách khác, nếu chỉ tính số lượng commit được đưa vào nhánh master trong khoảng thời gian từ lúc đóng băng tính năng đến ngày 25/9, con số này trên thực tế giảm nhẹ so với năm trước; tuy nhiên, số lượng commit được cập nhật ngược về các phiên bản cũ (back-patch) đã tăng vọt hơn 60%. Có thể nhận định một phần sự gia tăng này xuất phát từ việc các committer mắc nhiều lỗi hơn trong năm nay so với năm ngoái, song giới chuyên môn tham gia dự án khó có thể coi đây là nguyên nhân chủ yếu. Thay vào đó, nhiều khả năng các committer của PostgreSQL trong năm 2026 vẫn duy trì mức độ thận trọng tương đương các năm trước, nhưng phần lớn các sai sót phát sinh đã nhanh chóng bị LLM rà soát và phát hiện. Hiện tượng này không chỉ dừng lại ở các sai sót trong bản phát hành mới nhất. Trong cùng kỳ năm 2025, có 248 commit vào nhánh REL_17_STABLE; con số này trong năm 2026 đối với nhánh REL_18_STABLE là 433 lượt. Như vậy, số lượng commit được back-patch không chỉ cho bản phát hành đang chuẩn bị ra mắt mà còn cho ít nhất một phiên bản trước đó đã tăng hơn 74% chỉ trong vòng một năm. Lý do rất đơn giản: một lượng lớn người dùng trên mạng hiện đang báo cáo các lỗi trong PostgreSQL được phát hiện thông qua LLM, buộc các committer của dự án phải dồn toàn bộ nguồn lực để xử lý. Đội ngũ phát triển PostgreSQL bị quá tải Đây cũng được xem là lý do dẫn đến việc nhiều tính năng bị thu hồi muộn và bản thân việc phát hành phiên bản mới bị trì hoãn. Thực trạng này bắt nguồn từ hai yếu tố chính. Thứ nhất, do số lượng lỗi được phát hiện hiện nay tăng mạnh, việc khắc phục đòi hỏi nhiều thời gian hơn. Các mô hình LLM có thể đề xuất phương án sửa lỗi, song các phương án này không phải lúc nào cũng chính xác hoặc tuân thủ các tiêu chuẩn của PostgreSQL. Vì vậy, các đề xuất vẫn cần được con người rà soát và phê duyệt (commit), trong khi năng lực xử lý của con người không có sự gia tăng đột biến giữa năm 2025 và năm 2026. Thứ hai, quỹ thời gian vốn dành cho việc thẩm định các nội dung phát hành đã phải chuyển hướng sang giải quyết các vấn đề bảo mật và các lỗi khác trên các nhánh phát triển cũ (back-branches). Do đó, quy trình xác định những nội dung cần hoàn tác trước khi phát hành phiên bản v19 mất nhiều thời gian hơn. Hướng đi tiếp theo Tựu trung, việc trì hoãn phát hành PostgreSQL 19 không phải là điều quá đáng lo ngại. Xét trên bình diện tổng thể, khoảng thời gian chậm trễ này không lớn và xuất phát trực tiếp từ sự chú trọng đến chất lượng của dự án. Bức tranh dài hạn hiện kém rõ ràng và ở chừng mực nào đó đáng quan ngại hơn: khi có tới 40 năm tích lũy các lỗi mà con người không thể phát hiện nhưng LLM lại hoàn toàn có khả năng tìm ra, việc theo kịp tiến độ và duy trì đổi mới sáng tạo của PostgreSQL sẽ được thực hiện ra sao? Đây vẫn là câu hỏi chưa có lời đáp chắc chắn vào thời điểm này, song các kỹ sư phát triển đang nỗ lực tối đa để tìm giải pháp. Mã nguồn của PostgreSQL vốn được đánh giá là một trong những nền tảng chuẩn mực và có chất lượng cao hàng đầu đối với giới lập trình viên. Thành công gần đây của AI trong việc phát hiện lỗi trên cơ sở mã này không làm giảm đi sự đánh giá cao đó. Không sản phẩm phần mềm nào là hoàn hảo, song nếu cơ sở mã có nhiều khiếm khuyết mà mắt thường con người cũng nhận thấy được, số lượng vấn đề do LLM phát hiện có thể sẽ còn lớn hơn rất nhiều. Thực tế cho thấy, LLM đang đặt ra yêu cầu nâng cao năng lực chuyên môn đối với từng nhà phát triển PostgreSQL, và ở chừng mực nhất định là đối với mọi lập trình viên phần mềm trên toàn cầu. Mọi tính năng được xây dựng từ nay về sau đều sẽ chịu sự kiểm tra nghiêm ngặt của AI, và những thiếu sót từng bị bỏ qua trước đây nay có thể bị phát hiện chỉ trong vài giờ. Đây vừa là thách thức, vừa là cơ hội. Mục lục trang này Làn sóng sửa lỗi Áp lực đối với các nhà phát triển PostgreSQL Hướng đi tiếp theo Chia sẻ: Đăng ký nhận nhật ký thay đổi Chỉ nhận các bản cập nhật mới nhất. Cam kết không gửi thư rác. Đăng ký Chia sẻ: Nội dung khác từ Neon Sản phẩm, ngày 26/10/2026 Xây dựng giải pháp với Stripe Data Pipeline và hạ tầng backend của Neon