pgrust is a Rust reimplementation of Postgres attracting renewed developer attention. Its current repository labels the release v0.4-beta and advises against production use, recommending that important data remain authoritative in Postgres. That warning should frame an evaluation before a performance headline does. [1]
Read the status before the speed claim
The project describes SQL and wire compatibility, but also documents bugs, no stable extension ABI and unsupported procedural languages including PL/Python. It reports formal verification for a subset of functions alongside differential testing. These are project claims, not an independent certification of the whole database. [1]
Dan Luu's discussion of ambitious software projects points to pgrust's testing and upstream bug reports as evidence of substantive engineering. That is a reason to inspect the evidence, not a substitute for validating your application. His essay also distinguishes a project that works for its author from a useful product's higher quality bar. [2]
A driver connecting successfully establishes only a small part of the question. Your application may depend on specific error behavior, extension functions, transaction boundaries or recovery procedures. Write down those dependencies before you run a demonstration query.
Define a trial that cannot become an accidental migration
Use a separate environment and a disposable, appropriately sanitized dataset. Keep production connection settings out of the experiment. Document which server, build and endpoint each test uses so that a familiar database client does not hide an unintended connection.
The repository itself warns that an existing Postgres server can cause confusion and recommends checking select version(). Treat identity confirmation as the first result you record. [1]
Choose a bounded application path: for example, one reporting query plus the writes that supply its input. Record expected results from the reference system, including empty input, duplicate values and failed operations. Decide the acceptance criteria before comparing timings.
Test correctness and recovery as separate questions
A matching answer today does not tell you whether the same state returns after a failed write or interrupted process. In the isolated trial, define the recovery behavior your application requires, then measure it. Keep a failure log with the input, expected outcome, actual outcome and exact build.
PostgreSQL's official backup guide distinguishes SQL dumps, file-system backups and continuous archiving. Its SQL-dump documentation notes that pg_dump covers a single database and does not include cluster-wide roles or tablespaces. Those distinctions matter when defining what a complete recoverable copy means. [3][4]
These PostgreSQL documents do not certify pgrust's recovery behavior. Test the proposed trial's restore procedure independently, including the permissions needed by the application. Do not infer cross-system restore compatibility merely from a familiar file name or command.
Make performance relevant to the actual job
The project's headline comparison uses analytical queries with its columnar layout. It does not establish that every transaction workload gets the same gain. [1]
For your trial, keep the input data and result checks fixed. Report latency and throughput alongside memory use, concurrency and failures. Include a realistic mixture of reads and writes if that is what your application does. A faster incorrect result or an unmeasured recovery cost should not disappear from the scorecard.
Decide what the trial actually permits
- Continue a limited experiment only when its dependencies and results are understood.
- Report a reproducible failure with the exact build and a minimal non-sensitive example.
- Keep the authoritative database and its recovery process intact.
- Reassess the project's documented status before considering any broader adoption.
This is a proposed evaluation method. We have not run pgrust or reproduced its benchmarks. A successful trial can establish that one bounded workload deserves more investigation; it cannot establish general production readiness.
What does your database trial prove?
Sources
[1] pgrust official repository, status, testing and performance documentation, reviewed October 25, 2026: https://github.com/malisper/pgrust
[2] Dan Luu, We should be more ambitious with the software we build: https://danluu.com/ambitious/
[3] PostgreSQL 18 documentation, Backup and Restore: https://www.postgresql.org/docs/18/backup.html
[4] PostgreSQL 18 documentation, SQL Dump: https://www.postgresql.org/docs/18/backup-dump.html