Primary question: Can pgrust serve as a trustworthy Postgres-compatible server in Rust while opening the door to internal changes that C Postgres cannot easily make?
RepoDaily adoption score
RepoDaily rates this as 85/100 (strong) for adoption: evidence, installation path, production risk, differentiation, license clarity, and AI/agent fit are scored from the article sources and adoption notes.
5 source(s) across 4 source category/categories, plus a RepoDaily-specific evidence module when available.
5 workflow step(s), 5 next-action step(s), and 4 command/install signal(s) were detected.
Trending momentum is +518 stars, with maintenance/release/issue signals counted when present.
Risk is marked high, with 4 security note(s) and 4 explicit skip condition(s).
3 opportunity lens item(s), 3 alternative(s), and 4 type-specific section(s) support differentiation.
License source or license wording is present.
5 AI/agent-related signal(s) were detected in the article text and metadata.
Project overview
pgrust is a from-scratch rewrite of PostgreSQL 18.3 in Rust, created by Malisper and currently trending with 518 stars over the latest period. The project targets behavioral compatibility: it matches Postgres expected output across more than 46,000 regression queries and is disk compatible with an existing Postgres 18.3 data directory. An upcoming, not-yet-published version reportedly passes 100 percent of the Postgres regression suite, switches from Postgres's process-per-connection model to a thread-per-connection model, and is 50 percent faster than Postgres on transaction workloads and roughly 300x faster on analytical workloads.
The README is explicit about what pgrust is not: it is not production-ready and is not performance optimized in its current public release. Existing Postgres extensions and procedural languages such as PL/Python, PL/Perl, and PL/Tcl are not generally compatible. Some bundled contrib modules have been ported, and the roadmap calls for multithreaded internals, built-in connection pooling, JSON-heavy workload support, storage experiments including no-vacuum designs, runtime guardrails for bad queries and AI-generated SQL, and fewer sudden bad plan switches.
The Docker image is engineered as a drop-in replacement for the official postgres Docker image. It honors the same POSTGRES_PASSWORD, POSTGRES_USER, POSTGRES_DB, POSTGRES_INITDB_ARGS, POSTGRES_HOST_AUTH_METHOD, and PGDATA environment variables, supports /docker-entrypoint-initdb.d first-init scripts, and exposes port 5432 with SIGINT as the stop signal. Both the server and the catalog bootstrap (initdb) are powered by the pgrust binary — a faithful port of initdb.c — with the only remaining C tool being psql, sourced from the PGDG client package.
Why it is trending now
- Targets PostgreSQL 18.3 and matches expected output across 46,000+ regression queries, with an upcoming version passing 100 percent of the Postgres regression suite.
- Disk compatibility means pgrust can boot from an existing Postgres 18.3 data directory, lowering the barrier to evaluation.
- The unpublished version reports 50% higher transaction throughput than Postgres and ~300x faster analytical workloads (2x slower than ClickHouse on clickbench).
- The Docker image mirrors the official postgres image contract — same env vars, same entrypoint, same port — making it a near-seamless swap in existing compose files.
- The roadmap addresses pain points the C codebase struggles with: thread-per-connection, no-vacuum designs, and guardrails for AI-generated SQL.
Problem it solves
- Postgres's process-per-connection model consumes significant memory per connection and complicates built-in connection pooling.
- Modifying the C Postgres codebase is difficult; deeper structural changes such as threading, storage redesign, and plan stability are slow to land upstream.
- Extension and procedural language compatibility (PL/Python, PL/Perl, PL/Tcl) is incomplete in pgrust, limiting immediate drop-in scenarios.
- The project is explicitly pre-production and not performance-optimized in its current public release.
How it works
- pgrust rewrites the PostgreSQL 18.3 server binary in Rust, using vendored Postgres artifacts (postgres.bki, system_*.sql, system_views.sql, tz data) from the PGDG distribution for catalog bootstrap and timezone resolution.
- The --initdb driver is a faithful port of initdb.c in Rust, eliminating the need for C initdb in the Docker image.
- The build produces a single postgres binary via cargo build --release --locked --bin postgres, with PGRUST_PGSHAREDIR baked in at build time to locate the share tree.
- The server reads from and writes to the same on-disk format as Postgres 18.3, enabling it to boot directly from an existing data directory.
- An upcoming version switches from process-per-connection to thread-per-connection, which the project expects will reduce per-connection memory overhead and enable internal parallelism.
How to Try pgrust Today
The fastest path is the browser demo at pgrust.com, which runs pgrust compiled to WebAssembly. For a local evaluation, Docker is the recommended route. The pinned launch image is malisper/pgrust:v0.1; the latest tag currently points at the same release.
The Docker run command from the README creates a container named pgrust with POSTGRES_PASSWORD=secret, polls psql inside the container until the server responds, and then drops into an interactive psql session. The image bundles psql from the PGDG PostgreSQL 18 client package — pgrust does not yet ship its own psql replacement.
Building from source requires ICU, OpenSSL, libpq, and platform-specific dev packages. On Debian/Ubuntu: sudo apt-get install -y build-essential pkg-config libicu-dev libssl-dev libldap2-dev libpam0g-dev postgresql-client-18. On macOS: brew install icu4c openssl@3 libpq, plus exported LIBRARY_PATH, PKG_CONFIG_PATH, and PATH variables. The build command is PGRUST_PGSHAREDIR="$PWD/vendor/postgres-18.3/share" cargo build --release --locked --bin postgres.
Workspace Structure and Scope
- The Cargo.toml workspace contains dozens of crates under crates/_support/, covering type bindings (array, brin, gin, gist, hash, nbtree, spgist), replication (replication, replication_launcher, replication_slot_2), and JSON handling (types_json, types_jsonb, types_jsonfuncs, types_jsonpath).
- Support infrastructure includes a PRNG port (pg/prng, pg/prng_seams), resource usage seams (rusage, rusage_seams), a trace crate, and a todo_guard crate — suggesting the port tracks unconverted or stubbed code paths.
- The vendored nodetags.h (crates/_support/types/nodes/vendor/nodetags.h) is baked into the build, meaning the Rust build stage needs no PostgreSQL C source tree — only the Rust toolchain and libicu-dev.
Docker Image Internals
- Three-stage Dockerfile: Stage 1 (rustbuild) uses rust:1-bookworm to build the postgres binary; Stage 2 (pgtools) harvests psql, libpq, and the share tree from PGDG packages; Stage 3 (final) assembles the runtime.
- The final image contains no C postgres backend and no C initdb — only the pgrust postgres binary plus psql and libpq from PGDG.
- Environment contract matches official postgres: POSTGRES_PASSWORD, POSTGRES_USER, POSTGRES_DB, POSTGRES_INITDB_ARGS, POSTGRES_HOST_AUTH_METHOD, PGDATA at /var/lib/postgresql/data (VOLUME), postgres unix user (uid 999), /var/run/postgresql socket dir, EXPOSE 5432, STOPSIGNAL SIGINT.
- Entrypoint and CMD mirror the official image: ENTRYPOINT ["docker-entrypoint.sh"], CMD ["postgres"], with gosu step-down.
What to Verify Before Adopting
- Confirm your workload does not depend on PL/Python, PL/Perl, PL/Tcl, or other C-linked extensions — these are not generally compatible.
- Verify that the contrib modules you rely on are among those already ported (the README states some bundled contrib modules are ported but does not enumerate which).
- Note the stack size requirements: build-from-source run instructions set ulimit -s 65520 and RUST_MIN_STACK=33554432 (32 MB).
- Validate disk-format compatibility by booting pgrust against a copy of your existing Postgres 18.3 data directory before any production-adjacent use.
- Review the AGPL-3.0 license: network-accessible modifications trigger source disclosure obligations under section 13.
Who should pay attention?
Good fit if
- Booting pgrust from a copy of a Postgres 18.3 data directory to validate behavioral compatibility on your own schema.
- Running the WASM demo at pgrust.com or the Docker image for a hands-on evaluation of the Rust port's SQL surface.
- Benchmarking analytical workloads once the unpublished version with thread-per-connection and clickbench-level performance is released.
- Exploring the roadmap items — no-vacuum designs, plan stability, AI-SQL guardrails — as research or prototyping targets.
Skip for now if
- Production deployments: the README explicitly states pgrust is not production-ready.
- Workloads depending on PL/Python, PL/Perl, PL/Tcl, or unported C extensions.
- Environments where AGPL-3.0 licensing creates compliance friction for network-accessible services.
- Scenarios requiring psql from pgrust itself — the project does not yet ship a psql replacement.
Risks and cautions
pgrust is an ambitious and technically impressive rewrite, but it is explicitly pre-production, lacks extension compatibility, and its most compelling performance numbers come from an unpublished version.
- The README states 'pgrust is not production-ready yet' and 'It is not performance optimized yet.'
- PL/Python, PL/Perl, PL/Tcl, and other C-linked extensions are not generally compatible.
- The 100% regression pass rate, thread-per-connection model, and benchmark figures (50% faster on transactions, ~300x on analytical) all come from an unpublished version — the public v0.1 does not include these.
- AGPL-3.0 imposes source disclosure obligations for network-accessible modified versions.
- The workspace contains a todo_guard crate and numerous _support crates suggesting ongoing internal porting work.
- License is AGPL-3.0, which requires operators of network-accessible modified versions to provide source code to users of that server.
- The Docker image bundles psql and libpq from the PGDG PostgreSQL 18 client package — security updates depend on PGDG's release cadence.
- Runtime guardrails for bad queries and AI-generated SQL are listed on the roadmap but not yet implemented.
- The roadmap mentions runtime guardrails but does not specify the status of authentication, row-level security, or encryption compatibility relative to Postgres 18.3.
Alternatives to compare
| Approach | When to use | Trade-off |
|---|---|---|
PostgreSQL (C) | When you need production-proven stability, full extension compatibility, and decades of operational tooling. | Free (PostgreSQL License) |
ClickHouse | When analytical workload speed is the primary requirement — pgrust's unpublished version reports being 2x slower than ClickHouse on clickbench. | Free (Apache 2.0) |
Postgres extension ecosystem (pg_cron, pgvector, PostGIS, etc.) | When your application depends on specific Postgres extensions that pgrust has not yet ported. | Varies by extension |
What this trend reveals
Thread-per-connection Postgres internals
The unpublished version of pgrust replaces Postgres's process-per-connection model with thread-per-connection. This could unlock shared-buffer pooling across connections, lower per-connection memory, and internal parallelism that the process model resists. Engineers who have hit shared_buffers or connection-scaling limits in C Postgres can evaluate pgrust as a testbed for these architectural changes.
Run pgrust's Docker image with a connection-heavy workload and compare RSS per connection against C Postgres on the same data directory.
No-vacuum storage experiments
The roadmap explicitly lists storage experiments including no-vacuum designs. Teams dealing with bloat, autovacuum tuning, or long-running transaction overhead can follow the project's storage experiments as they emerge on the Discord and GitHub issues.
Monitor the pgrust Discord and GitHub issues for storage-experiment branches and benchmark results against vacuum-heavy workloads.
Plan stability and AI-SQL guardrails
The roadmap calls for fewer sudden bad plan switches and runtime guardrails for bad queries and AI-generated SQL. This positions pgrust as a candidate for environments where AI agents generate SQL and plan regressions are an operational risk.
Once the feature lands, compare pgrust's plan stability against C Postgres on a workload of AI-generated queries with varying selectivity.
RepoDaily verdict
pgrust is one of the most ambitious database rewrites in open source: a Rust port of Postgres 18.3 that passes 46,000+ regression queries, boots from existing data directories, and ships as a drop-in Docker image. Its unpublished version — with 100% regression pass rate, thread-per-connection architecture, and clickbench-adjacent analytical speed — signals where the project is heading. For now, treat it as a research testbed and compatibility experiment, not a production database.