PostgreSQL di Rust: pgrust 100% Lolos Regression Tests pada Juli 2026

Pada Juli 2026, dunia database dihebohkan oleh sebuah proyek ambisius: pgrust, sebuah rewrite total PostgreSQL dalam bahasa Rust yang berhasil melewati 100% regression tests resmi PostgreSQL 18.3 — lebih dari 46.000 kueri uji. Proyek ini bukan sekadar eksperimen akademis. Dikembangkan oleh malisper dan Jason Seibel dengan biaya sekitar $100.000 dan empat kali percobaan, pgrust membuktikan bahwa database paling populer di dunia bisa dibangun ulang dengan bahasa yang lebih aman, modern, dan mudah dimodifikasi. Artikel ini membahas secara mendalam apa itu pgrust, bagaimana ia dibangun, tantangan teknisnya, dan apa artinya bagi masa depan infrastruktur data.

Pemahaman Dasar: Mengapa PostgreSQL Ditulis Ulang di Rust?

PostgreSQL adalah relational database management system (RDBMS) yang telah dikembangkan selama lebih dari 35 tahun. Kode sumbernya ditulis dalam bahasa C, yang meskipun sangat kuat dan efisien, memiliki kelemahan klasik: memory safety. Bug seperti buffer overflow, use-after-free, dan null pointer dereference masih sering ditemukan di basis kode sebesar PostgreSQL. Menurut riset Microsoft dan Google, sekitar 70% dari kerentanan keamanan pada proyek infrastruktur besar disebabkan oleh memory safety issues di kode C dan C++.

Rust hadir sebagai solusi modern. Rust menjamin memory safety tanpa garbage collector melalui sistem ownership, borrowing, dan lifetimes yang diperiksa saat kompilasi. Selain itu, Rust menawarkan:

• Zero-cost abstractions — kode Rust bisa secepat C tanpa overhead runtime.
• Concurrency tanpa data race — type system Rust mencegah akses bersamaan ke data yang sama tanpa sinkronisasi yang benar.
• Toolchain modern — Cargo, crates.io, dokumentasi terintegrasi, dan compiler error messages yang sangat informatif.
• Ekosistem AI-friendly — karena aturan tipenya ketat dan deterministik, AI coding assistant seperti Claude Opus dan Codex menghasilkan kode Rust yang lebih benar dibanding C.

Proyek pgrust tidak bertujuan menggantikan PostgreSQL secara instan. Tujuan utamanya lebih strategis: membuat PostgreSQL lebih mudah diubah dari dalam. Dengan basis kode Rust yang lebih terstruktur dan aman, pengembangan fitur baru seperti built-in connection pooling, multithreaded query execution, dan storage engine alternatif bisa dilakukan dengan risiko lebih rendah.

💡 Poin Kunci: pgrust mempertahankan kompatibilitas disk penuh dengan PostgreSQL 18.3. Artinya, Anda bisa mengarahkan pgrust ke direktori data PostgreSQL yang sudah ada dan langsung menggunakannya — tanpa migrasi, tanpa dump-restore. Ini adalah pendekatan "drop-in replacement" yang paling agresif sepanjang sejarah PostgreSQL.

Implementasi: Empat Percobaan Menuju Terobosan

Perjalanan membangun pgrust tidaklah mudah. Tim menghabiskan empat percobaan terpisah — dan sekitar $100.000 dalam biaya API AI — sebelum akhirnya berhasil. Mari kita bedah setiap percobaan dan pelajaran yang didapat.

Percobaan #1 — pgrust-og (One Feature at a Time)

Pendekatan awal adalah porting PostgreSQL satu fitur dalam satu waktu. Tim memulai dengan subsistem inti: parser, planner, dan executor. Karena penulis sudah sangat memahami arsitektur PostgreSQL, mereka memberikan instruksi detail ke AI untuk menulis ulang setiap subsistem ke Rust. Pendekatan ini bekerja baik untuk fondasi awal — parser dan planner selesai dalam beberapa hari.

Namun masalah muncul saat skala bertambah. PostgreSQL memiliki lebih dari 300 tipe data, 500 keyword SQL, dan 3.000+ fungsi bawaan. Mengimplementasikan satu per satu secara manual tidak akan selesai dalam waktu wajar. Tim menyadari bahwa AI terlalu bagus dalam menulis satu fitur — ironisnya, justru ini yang menjadi bottleneck. Mereka menghabiskan sebagian besar waktu menunggu AI menyelesaikan satu fitur, bukan bekerja secara paralel.

Percobaan #2 — Parallel Agents dengan Conductor

Untuk percobaan kedua, tim menggunakan Conductor, sebuah tool untuk mengelola banyak sesi agent AI secara bersamaan. Mereka menjalankan hingga 40 subagent secara paralel, masing-masing mengerjakan satu fitur PostgreSQL dan menulisnya ke Rust secara independen. Karena setiap fitur relatif independen (setidaknya dalam hal parser dan tipe data), paralelisasi ini bekerja sangat baik.

Namun, pendekatan ini memiliki kelemahan: tidak ada konsistensi arsitektural antar modul. Satu subagent mungkin mengimplementasikan tipe numeric dengan satu struktur data, sementara subagent lain menggunakan pendekatan berbeda untuk tipe jsonb. Hasilnya adalah basis kode yang berfungsi tetapi sulit dirawat.

Percobaan #3 — File-by-File Porting

Tim kemudian beralih ke strategi porting per file. Alih-alih porting per fitur, mereka mengambil satu file C PostgreSQL dan menulis ulang ke Rust, mempertahankan struktur internal yang sama. Pendekatan ini menghasilkan basis kode yang lebih rapi dan lebih mudah diverifikasi. Namun, metode ini lebih lambat karena setiap file harus dipahami dan di-port secara menyeluruh.

Percobaan #4 — The Breakthrough (AI-Assisted Full Rewrite)

Percobaan keempat akhirnya mencapai terobosan. Tim menggabungkan pelajaran dari tiga percobaan sebelumnya:

1. Gunakan parallel agents tapi dengan template arsitektur yang ketat.
2. Setiap agent diberi context spesifik — potongan kode C yang relevan, contoh output regression test, dan aturan gaya Rust yang harus diikuti.
3. Semua kode yang dihasilkan langsung dijalankan melawan PostgreSQL regression test suite sebagai gate — hanya kode yang lolos semua test yang diterima.
4. Tim mendefinisikan "skills" — prompt templates reusable untuk berbagai pola rewriting yang umum.

Hasilnya: 1,8 juta baris kode Rust idiomatik yang melewati 46.000+ regression queries PostgreSQL 18.3. Berikut adalah contoh bagaimana koneksi database bekerja di pgrust dibanding PostgreSQL asli:

-- PostgreSQL asli (C) — koneksi via fork()
-- Setiap koneksi = satu proses child
$ psql -h localhost -p 5432 -U postgres -d mydb
mydb=# SELECT version();
                                    version
-------------------------------------------------------------------
 PostgreSQL 18.3 on x86_64-linux

-- pgrust (Rust) — koneksi via thread
-- Setiap koneksi = satu thread dalam satu proses
$ psql -h /tmp -p 5432 -U postgres -d postgres
postgres=# SELECT version(), 1 + 1 AS two;
                                          version
-----------------------------------------------------------------------------
 pgrust v0.1 on x86_64-linux, based on PostgreSQL 18.3
(1 row)

Untuk menjalankan pgrust di lingkungan pengembangan:

# 1. Inisialisasi data directory
target/release/postgres --initdb \
  -D /tmp/pgrust-data \
  -L "$PWD/vendor/postgres-18.3/share" \
  --no-locale \
  --encoding UTF8 \
  -U postgres

# 2. Jalankan server pgrust
ulimit -s 65520
RUST_MIN_STACK=33554432 target/release/postgres \
  -D /tmp/pgrust-data \
  -F \
  -c listen_addresses= \
  -k /tmp \
  -p 5432 \
  -c io_method=sync \
  -c max_stack_depth=60000

# 3. Konek via psql standar
psql -h /tmp -p 5432 -U postgres -d postgres

Studi Kasus: Performa pgrust vs PostgreSQL vs ClickHouse

Salah satu klaim paling mengejutkan dari tim pgrust adalah performa versi terbaru (masih dalam pengembangan, belum dipublikasikan). Dalam benchmark internal, versi pgrust yang menggunakan model thread-per-connection (bukan process-per-connection seperti PostgreSQL asli) menunjukkan hasil luar biasa:

* ClickHouse ditulis dalam C++, yang juga rentan terhadap memory safety issues.

Bagaimana pgrust versi terbaru bisa 300x lebih cepat dari PostgreSQL untuk beban analitis? Ada beberapa faktor:

• Eksekusi paralel multithread — tidak terbatas oleh model one process per connection PostgreSQL yang berat.
• Vectorized execution — memproses data dalam batch (seperti ClickHouse) alih-alih baris per baris.
• Eliminasi VACUUM — arsitektur storage baru yang tidak memerlukan proses VACUUM sama sekali, menghilangkan overhead maintenance yang signifikan.
• Cache-friendly data structures — Rust memungkinkan kontrol memori yang lebih presisi untuk memanfaatkan CPU cache hierarchy.

Penting untuk dicatat: versi v0.5 ini belum dirilis ke publik. Namun, trajectory performanya menunjukkan bahwa pendekatan rewrite Rust + AI-assisted optimization bisa menghasilkan lompatan 1-2 order of magnitude.

💡 Implikasi Besar: Jika pgrust v0.5 benar-benar mencapai performa 2x ClickHouse untuk query analitis — sambil tetap mempertahankan kompatibilitas penuh dengan PostgreSQL — ini akan menjadi pengubah permainan (game changer) untuk industri database. Satu database untuk OLTP dan OLAP, dengan keamanan memori Rust, tanpa biaya migrasi.

Analisis Arsitektural: Process-per-Connection vs Thread-per-Connection

Salah satu perbedaan arsitektural paling fundamental antara PostgreSQL dan pgrust adalah model konkurensi. PostgreSQL menggunakan process-per-connection: setiap koneksi client mendapat satu proses child (forked dari postmaster). Model ini memiliki beberapa implikasi:

Kelebihan model process-per-connection (PostgreSQL):

• Isolasi memori ketat antar koneksi — satu koneksi crash tidak memengaruhi yang lain.
• Stabilitas terbukti selama 35+ tahun di berbagai workload.
• Kompatibilitas dengan berbagai sistem operasi dan lingkungan cloud.

Kekurangan model process-per-connection:

• Overhead memori tinggi — setiap proses child bisa memakan 10-30 MB RAM meskipun idle.
• Context switching berat saat ribuan koneksi simultan.
• Shared memory complex — komunikasi antar proses via System V atau POSIX shared memory segments.
• Fork() lambat untuk workload dengan banyak koneksi pendek (short-lived connections).

pgrust mengadopsi model thread-per-connection yang lebih ringan:

• Semua thread berbagi ruang alamat yang sama — komunikasi via pointer biasa, bukan shared memory segments.
• Overhead per-thread hanya beberapa MB — memungkinkan puluhan ribu koneksi simultan.
• Context switching lebih murah karena thread dalam proses yang sama.

Perubahan model konkurensi ini sendiri berkontribusi signifikan terhadap peningkatan performa transaksional. Dalam benchmark internal yang dirilis tim pgrust, versi thread-per-connection menunjukkan throughput 50% lebih tinggi dibanding PostgreSQL asli untuk workload OLTP standar seperti TPC-C.

Namun, ada trade-off: thread-per-connection berarti satu thread yang crash bisa membawa turun seluruh server. Di sinilah keunggulan Rust berperan — jaminan memory safety di level kompilasi secara drastis mengurangi risiko crash akibat null pointer, buffer overflow, atau data race. Tim pgrust mengklaim tidak ada satupun crash akibat memory safety issue selama pengujian regression suite.

Ekosistem Database 2026: Posisi pgrust di Lanskap yang Lebih Luas

pgrust tidak muncul di ruang hampa. Tahun 2026 menyaksikan beberapa tren besar di dunia database yang membuat proyek ini semakin relevan:

1. Database Modern dalam Rust

Rust menjadi bahasa pilihan untuk database generation baru. Contohnya: DuckDB (OLAP embedded), RisingWave (streaming database), GreptimeDB (time-series), dan Qdrant (vector search). pgrust adalah yang pertama mencoba membawa paradigma Rust ke database relasional legacy terbesar.

2. AI-Driven Database Optimization

Dengan maraknya AI coding agents (Claude Codex, Cursor, Copilot), pgrust menunjukkan pendekatan baru: tidak hanya menggunakan AI untuk menulis kode, tetapi juga untuk mengoptimalkan query execution dan storage engine. Tim pgrust saat ini sedang mengembangkan runtime guardrails yang secara otomatis mendeteksi dan mencegah query buruk yang dihasilkan AI — sebuah fitur yang tidak dimiliki database manapun saat ini.

3. Pergeseran dari Database Spesialis ke Generalis

Selama satu dekade terakhir, tren database bergerak ke spesialisasi: database time-series, vector database, document store, graph database — masing-masing dengan engine terpisah. Namun, biaya operasional menjalankan multiple database systems mendorong pergeseran kembali ke converged database. pgrust dengan PostgreSQL compatibility dan performa analitis yang mendekati ClickHouse berpotensi menggantikan beberapa database spesialis sekaligus.

4. PostgreSQL Dominasi Terus Meningkat

Menurut Stack Overflow Survey 2026, PostgreSQL telah melampaui MySQL dalam popularitas untuk ketiga kalinya berturut-turut. Dengan Postgres 18 yang membawa incremental backup native, merge join yang dioptimasi, dan SQL/JSON constructor functions, basis penggunanya terus bertambah. pgrust adalah langkah logis berikutnya: mempertahankan semua keunggulan PostgreSQL sambil menghilangkan kelemahan arsitektural bahasa C.

5. Biaya Cloud dan Efisiensi Resource

Efisiensi memori dan CPU dari pgrust (thread-per-connection, zero-copy abstractions) berarti biaya infrastktur yang lebih rendah. Untuk startup dan enterprise di Indonesia yang sangat sensitif terhadap biaya cloud, potensi penghematan 30-50% pada biaya database bisa menjadi faktor adopsi yang kuat di masa depan.

Best Practice: Mengadopsi Pendekatan pgrust untuk Proyek Legacy Rewrite

Meskipun pgrust adalah proyek raksasa yang mungkin tidak relevan langsung untuk kebanyakan tim, ada prinsip-prinsip berharga yang bisa dipetik:

1. Regression Test Suite adalah GPS Anda

Tim pgrust menggunakan 46.000+ regression queries PostgreSQL sebagai source of truth. Setiap baris kode Rust harus menghasilkan output yang identik dengan PostgreSQL asli. Ini adalah pendekatan yang sangat disiplin dan efektif. Dalam proyek rewrite apapun, pastikan Anda memiliki test suite yang komprehensif sebelum memulai. Test tersebut menjadi jaring pengaman yang memungkinkan AI coding agent bekerja tanpa pengawasan konstan.

2. Gunakan Parallel Agents dengan Template Ketat

Salah satu inovasi kunci pgrust adalah penggunaan Conductor untuk menjalankan 40 agent secara paralel. Namun, template dan spesifikasi arsitektur harus seragam. Tanpa ini, Anda akan mendapatkan basis kode yang tidak konsisten. Definisikan:

• Konvensi penamaan yang baku.
• Struktur modul dan direktori.
• Pola error handling yang seragam (misalnya, Result<T, Error> vs Option<T>).
• Dokumentasi minimum per fungsi.

3. Definisikan "Skills" untuk AI Agent

Tim pgrust mendefinisikan skills — prompt templates reusable untuk tugas rewriting yang berulang. Misalnya, "bagaimana cara rewrite implementasi tipe data Postgres ke Rust" atau "bagaimana cara port fungsi utilitas Postgres". Dengan skills ini, agent AI bisa bekerja lebih cepat dan lebih konsisten. Investasi waktu untuk membuat skills yang baik akan terbayar berkali-kali lipat saat diterapkan ke ratusan file.

4. Prioritaskan Kompatibilitas, Optimasi Belakangan

Filosofi pgrust jelas: kompatibilitas dulu, performa nomor dua. Versi v0.1 bahkan belum dioptimasi sama sekali — fokusnya 100% pada kebenaran output. Ini adalah pendekatan yang tepat untuk rewrite sistem legacy. Jika Anda bisa memastikan sistem baru menghasilkan hasil yang identik dengan sistem lama, Anda bisa melakukan deploy bertahap (canary release) tanpa risiko divergensi data.

5. Pertimbangkan Biaya API AI

Tim pgrust menghabiskan $100.000 untuk biaya API AI (terutama Claude Opus dan Codex) selama proses pengembangan. Untuk tim yang ingin mengikuti jejak serupa, penting untuk:

• Memiliki metrik yang jelas tentang kapan kualitas output AI cukup baik.
• Menggunakan caching prompt untuk menghindari pembayaran berulang untuk transformasi yang sama.
• Memilih model yang cost-effective — model kecil untuk tugas sederhana, model besar hanya untuk tugas kompleks.

-- Contoh: Verifikasi kompatibilitas pgrust dengan PostgreSQL
-- Gunakan regression test suite bawaan pgrust

$ PGRUST_BIN="$PWD/target/release/postgres" scripts/run-regression
[...]
========================================================
All 46,320 regression tests PASSED.
Isolation tests: 196/196 passed.
========================================================

-- Bandingkan output query yang sama di kedua engine

-- Di PostgreSQL 18.3:
$ psql -p 5433 -U postgres -c "SELECT jsonb_typeof('[]'::jsonb)" 
 jsonb_typeof
--------------
 array

-- Di pgrust:
$ psql -h /tmp -p 5432 -U postgres -c "SELECT jsonb_typeof('[]'::jsonb)"
 jsonb_typeof
--------------
 array
(1 row)
-- Output identik!

Kesimpulan: Masa Depan PostgreSQL dan Database di Era Rust

Pgrust adalah salah satu proyek database paling ambisius di tahun 2026. Keberhasilannya melewati 100% regression tests PostgreSQL 18.3 membuktikan bahwa rewrite total sistem legacy dengan AI-assisted programming bukan lagi fiksi ilmiah. Ini adalah blueprint yang bisa diikuti oleh proyek-proyek infrastruktur lain — dari web server, message queue, hingga jaringan protokol.

Namun, penting untuk tetap realistis. pgrust versi v0.1 saat ini:

• Belum production-ready — jangan digunakan untuk beban kerja nyata.
• Tidak kompatibel dengan ekstensi PostgreSQL — semua ekstensi populer seperti PostGIS, pgvector, TimescaleDB, dan Citus belum bisa digunakan.
• Belum dioptimasi performa — versi saat ini sedikit lebih lambat dari PostgreSQL asli untuk beban transaksional.
• Hanya mendukung Linux dan macOS — port Windows masih dalam rencana.

Roadmap pgrust ke depan sangat ambisius:

• Multithreaded query execution — memanfaatkan CPU multi-core untuk satu query.
• Built-in connection pooling — mengurangi overhead koneksi database.
• Storage engine tanpa VACUUM — menghilangkan beban maintenance terbesar PostgreSQL.
• Runtime guardrails untuk AI-generated SQL — mencegah query buruk yang dihasilkan agent AI.
• Branching dan fork cepat — untuk workflow development dan testing.
• Dukungan ekstensi — kompatibilitas dengan ekosistem ekstensi PostgreSQL yang kaya.

Bagi praktisi database dan DevOps di Indonesia, pgrust adalah proyek yang wajib dipantau. Jika roadmap-nya berhasil dijalankan, dalam 1-2 tahun ke depan kita mungkin akan melihat pgrust menjadi fondasi bagi layanan database managed di cloud — menggabungkan keandalan PostgreSQL dengan performa dan keamanan Rust.

Database relasional mungkin sudah berusia 50 tahun, tetapi inovasi di bidang ini masih berjalan sangat cepat. pgrust membuktikan bahwa dengan alat yang tepat — AI, Rust, dan pendekatan engineering yang disiplin — kita bisa membangun ulang fondasi data modern yang lebih baik, lebih aman, dan lebih cepat.

Untuk mencoba pgrust sendiri, kunjungi github.com/malisper/pgrust atau coba demo browser di pgrust.com. Bergabunglah dengan komunitas di Discord untuk mengikuti perkembangan terbaru dari proyek yang mendefinisikan ulang apa yang mungkin dilakukan dengan PostgreSQL.