Have you ever thought about rewriting an open source code into another language? PostgreSQL is written in C, and its behavior, execution, and workflow are written in the C language. Now postgresql can support everything from relational workloads to full-text search methods.
The reason for creating pgrust is that - how would you create a database code like postgresql if you were building it now? Would we have made it in the same way?
Pgrust tries to keep the postgresql behaviour and compatibility, and also explores what a modern postgresql like db would look like if it was built from scratch using something like Rust.
Why Think About Rewriting PostgreSQL in Rust?
At first, we may think rewriting postgresql is not necessary because postgres is reliable, well-tested, and has a huge community; everything postgresql currently has been used for years and is less prone to errors. Then, why do we need to rewrite? It is not because the implementation using C is bad, because C has been really effective for building high performance softwares and systems.
1. Memory safety
One of the biggest differences between C and Rust is the way they manage memory. In C, developers have more direct control over memory through pointers, manual allocation, and deallocation methods. This gives better control and performance, but it also tells us that programmers must make sure that memory is being accessed correctly.
If not, we might face problems like:
- use-after-free
- buffer overflows
- dangling pointers
- double frees
- invalid memory access
- data races
Rust approaches this case differently. Its ownership, borrowing, and lifetime system allows the compiler to catch many classes of memory management errors before the program runs. For a complex system like postgres, where memory is used throughout the executor, storage manager, buffer manager, networking layer, and other components, this can make the system easier to reason about and safer to evolve.
pgrust is not pure safe Rust; any system that must reproduce postgresql's on-disk byte layout will need unsafe blocks in places.
2. A chance to rethink the architecture
Rewriting postgresql in Rust provides us an opportunity to rethink some of the fundamental architectural decisions we are relying on. Instead of being constrained by the current design of postgres, pgrust can think about modern methods for concurrency, connection handling, query execution, scheduling, memory management, and storage. This makes it possible to test with features such as greater use of threads, vectorized execution, intelligent query scheduling, built-in protection against runaway queries, and better handling of memory pressure and modern storage workloads.
3. Modern hardware and workloads
Workloads we have in the database have also changed a lot since postgresql was created, with current applications managing thousands of concurrent connections, large analytical queries, and bigger datasets. And also a modern CPU provides many cores and better memory architecture. Rewriting PostgreSQL gives us a chance to design the architecture and components according to modern hardware capabilities, rather than relying on old structures we made decades ago.
What is pgrust?
pgrust is PostgreSQL written in Rust. One of the most important design goals is compatibility. pgrust tries to reproduce postgresql behaviour very closely so that PostgreSQL's regression tests can be used for correctness rather than creating a different codebase that merely resembles PostgreSQL. The current project shows 46,066 out of 46,066 postgresql regression queries passed, while remaining compatible with postgresql dialect and wire protocol.
This project is trying to keep the behavior that postgresql applications already expect while changing what happens under the hood.
Where the project stands today
pgrust is at v0.2, and the project describes itself as not production-ready. The README already says this -” do not put data you care about in it; it still has a lot of bugs, and if you need production-ready Postgres today, use postgres.” Testing and reliability are the team's stated top priority right now. Compatibility is real but bounded; pgrust matches postgresql 18.3's expected output across the regression suite and is disk compatible, which means it can boot from an existing 18.3 data directory, but existing postgresql extensions do not work. Procedural languages such as PL/Python, PL/Perl, and PL/Tcl are not supported, and only some bundled contrib modules have been ported. The project is also licensed under AGPL-3.0, unlike postgresql’s permissive license, which is worth knowing before anyone considers it for real use. External code contributions are not being accepted yet, as the architecture is still moving too fast.