Postgres was rewritten in Rust… and somehow passed every test

Highlights

• PGRust is an independent database implementation designed to mirror PostgreSQL 18.3, capable of booting from existing PostgreSQL data directories.

• The current version of PGRust successfully passes all 46,000 queries in the official PostgreSQL regression test suite.

• Unpublished development builds of PGRust report a 50% performance increase on transactional workloads and 300x performance on analytical workloads by utilizing a thread-per-connection model.

• PostgreSQL currently relies on a process-per-connection architecture, which introduces memory overhead and complicates state sharing across parallel tasks.

• AI-assisted coding agents were utilized extensively to make the architectural rewrite of the million-line C codebase economically feasible.

• PGRust is not yet production-ready, lacking full optimization and extensive support for the broader PostgreSQL extension ecosystem.

Timeline

1. 00:00 - 02:25

   PGRust Project Scope

   The project aims to replace the core engine of PostgreSQL while preserving established client experiences. It differentiates itself from existing forks by targeting exact compatibility through the official PostgreSQL regression suite. Testing confirms that standard PSQL clients interact with the Rust-based implementation without modification.

   • PGRust functions as a standalone database engine written in Rust rather than a standard PostgreSQL extension.
   • The system maintains wire protocol and disk format compatibility, allowing it to boot from existing PostgreSQL 18.3 data directories.
   • External behavior and output remain indistinguishable from native PostgreSQL during standard operations like table creation and query planning.
2. 02:25 - 04:45

   Architectural Changes and Performance

   PostgreSQL faces challenges managing memory and concurrency due to its long-standing architecture involving nearly a million lines of C code. The thread-per-connection model attempts to solve these limitations but risks the isolation benefits provided by separate process-based backends. Developers are evaluating these trade-offs to determine if performance gains outweigh the potential reduction in crash isolation.

   • The standard PostgreSQL process-per-connection model incurs significant memory overhead and limits cross-connection state sharing.
   • Experimental builds replace the process-based architecture with a thread-per-connection model to reduce per-connection resource usage.
   • Transitioning to threads introduces new safety concerns, as memory errors in one connection may affect the broader server process.
3. 04:45 - 06:17

   AI Influence and Development Velocity

   The rewrite demonstrates how automated agents can potentially change the economics of refactoring legacy systems. While the performance benchmarks for the thread-per-connection version are significant, the code powering these figures remains unavailable for public inspection or verification. Current testing remains limited to the public release version.

   • AI coding agents were central to scaling the effort required for a rewrite of this magnitude.
   • Unverified development claims suggest up to 50% faster transactional throughput and 300x faster analytical performance.
   • The project serves as an experiment in whether AI can lower the cost of complex infrastructure maintenance and modernization.
4. 06:17 - 08:27

   Production Viability and Future Outlook

   While passing 46,000 regression tests is a notable milestone, production databases require extensive validation through crash recovery and long-term stability testing. The project represents a significant technical experiment that may influence future infrastructure development. Users are encouraged to test client libraries against the existing Docker image to aid in further development.

   • Passing regression tests validates protocol compatibility but does not equate to the long-term reliability required for production environments.
   • The lack of comprehensive extension support remains a major barrier to widespread adoption.
   • The project is currently intended for exploration and testing rather than replacing production clusters.