Postgres rewritten in Rust passes 100% of Postgres regression tests
Rewriting one of the pillars of technological infrastructure, such as PostgreSQL, seems like a Herculean task. After all, we are talking about a robust and mature relational database that powers countless critical applications worldwide. But that's exactly what the pgrust project sets out to do: rewrite Postgres in Rust, with an ambitious goal that goes far beyond merely replicating functionalities. And the latest news? They have just reached an impressive milestone: the new version of pgrust passes 100% of Postgres's own regression tests. This is no small feat.
The pgrust: A Postgres in Rust, Compatible and Ambitious
The pgrust project was born with a clear premise: maintain compatibility with Postgres's behavior and use Postgres's own regression tests as an "oracle" to ensure identical output. The version currently under development already achieves compatibility with Postgres 18.3 and, remarkably, can initialize from an existing Postgres 18.3 data directory – meaning it is disk compatible. Anyone who has worked with system migrations or compatibility knows this is a considerable technical achievement.
The big question is: why rewrite such an established database? The answer lies in the quest to make Postgres "easier to modify internally." The idea is to use Rust's safety and performance, combined with AI-assisted programming, to explore deeper changes in the server architecture that would be difficult or risky in the original code, written predominantly in C.
Rust, for those unfamiliar, is a programming language known for its memory safety and performance, qualities that make it ideal for low-level systems where stability is critical. By rewriting Postgres in Rust, pgrust seeks to inherit these advantages, paving the way for innovations that might be limited by the current architecture.
Beyond Compatibility: Future Vision and Performance
Achieving 100% compatibility in regression tests is a starting point, not the final destination. The pgrust team is already working on a new (yet unpublished) version that promises to go much further:
- Connection Model: Instead of the traditional "process per connection" model (which can be heavy for many accesses), pgrust adopts a "thread per connection" model, which is lighter and more efficient for managing multiple simultaneous requests.
- Incredible Performance: Initial benchmarks of this new version are impressive. pgrust proves to be 50% faster than Postgres in transactional workloads (fast and frequent read/write operations, such as those in e-commerce) and about 300 times faster in analytical workloads (complex queries for reports and data analysis). Although still 2 times slower than Clickhouse (a database optimized for analytics) in some tests, the team believes it can surpass it.
It is crucial to note that pgrust is not yet production-ready and has not yet been optimized for performance in all aspects. However, the initial numbers are a glimpse of its potential.
Among the architectural innovations and features planned for the future, highlights include:
- Multithreaded Internals: A fully multithreaded Postgres core for better resource utilization.
- Built-in Connection Pooling: Integrated connection pooling, meaning the database can reuse existing connections instead of creating new ones for each request, improving efficiency and reducing latency.
- Better JSON Support: Optimizations to handle JSON-intensive workloads, a data format very common in modern applications.
- Fast Forking and Branching Workflows: Ability to create instant "copies" of databases for development or testing, speeding up the software development lifecycle.
- Storage Experiments: Including "no-vacuum" designs, which aim to eliminate the need for Postgres's
VACUUMoperation, which can be a performance bottleneck. - Runtime Guardrails: Protection mechanisms to identify and limit the impact of bad or AI-generated queries, preventing performance or security issues.
- Fewer Unexpected Plan Changes: Reduction in the occurrence of "bad plan switches," where the query optimizer chooses an inefficient execution plan.
It is important to mention that existing Postgres extensions, such as PL/Python or PL/Perl, are not yet compatible, although compatibility may increase over time for some modules.
Why This Matters To You
For developers, architects, and technical leaders, pgrust is more than an interesting project; it's a demonstration of what's possible when fundamental infrastructure is rethought with new tools. Even if pgrust doesn't replace Postgres everywhere, the innovations it is exploring – from concurrency architecture to storage experiments and AI integration – could influence the future of relational databases.
It reminds us that, even in mature and widely adopted software, there is always room for radical innovation. The pursuit of a Postgres that is easier to evolve, more performant, and more resilient, built on a modern foundation like Rust, is a beacon for what we can expect from the next generation of data tools. Keep an eye on it, as the lessons and emerging technologies from this project may soon impact how we build and scale our applications.
Sources
📬 Enjoyed this? Subscribe to the Vaccari's Code newsletter for the next wave of software & AI trends, straight to your inbox: Subscribe here