Rewrite besar sering kelihatan seperti tombol reset: codebase lama ribet, pindahin ke bahasa yang lebih modern, lalu semua masalah selesai. Sayangnya, software production jarang sesederhana itu.
pgrust menarik karena klaimnya berani: Postgres ditulis ulang dalam Rust, menargetkan kompatibilitas Postgres 18.3, dan melewati 46 ribu lebih regression query. Tapi pelajaran paling penting dari pgrust bukan “Rust pasti menang” atau “rewrite sekarang gampang karena AI”. Pelajaran utamanya: rewrite besar baru layak dipercaya kalau punya bukti teknis yang jelas, batasan yang jujur, dan rencana operasional yang bisa diuji.
Artikel ini ngebahas cara membaca proyek rewrite besar tanpa fanboy bahasa. Fokusnya bukan menilai pgrust sebagai pengganti Postgres production hari ini, karena README proyeknya sendiri bilang belum production-ready dan belum performance optimized. Fokusnya adalah checklist berpikir buat developer: kalau besok tim lu pengin rewrite service, database layer, atau runtime internal, bukti apa yang harus lu minta sebelum percaya?
Apa itu pgrust?
pgrust adalah proyek open-source yang mencoba menulis ulang Postgres dalam Rust. Di README-nya, proyek ini menyebut target kompatibilitas dengan Postgres 18.3, mencocokkan output Postgres lewat 46.000+ regression query, dan bahkan bisa boot dari data directory Postgres 18.3 yang sudah ada.
Itu sinyal teknis yang kuat. Bukan sekadar repo demo “database pakai Rust” yang cuma bisa jalanin query sederhana. Menggunakan regression test Postgres sebagai oracle artinya proyek ini mencoba mengukur perilaku terhadap ekspektasi Postgres asli, bukan bikin standar sendiri yang lebih gampang diluluskan.
Tapi pgrust juga jujur soal statusnya: belum production-ready, belum dioptimasi performa, dan compatibility extension belum umum. Ini bagian yang menurut gua justru sehat. Proyek rewrite yang bagus harus berani nunjukin dua hal sekaligus: sejauh mana bukti yang sudah ada, dan batasan mana yang belum selesai.
Regression test lulus itu penting, tapi belum sama dengan production trust
Kalau sebuah rewrite database bisa melewati regression suite, itu bukan hal kecil. Regression test membantu menangkap perubahan perilaku yang kelihatan sepele tapi bisa fatal: hasil query beda, error message berubah, planner bertindak aneh, atau edge case SQL tiba-tiba pecah.
Dokumentasi PostgreSQL sendiri menjelaskan regression test sebagai cara memverifikasi bahwa sistem berjalan sesuai ekspektasi setelah perubahan. Dalam konteks rewrite, test seperti ini jadi semacam kontrak perilaku: “implementasi baru harus menghasilkan output yang sama untuk kasus yang diuji.”
Masalahnya, production trust lebih luas dari test suite. Apalagi untuk database. Ada concurrency, locking, replication, backup-restore, extension ecosystem, observability, crash recovery, upgrade path, workload aneh dari user, dan performa di data nyata. Banyak bug production muncul bukan karena query sederhana gagal, tapi karena interaksi beberapa bagian sistem dalam kondisi capek, padat, dan sulit diulang.
Jadi kalimat yang fair adalah: pgrust punya bukti awal yang serius, tapi bukti production masih butuh perjalanan panjang. Ini bukan meremehkan proyeknya. Justru ini cara menghormati kompleksitas database.
Rewrite besar bukan adu bahasa pemrograman
Diskusi rewrite sering cepat berubah jadi perang bahasa: Rust vs C, Rust vs Zig, bahasa lama vs bahasa baru. Padahal keputusan rewrite biasanya lebih kompleks dari itu.
Rust bisa memberi memory safety dan tooling modern. Itu penting, terutama di sistem level rendah. Tapi bug production nggak cuma lahir dari memory safety. Bug bisa muncul dari desain transaksi, race condition logis, asumsi migrasi, konfigurasi, query planner, schema user, atau integrasi eksternal.
Di sisi lain, bahasa implementation memang tetap berpengaruh. Bahasa yang lebih familiar ke contributor baru bisa memperluas pool maintainer. Type system dan tooling bisa menurunkan kelas bug tertentu. Build system dan package ecosystem bisa memengaruhi onboarding. Tapi semua itu tradeoff, bukan mantra.
Contoh lain yang lagi ramai adalah Bun yang menulis ulang bagian besar project ke Rust. Angle terbaik dari berita seperti ini bukan “bahasa X kalah”. Angle yang lebih berguna: problem apa yang mau diselesaikan, cost migrasinya berapa, risiko regresinya apa, dan user akan dapat bukti apa?
AI bisa bikin rewrite lebih murah, tapi review tetap mahal
Satu hal menarik dari pgrust adalah README-nya menyebut Rust plus AI-assisted programming sebagai cara mengeksplorasi perubahan server yang lebih dalam. Ini nyambung dengan diskusi yang lebih luas: AI mungkin mengubah ekonomi rewrite karena porting kode, mencari pola, dan membuat scaffolding bisa lebih cepat.
Tapi jangan kebalik membaca sinyalnya. AI bisa menurunkan biaya mengetik dan translasi awal. Yang belum otomatis murah adalah correctness, review, ownership, debugging, dan maintenance jangka panjang.
Kalau AI bantu porting 100 ribu baris kode, pertanyaan berikutnya bukan “berapa cepat selesai?” Pertanyaan yang lebih penting:
- Siapa yang memahami perilaku sistem lama?
- Test apa yang membuktikan perilaku baru kompatibel?
- Bagian mana yang intentionally berbeda?
- Bagaimana rollback kalau production pecah?
- Siapa owner jangka panjang setelah excitement rewrite habis?
AI bikin rewrite terlihat lebih mungkin. Tapi semakin gampang bikin kode baru, semakin penting disiplin engineering buat membuktikan kode itu benar.
Checklist sebelum tim lu memutuskan rewrite
Kalau lu lagi di tim yang tergoda rewrite total, pgrust bisa dijadikan bahan refleksi. Bukan berarti semua project harus punya standar database-level. Tapi minimal, rewrite harus punya bukti yang lebih kuat dari “kode lama jelek”.
1. Tulis problem yang spesifik
“Codebase lama berantakan” terlalu kabur. Problem yang lebih berguna misalnya: release sering regresi, onboarding contributor butuh terlalu lama, performa sulit diprediksi, arsitektur lama menghalangi fitur tertentu, atau kelas bug tertentu terlalu sering muncul.
2. Tentukan oracle perilaku
pgrust memakai regression query Postgres sebagai oracle. Di project lu, oracle bisa berupa test suite, contract test, snapshot perilaku API, golden file, benchmark, atau replay traffic production. Tanpa oracle, rewrite cuma mengandalkan perasaan.
3. Pisahkan compatibility dari improvement
Rewrite sering gagal karena tim mencoba dua hal sekaligus: bikin ulang perilaku lama dan menambah desain baru. Kalau semuanya berubah bareng, debugging jadi kabur. Mana bug porting, mana intentional change?
4. Ukur performa dengan workload nyata
Bahasa baru atau arsitektur baru belum tentu otomatis lebih cepat. Pakai workload yang mirip user lu: ukuran data, concurrency, query pattern, cold start, memory pressure, dan failure mode.
5. Jujur soal non-goal
pgrust jujur bilang belum production-ready dan belum performance optimized. Tim internal juga perlu begitu. Rewrite yang sehat punya daftar “belum”: belum support fitur A, belum aman untuk traffic B, belum punya rollback C.
6. Siapkan owner setelah launch
Rewrite bukan selesai saat branch baru merge. Justru setelah itu mulai periode panjang: bug compatibility, dokumentasi, observability, migration support, dan keputusan arsitektur berikutnya. Kalau nggak ada owner yang jelas, rewrite bisa berubah jadi utang operasional baru.
Cara membaca proyek rewrite open-source tanpa ikut hype
Buat developer yang lihat proyek seperti pgrust, Bun rewrite, atau reimplementation lain, gua biasanya pakai lima pertanyaan cepat:
- Apa klaim utamanya? Compatibility, performance, maintainability, security, atau contributor onboarding?
- Bukti teknisnya apa? Test suite, benchmark, real user, production deployment, atau baru demo?
- Apa yang belum didukung? Extension, migration path, data lama, edge case, platform tertentu?
- Siapa yang akan maintain? Satu orang, komunitas, perusahaan, atau tim yang jelas?
- Apa risiko kalau lu pakai terlalu cepat? Data loss, downtime, lock-in, bug compatibility, atau sekadar waktu eksperimen kebuang?
Kalau jawaban pertanyaan itu jelas, proyeknya layak dipantau. Kalau jawabannya cuma “karena ditulis ulang pakai bahasa modern”, gua bakal lebih hati-hati.
Takeaway buat developer
pgrust adalah contoh menarik karena dia menunjukkan standar bukti yang lebih serius untuk rewrite besar: kompatibilitas diuji, status proyek dijelaskan, dan batasan tidak ditutup-tutupi. Buat gua, ini jauh lebih valuable daripada headline “Postgres rewritten in Rust” doang.
Pelajaran praktisnya: rewrite bukan tombol reset. Rewrite adalah proyek engineering yang harus membuktikan perilaku, performa, reliability, dan ownership. AI boleh bikin proses awal lebih cepat, bahasa modern boleh mengurangi kelas bug tertentu, tapi trust tetap dibangun dari test, observability, review, dan pengalaman production.
Kalau lu pengin pakai ini jadi bahan diskusi tim, mulai dari satu pertanyaan sederhana: “Bukti apa yang bikin kita percaya rewrite ini lebih aman daripada memperbaiki sistem lama bertahap?”
FAQ singkat
Apakah pgrust sudah bisa menggantikan Postgres di production?
Belum. README pgrust menyebut proyek ini belum production-ready dan belum performance optimized. Anggap ini eksperimen teknis yang serius, bukan rekomendasi migrasi production.
Apakah Rust otomatis bikin database lebih aman?
Rust membantu mengurangi kelas bug memory safety, tapi database tetap bisa punya bug logika, concurrency, planner, recovery, atau operasional. Memory safety penting, tapi bukan seluruh cerita.
Apakah AI bikin rewrite besar jadi aman?
AI bisa mempercepat porting dan scaffolding, tapi review correctness, test compatibility, debugging, dan maintenance tetap butuh manusia yang paham sistem.
Kapan rewrite layak dipertimbangkan?
Rewrite mulai masuk akal kalau problem lama spesifik, improvement bertahap sudah mentok, ada oracle perilaku yang kuat, ada owner jangka panjang, dan risiko migrasi bisa dikontrol.
