Making Postgres 300x faster for analytics: batching, operator fusion, and SIMD
A new Rust-based reimplementation of PostgreSQL, pgrust, claims up to 300x faster analytic queries through batch execution, operator fusion, SIMD, and a redesigned scheduler, and early benchmarks suggest it can rival or beat systems like ClickHouse on certain workloads. Commenters are sharply divided over its heavy use of AI-generated code, the reliability and safety of a rapidly produced systems-level database, and whether formal verification and fuzzing are enough to trust it in production. Licensing is another flashpoint: the choice of AGPL is seen by some as necessary to stop cloud giants from monetizing the work, while others argue it will block corporate adoption and contributions, prompting talk of forks or alternative licenses.
Licensing, Business Model, and Adoption
- Major thread focus is the AGPL license. Many say it’s a “dealbreaker,” especially in corporate settings where AGPL is banned or heavily discouraged, and it blocks upstreaming into core Postgres.
- Supporters argue AGPL (or similar copyleft) is now standard for databases to prevent cloud providers from monetizing permissively licensed work without contributing back.
- Several suggest dual-licensing (AGPL + commercial) and setting up proper contribution agreements; some worry that only the core company will benefit financially from community work.
- There’s confusion and disagreement about what AGPL requires; some claim normal DB clients are safe, others stress AGPL is legally untested and risky.
- Some note that if the performance gain is real, big players could re‑port Postgres themselves under permissive terms, especially given the apparent low cost with AI help.
AI-Generated Port and Copyright Concerns
- The repo’s commit history shows thousands of AI-coauthored commits over a month; some call it “AI slop” or “vibecoded” and question human review depth.
- Process described: C→Rust via c2rust, then heavy LLM refactoring plus tests. Critics argue this is clearly a derived work and morally (if not legally) dubious to relicense to AGPL.
- There’s debate about whether LLM-generated code is copyrightable at all; some suggest the license might be moot but this is flagged as unclear.
Performance Claims and Benchmarks
- The marketing claim is ~300x faster than Postgres for analytics; several commenters are skeptical.
- Critics highlight that a demo disabled Postgres parallelism, making comparisons look worse; maintainers say the 300x figure comes from ClickBench results with parallelism enabled.
- One external expert reportedly reviewed ClickBench runs and confirmed major speedups; others caution that tests may reflect specific memory-resident analytic workloads, not general OLTP use.
- Discussion notes that many workloads are memory- and cache‑bound; columnar and vectorized execution can legitimately produce very large gains for certain analytic queries.
Correctness, Reliability, and Longevity
- The project team emphasizes correctness: formal verification of ~1000 functions, differential fuzzing vs Postgres, and external engagements for fault testing and verification.
- They report ~100 bugs found in pgrust and ~20 in Postgres, including subtle floating‑point bugs.
- Many still worry that a young, AI‑generated system DB cannot match Postgres’s decades of battle‑testing; concerns about data corruption and long‑term maintenance are frequent.
Architecture, Features, and Use Cases
- pgrust adds columnar storage as a table access method, adaptive planning, a new query scheduler with resource throttling and work stealing, and a “test mode” to speed DB cloning.
- It can be embedded (including to Wasm) and may support per‑test ephemeral DBs, read‑only analytics replicas via WAL, and lighter-weight deployments.
- Some see it as a promising Postgres-compatible analytic engine; others doubt it will displace Postgres but can coexist for specific workloads.