malisper/pgrust

Worth an afternoon in a sandbox if you run analytics on Postgres and want to see what a modern engine could do; not yet a database to put your only copy of anything into.

The problem

A team already stores its data in Postgres and wants fast scan-heavy reporting on it. The usual workaround is to copy data out to ClickHouse or another analytical store, then maintain two schemas, two query languages and a sync job. pgrust changes that step: you start a server built to speak Postgres' wire protocol and SQL dialect, point an existing client at it, and can put analytical tables in its columnar layout instead of exporting them. The intended result is one engine for both transactional and analytical work.

What's different

This is not a Postgres extension; it is a re-implementation, aimed at Postgres 18.6 compatibility. The README claims wire and SQL-dialect compatibility, so existing drivers and clients have a plausible path to it, and the Docker image is described as a drop-in replacement for the official postgres image with the same environment variables, init-script directory and data volume. Internally, the author says the new version uses a thread per connection rather than Postgres' process per connection, and that pgrust with its pgrcolumnar table access method runs ClickBench analytical queries up to 1,600x faster than PostgreSQL per query on cold runs on a c8g.4xlarge, compared against PostgreSQL's published results on the same instance type. That is the author's own benchmark, not an independent reproduction, and it describes analytical queries on a columnar layout, not transactional throughput.

The significant trade-off is architectural trust. A thread-per-connection model means one crashing extension can take down the whole server, where Postgres' process model contains it; an HN commenter raised exactly that concern on the July announcement thread comment. Extensions are also a soft spot: there is no stable extension ABI yet, so third-party extensions do not work out of the box, though many popular ones ship bundled. The project does address trust explicitly, with a ledger of 3,400 user-facing functions in which 1,397 have been formally verified for identical behavior with Kani and 466 more tested against Postgres verification ledger. That is evidence of effort, not a guarantee of correctness.

Who should try it

Good fit: a developer or data engineer with an existing Postgres workload who wants to run the same queries against a columnar table and judge the speed claim for themselves, or someone who wants to try a Postgres-compatible server in the browser before installing anything. The browser demo is the lowest-commitment path, and the v0.4-beta release notes describe what changed.

Poor fit: anyone who needs production Postgres today, the README says so directly and recommends Postgres instead. Also a poor fit for teams that depend on a specific third-party extension, or whose workload is mostly short transactions rather than analytical scans, since the headline benchmark is analytical.

Requirements and limitations

Binaries are platform-specific: Linux needs glibc 2.34 or newer (Debian 12, Ubuntu 22.04, RHEL/Rocky 9 and later), macOS needs 11 or newer, and there are separate tuned builds for AMD Zen 3+ and Neoverse-V2 such as Graviton4 downloads. Each tarball is self-contained with its own postgres, initdb and psql, so no PostgreSQL install is needed. Getting started is therefore quick, but the ongoing limitation is compatibility: extension ABI instability and the missing PL/Python, PL/Perl and PL/Tcl mean a workload that leans on those cannot move over unchanged.

The bigger boundary is data safety, not setup. The README says the project is successfully used internally but explicitly keeps Postgres as the source of truth for data you cannot afford to lose, and names testing and reliability as the top priority. Plan to treat pgrust as a read/analytics experiment against a copy, not as a replacement for the primary database.

HotRepo's take

HotRepo records 1,848 to 2,324 stars on the daily board over 2026-07-11 to 2026-07-13, and 5,516 on 2026-10-26; with only four recorded board dates, persistence of interest cannot be judged from these samples. The repository was created on 2026-04-20, so this is a young project. Before investing, check the verification ledger for the specific functions your workload calls, since the README's trust argument rests on that coverage.