- pgrust là dự án viết lại bằng Rust hướng tới tương thích với Postgres 18.3, và khớp với đầu ra kỳ vọng của Postgres trên hơn 46.000 truy vấn hồi quy
- Có khả năng tương thích đĩa để khởi động từ thư mục dữ liệu Postgres 18.3 hiện có, và lấy các bài kiểm thử Postgres thực tế làm chuẩn hành vi
- Hiện chưa sẵn sàng cho production, cũng chưa được tối ưu hiệu năng; các extension Postgres hiện có và extension ngôn ngữ thủ tục như PL/Python, PL/Perl, PL/Tcl nhìn chung chưa tương thích
- Có thể chạy thử qua demo WebAssembly và Docker image
malisper/pgrust:v0.1; latest hiện trỏ tới cùng bản phát hành, nhưng image chạy cố định là v0.1
- Lộ trình bao gồm kiến trúc nội bộ Postgres đa luồng, connection pooling tích hợp, cải thiện workload tập trung vào JSON, thử nghiệm storage no-vacuum, và guardrail runtime cho SQL do AI tạo
Mục tiêu và khả năng tương thích của pgrust
- pgrust là dự án viết lại Postgres bằng Rust
- Mục tiêu là Postgres 18.3, và khớp với đầu ra kỳ vọng của Postgres trên hơn 46.000 truy vấn hồi quy
- Cung cấp khả năng tương thích đĩa để khởi động từ thư mục dữ liệu Postgres 18.3 hiện có
- Mục tiêu của dự án là giúp việc thay đổi Postgres từ bên trong trở nên dễ dàng hơn
- Hành vi vẫn giữ theo dạng Postgres
- Sử dụng các bài kiểm thử Postgres thực tế làm chuẩn
- Khám phá các thay đổi sâu hơn trong server bằng Rust và lập trình có AI hỗ trợ
Trạng thái hiện tại và giới hạn
- pgrust hiện chưa sẵn sàng cho production
- Vẫn chưa được tối ưu hiệu năng
- Các extension Postgres hiện có và extension ngôn ngữ thủ tục nhìn chung hiện chưa tương thích
- Một số module contrib đi kèm đã được port, và theo thời gian có thể đạt thêm nhiều khả năng tương thích hơn
Cách chạy
- Có thể chạy thử demo WebAssembly tại https://pgrust.com
- Chạy bằng Docker sử dụng image
malisper/pgrust:v0.1
- Sử dụng client
psql bên trong image
malisper/pgrust:latest hiện trỏ tới cùng bản phát hành- Image phát hành cố định là
v0.1
docker run -d --name pgrust -e POSTGRES_PASSWORD=secret malisper/pgrust:v0.1 && until docker exec -e PGPASSWORD=secret pgrust psql -h 127.0.0.1 -U postgres -c '\q' >/dev/null 2>&1; do sleep 1; done && docker exec -it -e PGPASSWORD=secret pgrust psql -h 127.0.0.1 -U postgres; docker rm -f pgrust
Build từ mã nguồn và chạy
- Trên macOS cần
icu4c, openssl@3, libpq
brew install icu4c openssl@3 libpq
export LIBRARY_PATH="$(brew --prefix openssl@3)/lib:${LIBRARY_PATH:-}"
export PKG_CONFIG_PATH="$(brew --prefix openssl@3)/lib/pkgconfig:$(brew --prefix icu4c)/lib/pkgconfig:${PKG_CONFIG_PATH:-}"
export PATH="$(brew --prefix libpq)/bin:$PATH"
- Trên Debian/Ubuntu, cài công cụ build cùng ICU, OpenSSL, LDAP, PAM và client Postgres 18
sudo apt-get update
sudo apt-get install -y build-essential pkg-config libicu-dev libssl-dev libldap2-dev libpam0g-dev postgresql-client-18
- Việc build được thực hiện bằng
cargo build, với chỉ định thư mục share của Postgres 18.3 được vendored
PGRUST_PGSHAREDIR="$PWD/vendor/postgres-18.3/share" \
cargo build --release --locked --bin postgres
- Thư mục dữ liệu được tạo bằng
--initdb của pgrust
target/release/postgres --initdb \
-D /tmp/pgrust-data \
-L "$PWD/vendor/postgres-18.3/share" \
--no-locale \
--encoding UTF8 \
-U postgres
- Khi chạy, dùng kèm thiết lập liên quan đến stack và thiết lập I/O đồng bộ
ulimit -s 65520
RUST_MIN_STACK=33554432 target/release/postgres \
-D /tmp/pgrust-data \
-F \
-c listen_addresses= \
-k /tmp \
-p 5432 \
-c io_method=sync \
-c max_stack_depth=60000
Kiểm thử hồi quy và kết quả xác minh
- Bộ kiểm thử hồi quy Postgres được chạy bằng
scripts/run-regression
PGRUST_BIN="$PWD/target/release/postgres" \
scripts/run-regression
- Test runner sử dụng
--initdb riêng của pgrust và các file kiểm thử Postgres 18.3 có trong repository
- Cần có client Postgres 18
psql trong PATH
- Nếu ở vị trí khác, thiết lập
PGRUST_PSQL=/path/to/psql
- Kết quả phát hành đã được xác minh là pgrust khớp với đầu ra kỳ vọng của Postgres trên hơn 46.000 truy vấn hồi quy
Lộ trình và lịch sử dự án
- Lộ trình bao gồm các hạng mục sau
-
Kiến trúc nội bộ Postgres đa luồng
- Connection pooling tích hợp
- Cải thiện hỗ trợ workload tập trung vào JSON
- Quy trình fork và branching nhanh
- Thử nghiệm storage, bao gồm thiết kế no-vacuum
- Guardrail runtime cho truy vấn sai và SQL do AI tạo
- Giảm các lần chuyển đột ngột sang execution plan kém
- Repository hiện tại chứa triển khai pgrust mới hơn đã đạt mốc kiểm thử hồi quy
- Triển khai công khai trước đây được lưu trữ tại
archive/pre-fabled-2026-06-23
- Các liên kết nền tảng liên quan
- Original pgrust launch
- 67% regression update
- Four Horsemen roadmap
- Giấy phép là AGPL-3.0
1 bình luận
Ý kiến trên Hacker News
Tôi là tác giả gốc. Không ngờ nó lại lên đây. Tóm lại, tôi đã làm một thử nghiệm để tạo ra Postgres tốt hơn bằng LLM, và vì Postgres đã 30 năm tuổi nên tôi nghĩ trong thời gian đó chúng ta cũng đã học được rất nhiều về cơ sở dữ liệu
Khá nhiều kỹ thuật hữu ích cho việc viết lại cũng hữu ích cho việc thiết kế lại. Phiên bản pgrust mới chưa công bố hiện đã vượt qua 100% bài kiểm tra hồi quy của Postgres, triển khai mô hình thread cho mỗi kết nối thay vì mô hình tiến trình cho mỗi kết nối của Postgres, nhanh hơn Postgres 50% trên tải giao dịch và nhanh hơn khoảng 300 lần trên tải phân tích
Hiện tại nó chậm hơn ClickHouse 2 lần trong clickbench, nhưng tôi nghĩ nó có thể nhanh hơn ClickHouse. Nếu có câu hỏi tôi sẽ trả lời
Có thể ở đâu đó đã phá vỡ MVCC để đổi lấy thứ không thể đưa vào production. Tôi có thấy là nó vượt qua các bài kiểm tra hồi quy.
fsynccó đang bật không? Theo tôi biết thì kiểm tra hồi quy không bắt được tốt các mẫu I/O tệ. Dù vậy trông vẫn là một dự án thú vịTôi đang làm một việc tương tự nhưng khác, là tạo δx. Đây là một extension của Postgres lưu dữ liệu nén dạng cột bên trong bảng Postgres thông thường nên sao chép, khôi phục sự cố,
pg_dumpv.v. vẫn hoạt động nguyên vẹn: https://github.com/xataio/deltaxHiện tại trên một node đơn lẻ nó chậm hơn ClickHouse 30~40%. PR thêm nó vào clickbench vừa được chấp nhận, nên có thể xem so sánh tại đây: https://benchmark.clickhouse.com/#system=+liH|_etx|gQ|saB&ty...
Tôi không thực sự hiểu các kiểu viết lại như thế này. Thường một người sẽ dẫn dắt, và rất dễ trở thành điểm lỗi đơn lẻ, lại còn được làm trong thời gian rất ngắn nên khó nói là đã rèn được tính kỷ luật để xây dự án bền bỉ
Về trung và dài hạn thì khả năng được duy trì cũng có vẻ thấp. Người muốn đóng góp cũng phải trả chi phí token. Vì ngày càng khó duy trì những dự án như vậy nếu không có AI. Có ai thực sự muốn đưa thứ này vào production không? Nghe không hợp lý lắm
Tôi sẽ không đưa nó vào production, nhưng đã học được rất nhiều về bên trong cơ sở dữ liệu. Ngay cả trong thời đại LLM, để đầu óc vẫn thấy hứng thú, tôi cũng triển khai các tính năng cơ sở dữ liệu cho cơ sở dữ liệu production của chúng tôi mà không dùng LLM. Gần đây tôi đang vật lộn với Flexible Paxos, dù có lẽ cuối cùng vẫn sẽ tiếp tục dùng Raft vì nó cũ, ổn định và đơn giản hơn, nhưng dù sao cũng rất thú vị
LLM rất mạnh trong việc tạo prototype cực nhanh, và một prototype chạy được có thể chấm dứt rất nhiều suy đoán. Nếu không có chính đội ngũ gốc hoặc một lượng nhân lực đáng kể tương đương đứng sau, và không có giải thích đáng tin rằng nó đã đạt hoặc vượt chất lượng mã nguồn và khả năng bảo trì của bản gốc, thì tôi có lẽ sẽ không dùng bản viết lại của một dự án khổng lồ như thế này
Nói chung, việc dùng LLM để rửa giấy phép thì tôi thấy khó biện hộ cả về pháp lý lẫn đạo đức. Nhưng trường hợp này khác ở chỗ họ đã chọn một giấy phép hạn chế hơn. Tôi không phải luật sư, nhưng theo hiểu biết của tôi thì tải PostgreSQL về,
s/MIT/AGPL/rồi phân phối lại là hợp pháp. Vì bản MIT gốc vẫn còn đó, nên trước khi có tính năng mới đủ thuyết phục thì không có lý do gì để ưu tiên bản đóCách tốt nhất để kiểm thử thứ này có lẽ là đặt một proxy như PgBouncer trước một cơ sở dữ liệu production bận rộn, rồi mirror query đồng thời tới Postgres hiện tại và phiên bản Rust
Như vậy có thể so sánh đầu ra và hiệu năng dưới tải thực. Sau khi chạy một thời gian, cũng có thể đem từng bảng ra đối chiếu với instance Postgres thông thường
Nên đánh giá kiểu mã này như thế nào? Thông thường người ta sẽ lướt lịch sử commit để xem mọi người đã làm gì và làm như thế nào, nhưng nếu LLM tạo ra 7101 commit trong chưa đầy một tháng thì điều đó là bất khả thi.
Chỉ xem riêng một ngày thôi cũng đã quá nhiều [1]. Dù sao thì nội dung commit cũng có thể không cho biết được bao nhiêu. Cũng tò mò không biết có cách nào dễ để đi tới commit đầu tiên của kho trên GitHub hay không. Việc lần theo lịch sử commit có cảm giác khá phiền phức.
[1] - https://github.com/malisper/pgrust/commits/main/?since=2026-...
Cần đi xa hơn rất nhiều so với các bài kiểm thử hồi quy, cô lập và lỗi của Postgres. Bài viết danluu liên quan: https://danluu.com/ai-coding/
github clicó lệnh truy vấn commit với cờ sắp xếp tăng dần/giảm dần: https://cli.github.com/manual/gh_search_commitsTài liệu cú pháp như
before x dateở đây: https://docs.github.com/en/search-github/searching-on-github...Cũng có trang tìm kiếm nâng cao, nhưng không hỗ trợ commit với bộ lọc ngày: https://github.com/search/advanced
Cũng có thể tìm nhị phân theo ngày trong tiện ích tìm kiếm, và ngày đầu tiên có commit là ở đây: https://github.com/malisper/pgrust/commits/main/?since=2026-...
Commit đầu tiên: https://github.com/malisper/pgrust/commit/22113dc36b02973060...
Mặt khác, ngoài message commit ra thì từ trước đến nay chúng ta cũng đâu có tiếp cận được quá trình suy nghĩ nội bộ của lập trình viên con người, nên nói rằng prompt bí mật đồng nghĩa với mã nguồn đóng cũng có lẽ không hoàn toàn tương đương
github.com/user/repo/commits/?after=last_commit_hash+number_of_commits-2. Cách này trừ-1,-1vì có commit mới nhất và commit cuối cùng.Ví dụ: https://github.com/malisper/pgrust/commits/?after=3646a73515...
Khá ấn tượng, nhưng đây là thay đổi giấy phép từ giấy phép PostgreSQL [0] sang AGPL [1].
Tôi thích AGPL và nghĩ đó là giấy phép mã nguồn mở tự do thực sự tốt nhất, nhưng tôi lo về tính tương thích. Nếu được viết lại từ mã nguồn gốc thì chẳng phải giấy phép gốc nên được áp dụng sao? Tôi nghĩ là vậy. Đã từng có xu hướng viết lại phần mềm mã nguồn mở dưới giấy phép hạn chế hơn, như Rust coretools. Việc chọn AGPL khiến nó có vẻ đạo đức hơn nhiều, nhưng có lẽ an toàn hơn nếu hoàn toàn không đổi giấy phép?
[0] https://www.postgresql.org/about/licence/
[1] https://github.com/malisper/pgrust?tab=AGPL-3.0-1-ov-file
Việc phát hành bản viết lại dưới giấy phép hạn chế hơn không vi phạm giấy phép PostgreSQL. Lý do các giấy phép kiểu MIT ít hạn chế hơn GPL hay AGPL chính là vì chúng cho phép tái cấp phép theo hướng hạn chế hơn
Có thể hiểu thế này. Bạn tạo một dự án (A)GPL trống rồi đưa codebase BSD upstream vào. Các tệp upstream gốc vẫn giữ giấy phép cho phép ban đầu, nhưng toàn bộ dự án sẽ chịu sự chi phối của (A)GPL, bao gồm cả yêu cầu ghi công của giấy phép upstream. GPL cho phép các yêu cầu như vậy. Sau đó bạn có thể thêm mã của mình dưới AGPL và phân phối tác phẩm kết hợp dưới AGPL.
Nếu ai đó chỉ lấy phần mã do bạn viết, họ chỉ cần tuân theo AGPL. Nhưng nếu họ cũng bao gồm cả mã nguồn upstream, thì họ vẫn phải tiếp tục đáp ứng yêu cầu ghi công của giấy phép upstream
Có 2664 chỗ
unsafe {và 1835 chỗunsafe fn. Như vậy hoàn toàn không an toàn. Trông không giống một bản viết lại có hiểu rõ chuyện gì thực sự đang diễn ra và cần thiết kế lại kiến trúc ra sao để tận dụng được ưu điểm của RustMà giống một bản chuyển đổi do AI tạo ra dùng con trỏ thô trên diện rộng hơn
unsafebị nhốt trong bộ phân tích cú pháp được tạo ra bằng cách chạyc2rusttrên parser của Postgres. Bản thân parser của Postgres cũng được sinh từyacc/bison, nên người ta đã chọn port một cách máy móc thay vì chuyển sang Rust theo kiểu thành ngữNếu có chỗ
unsafenào bị xem là đặc biệt nghiêm trọng thì rất mong được chỉ raunsafe=deny. Không hiểu sao mọi người lại không lường trước phản ứng kiểu nàyCó lẽ cần phân biệt rõ giữa viết lại và viết lại bằng AI
Vậy thì phải dùng AI đến mức nào mới được gọi là “viết lại bằng AI”?
Tôi thấy nhiều dự án viết lại kiểu này tuyên bố rằng chúng hoạt động nhờ dựa vào test. Nhưng điều khiến phần mềm như Postgres hay SQLite trở nên đáng tin không hẳn là bản thân test, mà gần hơn với những vết sẹo tích lũy trong môi trường vận hành thực tế
Độ tin cậy được tích lũy qua nhiều năm chạy ngoài thực tế
SQLite là ví dụ điển hình. Bộ test khổng lồ nhưng không công khai của SQLite thường được nhắc đến như một yếu tố khiến người khác khó fork. Turso đã làm được, nhưng để bảo đảm mức độ cẩn trọng tương đương thì cần có cả một công ty. Và dĩ nhiên cũng cần nhiều năm vận hành thực tế
Dùng nguyên bộ test hiện có mà không chỉnh sửa để nói rằng một thứ gì đó hoạt động là hoàn toàn hợp lý. Dự án càng lớn thì càng đúng như vậy. Những vết sẹo thu được từ vận hành phải được ghi lại và bảo vệ trong bộ test; nếu không thì bài học đó sẽ biến mất
SQLite nổi tiếng vì bộ test khổng lồ và fuzzing trên diện rộng. Lượng mã test và script của nó nhiều hơn mã thường tới 590 lần. Nguồn: https://sqlite.org/testing.html
Lúc này, việc hữu ích nhất có thể làm với bản chuyển đổi bằng LLM như thế này là: nếu nó vượt qua toàn bộ test gốc, hãy chạy bộ test ứng dụng của tôi trên đó để tìm ra những lỗ hổng trong độ bao phủ test của bản gốc
Nếu bản chuyển đổi bị crash hoặc có hành vi sai có thể quan sát được, thì điều đó có nghĩa là dự án thật đang thiếu một regression test nào đó. Nếu có thể chạy các dự án chuyển đổi kiểu này một cách an toàn và dễ dàng như một dòng trong ma trận kiểm thử tích hợp hằng ngày, thì upstream sẽ ngăn được tốt hơn nhiều việc vô tình làm hỏng thứ gì đó ở các bản cập nhật sau này
Chỉ là ở các bản viết lại kiểu này, điều tôi không thấy là sẽ xử lý ra sao với những bug mới được đưa vào chính vì việc viết lại. Chẳng phải cuối cùng nó vẫn phải tự mình chịu thử thách trong các kịch bản ngoài đời thực sao?
Nếu biết các edge case thì cứ chạy chúng; còn nếu không biết thì có thể dùng fuzzer hay công cụ tự động để tìm đầu vào thú vị. Khi tìm ra khác biệt, cặp đầu vào/đầu ra đó sẽ trở thành test case mới. Tôi không biết đã có công cụ như vậy chưa, nhưng nếu có thì cứ đưa cho Claude để nó nhét vào vòng lặp phát triển
Bản demo WebAssembly chạy trong trình duyệt thực sự rất gọn gàng: https://pgrust.com
Không hiểu sao lại tiêu cực đến vậy. Mình thấy những dự án kiểu này thú vị vì mục đích học tập và khám phá cách làm mới. Có vấn đề gì với chuyện đó?
Đặc biệt, khi một cái tên mang tín hiệu mạnh như Postgres xuất hiện ngay trong tiêu đề và được đem ra làm điểm nhấn, nhưng lại rõ ràng thiếu tính thực dụng xét về ngắn hạn, dài hạn, niềm tin xã hội hay hiệu ứng mạng lưới, thì có vẻ rất dễ tạo phản cảm
Có thể hiểu được, nhưng đó không phải cảm xúc tiêu cực mang tính xây dựng, cũng không hẳn là rất hợp lý. Chuỗi thảo luận này đầy những bài viết muốn khẳng định rằng thứ này không thể nào là tốt, cũng không nên là tốt, và cuối cùng chắc chắn sẽ kết thúc trong thảm họa. Nhưng việc nó đã vượt qua hàng chục nghìn bài kiểm thử tinh vi được tích lũy suốt nhiều thập kỷ lại cho thấy điều ngược lại. Rất khó phản bác
Tất nhiên khả năng phát sinh vấn đề mới là cao, nhưng dù vậy đây vẫn là một thành tựu ấn tượng
https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b...
https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b...