A new open-source project has emerged with a bold claim: a version of PostgreSQL, rewritten in Rust, that is faster than both its namesake and the high-performance analytical database ClickHouse. The project, malisper/pgrust on GitHub, presents itself as a ground-up rewrite focused on performance. In an industry where PostgreSQL is a durable, trusted standard for transactional workloads and ClickHouse is a benchmark for analytical speed, the assertion that a new project can best both is a significant one. It signals a growing appetite for re-architecting foundational software with modern languages and data processing techniques.
This isn't merely a line-for-line translation of C code into Rust. Instead, pgrust adopts an entirely different internal architecture, borrowing heavily from the design of modern Online Analytical Processing (OLAP) databases. By doing so, it wades into the complex and resource-intensive world of database engine development, betting that the combination of Rust's safety and performance, coupled with a columnar, vectorized execution model, can yield substantial gains.
The Performance Claim in Detail
The central claim of the project's superiority rests on a specific benchmark detailed in its README file. The test involves a common analytical query: a GROUP BY aggregation on a table with 100 million rows of sales data. The goal is to calculate the total count and sum of sales for each city.
SELECT city, COUNT(*), SUM(sales)
FROM sales
GROUP BY city;
This type of query is a classic OLAP task. It requires scanning a large portion of the table, filtering specific columns (city, sales), and performing aggregate calculations. It is a workload that traditional row-oriented databases like PostgreSQL can handle, but one for which columnar databases like ClickHouse are specifically optimized.
The benchmark was run on a MacBook Pro with an M2 Max processor and 64GB of RAM. According to the project's documentation, the results for executing this query were:
- PostgreSQL: ~12 seconds
- ClickHouse: ~2.5 seconds
- pgrust: ~1.5 seconds
On this specific task, the numbers position pgrust as not just incrementally better, but significantly faster—over 8x faster than PostgreSQL and about 67% faster than ClickHouse. It is a remarkable result for a nascent project. However, this single benchmark is a narrow snapshot. It represents a best-case scenario for the architecture pgrust has chosen, and it doesn't reflect the vast spectrum of workloads that a general-purpose database must handle.
An OLAP Engine in Postgres Clothing
The key to understanding these performance numbers is to recognize that pgrust is not a direct, feature-for-feature replacement for PostgreSQL. While it shares the name, its internal design philosophy is fundamentally different. PostgreSQL is the quintessential Online Transaction Processing (OLTP) database. It is built for high-concurrency reads and writes of individual records, with strong consistency guarantees (ACID compliance) at its core. Its data is stored in a row-oriented format, meaning all the data for a single record (e.g., one sale's ID, city, amount, and timestamp) is stored together. This is efficient for fetching an entire record at once, as is common in application backends.
pgrust, by contrast, is built as an OLAP engine. It uses a columnar storage format. In this model, all values for a single column (e.g., all 100 million city values) are stored together, and all values for the sales column are stored together in a separate block. When the benchmark query runs, the engine only needs to read the city and sales columns. It can completely ignore the data for every other column in the table, dramatically reducing the amount of data read from memory or disk. This is precisely why ClickHouse, which also uses a columnar architecture, is so much faster than Postgres on this test.
pgrust takes this a step further by implementing a vectorized execution engine, another hallmark of modern high-performance analytical systems. Instead of processing data one row at a time in a tight loop, a vectorized engine processes data in batches, or "vectors." This approach significantly reduces the overhead of the query interpreter and makes better use of modern CPU caches and instruction sets.
Deconstructing the Architecture
The project's design rests on several modern pillars of systems programming and database design, which together explain its performance on the benchmark query.
Written in Rust
The choice of Rust is central to the project's identity. Rust provides C-like performance without the manual memory management that often leads to bugs, memory leaks, and security vulnerabilities in large C/C++ codebases like PostgreSQL. Its ownership and borrowing system allows for fearless concurrency, enabling developers to write highly parallel code that can take full advantage of multi-core processors without data races. For a database engine, where performance and reliability are paramount, these features are a compelling advantage.
Columnar Storage
As mentioned, storing data by column rather than by row is the most significant architectural departure from PostgreSQL. This design offers two primary benefits for analytical queries. First, it minimizes I/O by only reading the required columns. Second, because all data in a column is of the same type, it creates opportunities for highly effective compression. For example, a column of integers with a small range can be compressed far more efficiently than a row containing a mix of integers, strings, and timestamps.
Vectorized Execution and SIMD
Vectorized execution works hand-in-hand with columnar storage. When data is laid out contiguously in columns, the engine can load a chunk of it into a vector and apply an operation to the entire batch at once. This is where modern CPUs' SIMD (Single Instruction, Multiple Data) capabilities come into play. SIMD instructions allow the processor to perform the same operation—for example, an addition or comparison—on multiple data points simultaneously. A traditional row-by-row engine cannot easily leverage SIMD, but for a vectorized engine operating on columnar data, it provides a massive performance boost.
Together, these architectural choices mean pgrust is not so much a rewrite of PostgreSQL as it is a new analytical database engine, inspired by systems like DuckDB and ClickHouse, but built from the ground up in Rust.
A Proof of Concept, Not a Replacement
It is crucial to frame pgrust in its current context: it is an early-stage, experimental project. The impressive benchmark is a proof of concept for its architecture, not a sign of production readiness. Building a robust, general-purpose database is a monumental undertaking that typically spans decades. PostgreSQL's strength lies not just in its performance but in its reliability, its vast feature set, and its thriving ecosystem, all cultivated over more than 30 years of continuous development.
pgrust currently lacks most of the features required for a general-purpose database. The SQL dialect it supports is minimal. There is no mention of transactions, ACID compliance, complex joins, indexes beyond a basic implementation, user-defined functions, or the rich extension framework that makes PostgreSQL so versatile. It is a specialized engine designed to do one thing—fast analytical aggregations—exceptionally well.
This specialization makes it an exciting project but also defines its limitations. It cannot serve as a drop-in replacement for PostgreSQL in applications that rely on transactional guarantees or a broad SQL feature set. Its name may cause some confusion, but its architecture places it firmly in the category of analytical data engines.
What to Watch Next
The emergence of pgrust is best understood as a compelling experiment and a data point in two major industry trends: the adoption of Rust for building critical, high-performance infrastructure, and the ongoing innovation in specialized analytical database engines. The project demonstrates that the architectural principles of the OLAP world can be implemented in Rust to achieve state-of-the-art performance.
For developers and observers, the key questions for the future of pgrust are not about whether it will replace PostgreSQL tomorrow. Instead, we should watch its evolution. Will the project's developers expand its SQL support to handle more complex analytical queries? Can the performance claims be replicated across a wider variety of benchmarks, datasets, and hardware? And, most importantly, can the project attract a community of contributors to help it mature from a promising benchmark into a more fully-featured, reliable engine?
For now, pgrust is not a tool for production deployments. It is a project to star on GitHub, a codebase to study for its implementation of modern database techniques, and a fascinating example of what becomes possible when new tools are applied to old problems.