Jepsen Temukan 96 Masalah di ParticleDB 1.1.4, Klaim ACID Dinilai Prematur

Jepsen menguji ParticleDB versi 1.1.4 sampai 1.1.18.11.rc-22 dan menemukan 96 masalah, dari crash dan deadlock sampai data loss. Hampir semuanya muncul pada satu server, satu klien, tanpa gangguan jaringan sama sekali. Yang paling serius: ParticleDB tetap kehilangan write yang sudah di-commit pada mode transaksi default occ, dan masih mengizinkan anomali internal serta Lost Update bahkan saat diset ke serializable, level isolasi paling kuat. Laporan diterbitkan 31 Oktober 2026 oleh Kyle Kingsbury, dan risetnya didanai oleh Orkes, perusahaan yang membuat ParticleDB itu sendiri.

TL;DR

• Laporan Jepsen menemukan 96 masalah pada ParticleDB, diuji dari 1.1.4 sampai 1.1.18.11.rc-22.
• Pada 1.1.18.11.rc-22, semua kecuali sepuluh masalah sudah diperbaiki, tapi kehilangan committed write masih terjadi di mode default.
• Klaim "Full ACID" dinilai prematur, karena Lost Update tetap muncul pada setelan serializable.
• Sebagian besar masalah tidak butuh gangguan jaringan, cukup satu server dan satu klien.
• Orkes sudah merilis 1.1.19-rc.13 dan mengklaim seluruh temuan selesai, tapi klaim itu belum diverifikasi ulang secara independen.

Apa sebenarnya yang diuji Jepsen?

Jepsen adalah praktik pengujian konsistensi sistem terdistribusi yang sudah jadi rujukan sejak satu dekade terakhir. Yang diuji kali ini ParticleDB, basis data multi-model yang ditujukan untuk beban kerja AI: ia menawarkan SQL transaksional, key-value store, vector search, live analytics, dan user-defined function yang mereka sebut Particles. Klien bisa masuk lewat protokol Postgres dan Redis, juga gRPC serta HTTP2 miliknya sendiri. ParticleDB ditulis dari nol dengan Rust, dan mengklaim jauh lebih cepat daripada Postgres dengan karakteristik keamanan yang sama.

ParticleDB dibuat oleh Orkes untuk menopang platform orkestrasi workflow mereka, Conductor. Konteks ini penting karena basis data yang lahir dari kebutuhan internal cenderung dioptimalkan untuk pola akses tertentu, dan toleransi terhadap anomali di pola lain bisa jadi tidak pernah diuji. Itulah yang coba ditutup oleh pengujian Jepsen.

Seberapa parah temuannya?

Cukup parah, dan yang membuatnya menonjol adalah sifat masalahnya. Kingsbury mengelompokkan 96 temuan itu dari yang biasa sampai yang aneh: crash, deadlock, dan data loss masuk kategori biasa. Kategori anehnya lebih mengganggu: baris yang sebagian tidak terlihat dan tidak bisa dihapus, kondisi WHERE 4 = 5 yang tetap mengembalikan hasil, tabel yang sudah di-drop muncul kembali dalam bentuk terdistorsi, kolom tertukar, dan string yang berubah menjadi integer.

Yang paling menentukan justru bukan daftar bug-nya, tapi kondisi reproduksinya. Sebagian besar masalah muncul hanya dengan satu server, satu klien, dan tanpa injeksi gangguan apa pun. Dalam pengujian sistem terdistribusi, beban pembuktian biasanya ada pada skenario partisi jaringan dan kegagalan node. Kalau bug sudah muncul di kondisi paling sederhana, artinya akar masalahnya bukan di koordinasi antar-node, melainkan di lapisan penyimpanan atau eksekusi query itu sendiri.

Temuan	Konteks muncul	Status di 1.1.18.11.rc-22
Crash dan deadlock	Satu server, satu klien	Sebagian besar sudah diperbaiki
Kehilangan committed write	Mode transaksi default occ	Masih terjadi
Lost Update dan anomali internal	Mode serializable	Masih terjadi
Baris tidak terlihat dan tidak bisa dihapus	Operasi normal	Sebagian sudah diperbaiki
Tabel drop muncul kembali	Operasi DDL	Sebagian sudah diperbaiki
Kolom tertukar dan tipe berubah	Query biasa	Sebagian sudah diperbaiki

Kenapa kehilangan committed write lebih serius dari crash?

Karena crash terlihat, sedangkan kehilangan write tidak. Server yang crash memaksa operator bertindak: log dibaca, layanan di-restart, insiden dicatat. Write yang hilang tanpa error tidak memberi sinyal apa pun. Aplikasi menerima respons sukses, pengguna melihat konfirmasi, dan datanya tidak ada. Pada level aplikasi bisnis, pola ini yang paling mahal, karena kerusakannya baru ketahuan berhari-hari kemudian ketika laporan tidak cocok dengan kenyataan, dan pada titik itu penyebabnya sudah sangat sulit dilacak.

Jepsen mencatat bahwa kehilangan committed write di ParticleDB terjadi pada operasi normal dengan mode transaksi default occ. Artinya pengguna yang tidak mengubah konfigurasi apa pun, dan hanya memakai setelan bawaan, adalah yang paling terekspos. Ini kebalikan dari asumsi umum bahwa mode default biasanya paling konservatif. Pada kebanyakan basis data, setelan bawaan mengorbankan throughput demi keamanan data, dan operator yang sadar risiko baru menaikkan isolasi sesuai kebutuhan.

Apa arti temuan pada mode serializable?

Artinya menjalankan transaksi pada level isolasi paling kuat tidak menutup celah. Laporan menyebut bahwa bahkan pada serializable, ParticleDB masih mengizinkan anomali internal dan Lost Update. Ini penting karena serializable adalah janji paling kuat yang bisa diberikan sebuah basis data transaksional: hasil eksekusi transaksi harus setara dengan eksekusi berurutan satu per satu. Kalau janji itu gagal, tidak ada level di atasnya yang bisa dipakai sebagai jalan keluar.

Untuk tim yang memilih basis data berdasarkan label ACID, implikasinya praktis: label itu tidak bisa dipakai sebagai pengganti uji. Klaim ACID pada halaman pemasaran tidak menyebut level isolasi mana yang benar-benar dijamin, apakah jaminannya berlaku pada semua jalur replikasi, dan apakah ada kondisi yang membuat jaminan itu turun diam-diam. Yang bisa dipakai sebagai bukti hanya pengujian pada beban kerja yang menyerupai produksi, dengan skenario konkurensi dan kegagalan yang sengaja dibuat.

Apakah Orkes sudah memperbaiki semuanya?

Mereka mengklaim begitu. Setelah laporan keluar, Orkes merilis versi 1.1.19-rc.13 dan menyatakan bahwa rilis tersebut menyelesaikan seluruh masalah yang dibahas dalam laporan. Yang perlu dicatat: klaim itu datang dari pihak yang juga mendanai risetnya, dan statusnya masih rilis kandidat dengan akhiran rc. Artinya belum ada verifikasi independen bahwa perbaikannya benar-benar menutup penyebab, bukan hanya menutup satu jalur reproduksi yang dipakai pengujian.

Pola yang lebih aman untuk menilai: minta pengujian ulang pada beban kerja sendiri, atau tunggu analisis Jepsen berikutnya. Perbaikan yang hanya diuji dengan skrip yang sama dengan yang menemukan bug punya celah nyata, karena skrip itu dirancang untuk satu jalur tertentu. Masalah yang bersifat race dan anomali isolasi sering berpindah ke jalur lain setelah satu jalur ditutup.

Kalau tetap mau dipakai, apa yang perlu disiapkan?

Yang pertama, jangan simpan data yang tidak bisa direkonstruksi sebagai satu-satunya salinan. Basis data yang masih dalam tahap kandidat rilis untuk perbaikan konsistensi bukan tempat menyimpan catatan keuangan atau ledger transaksi tanpa cadangan independen. Yang kedua, jangan mengandalkan mode transaksi default tanpa membaca dokumentasinya. Kalau mode default adalah occ dan pengujian independen menemukan kehilangan write di sana, asumsi itu harus diverifikasi sendiri sebelum dipakai di produksi.

Yang ketiga, siapkan pengujian konsistensi internal, bukan hanya pengujian fungsional. Pengujian fungsional memeriksa apakah query mengembalikan nilai yang diharapkan pada satu jalur. Pengujian konsistensi memeriksa apakah riwayat transaksi yang terjadi secara bersamaan menghasilkan keadaan yang bisa dijelaskan. Untuk skala kecil, itu bisa berarti rekonsiliasi berkala antara tabel utama dan tabel ringkasan, dengan alarm ketika angkanya tidak cocok.

SELECT count(*) FROM pesanan;
SELECT count(*) FROM ringkasan_harian;
-- selisih tidak nol berarti ada write yang hilang atau dobel

Pemeriksaan sesederhana itu tidak membuktikan sistemnya benar, tapi ia menangkap kelas kegagalan yang paling mahal, yaitu data yang hilang tanpa jejak error. Basis data yang sudah lolos pengujian konsistensi independen tetap layak dipercaya. Yang tidak layak adalah mempercayainya hanya karena labelnya.

Bagaimana menguji konsistensi tanpa alat khusus?

Mulai dari rekonsiliasi, karena cara termurah menangkap kehilangan data adalah membandingkan dua representasi yang seharusnya selalu cocok. Simpan tabel ringkasan yang dihitung dari tabel utama, lalu bandingkan keduanya secara berkala. Selisih nol berarti tidak ada bukti kerusakan, bukan bukti bahwa sistemnya benar. Selisih bukan nol adalah sinyal yang harus diselidiki, dan justru itulah nilai praktisnya.

Kedua, uji operasi yang paling sering dipakai, bukan yang paling rumit. Laporan menyebut banyak temuan muncul pada satu server, satu klien, tanpa gangguan, dengan operasi biasa. Artinya pengujian sederhana pun bisa menemukan masalah, asalkan dijalankan dengan data dan konkurensi yang menyerupai produksi. Menguji fitur eksotis sambil melewatkan alur utama adalah urutan yang salah.

Ketiga, catat versi secara eksplisit di setiap laporan insiden. Rentang versi yang diuji Jepsen cukup lebar, dari 1.1.4 sampai 1.1.18.11.rc-22, dan status perbaikannya berbeda antarversi. Tanpa nomor versi yang presisi, diskusi tentang "sudah diperbaiki atau belum" hanya akan berputar. Versi adalah bagian dari bukti, bukan detail administratif.

Sumber dan bacaan lanjut

• Analisis lengkap Jepsen untuk ParticleDB 1.1.4 di jepsen.io, diterbitkan 31 Oktober 2026.
• Penjelasan model konsistensi yang dipakai dalam pengujian di jepsen.io/consistency.
• Definisi resmi level isolasi transaksi SQL di dokumentasi PostgreSQL.
• Dokumentasi produk dan catatan rilis dari pembuatnya, Orkes.

FAQ

Apa itu Lost Update yang disebut di laporan?

Lost Update terjadi ketika dua transaksi membaca nilai yang sama, lalu keduanya menulis berdasarkan nilai lama itu, sehingga hasil transaksi pertama tertimpa tanpa terdeteksi. Pada sistem yang benar-benar serializable, pola ini seharusnya dicegah dengan abort atau penguncian. Kalau ia tetap muncul pada setelan paling kuat, jaminan isolasinya tidak berjalan sebagaimana dijanjikan.

Apakah laporan ini berarti ParticleDB tidak boleh dipakai sama sekali?

Tidak. Laporan Jepsen menilai satu seri versi pada satu titik waktu, dan sebagian besar masalah sudah diperbaiki pada rilis berikutnya. Yang berubah adalah tingkat kepercayaan yang pantas diberikan pada klaim pemasaran. Untuk beban kerja eksperimental atau data yang bisa dibangun ulang, risiko itu masih bisa dikelola. Untuk data yang tidak bisa hilang, tunggu verifikasi independen.

Kenapa fakta bahwa risetnya didanai Orkes itu penting?

Bukan karena hasilnya otomatis bias, karena Jepsen menerbitkan metodologi dan temuannya secara terbuka. Yang penting adalah memisahkan dua hal: temuan pengujian dan klaim perbaikan. Temuan diuji dengan metode yang bisa diperiksa ulang, sedangkan klaim bahwa 1.1.19-rc.13 sudah menutup semuanya datang dari pihak yang punya kepentingan pada kesimpulan itu.

Berapa lama waktu yang biasanya dibutuhkan sampai hasilnya diverifikasi ulang?

Belum ada data publik yang bisa dipakai sebagai patokan untuk kasus ini. Yang bisa dikatakan: analisis Jepsen biasanya mencakup satu rentang versi tertentu, dan verifikasi ulang butuh pengujian baru pada versi yang lebih baru. Sampai itu terbit, status perbaikan sebaiknya diperlakukan sebagai klaim vendor, bukan sebagai fakta terverifikasi.

Apa yang paling penting dipahami developer dari laporan ini?

Bahwa label ACID bukan jaminan yang bisa dipakai tanpa uji. Laporan ini menunjukkan anomali isolasi dan kehilangan data pada basis data yang mengklaim "Full ACID", muncul di kondisi satu server tanpa gangguan jaringan. Pelajarannya bukan menolak produk baru, tapi menempatkan pengujian konsistensi independen sebagai syarat sebelum data penting dipindahkan ke sana.