MariaDB Foundation memublikasikan panduan exploring TidesDB performance with TAF yang menetapkan konfigurasi awal yang dapat direproduksi, bukan angka throughput atau latency pemenang. Per 18 Oktober 2026, integrasi baseline pada commit e55a32691c1234e6fea20ac86ba6b59575fdd520 menjadi pegangan tim yang ingin menjalankan benchmark TidesDB MariaDB TAF tanpa mengubah setup resmi menjadi verdict performa.
TidesDB adalah library storage engine key-value transaksional (LSM-tree); TideSQL adalah plugin engine MariaDB-compatible di atasnya. Lisensi berbeda (MPL-2.0, GPL-2.0, GPLv2+); jangan mencampur status legal proyek. Panduan memakai MariaDB 11.4.13 RPM dan paket plugin tidesdb untuk RHEL/AlmaLinux 9 amd64.
Workload dan parameter yang di-commit
Profil small host (Intel Core i5-13500, 62 GB RAM, AlmaLinux 9.7): delapan tabel x 1 juta baris; POINT_SELECT dan OLTP_RO untuk reads; OLTP_RW dan OLTP_WO_MODIFIABLE untuk writes; 16/32/64 threads; 100 detik run dan warmup pada 64 threads; tiga iterasi; cache 32G dan memtable 1G. Profil large host (AMD EPYC 9454, ~125 GB RAM, AlmaLinux 9.8): delapan tabel x 10 juta baris; reads sama; writes hanya OLTP_RW (file committed large writes tidak menjalankan OLTP_WO_MODIFIABLE meski narasi blog menyebut keduanya secara umum).
Boundary konfigurasi penting: transaction_isolation READ-COMMITTED; sync_binlog=0; tidesdb_memtable_sync_mode NONE; compression NONE; bloom filter ON; flush dan compaction threads masing-masing 4. Shell script menetapkan governor performance dan frekuensi CPU bila cpupower tersedia; verifikasi state CPU setelah setup karena output dapat gagal diam-diam. Path PROP_DIR, INSTALL_DIR, plugin, dan data directory di commit adalah path penulis dan wajib diganti.
Model storage device, filesystem, NUMA, dan versi sysbench hasil build belum dapat diverifikasi dari halaman yang diperiksa; jangan mengisi asumsi NVMe hanya karena desain TidesDB mengincar many-core.
Durability dan cara membaca hasil
sync_binlog=0 dan memtable sync NONE memengaruhi envelope durability; membandingkan throughput dengan engine full fsync lalu menyatakan pemenang tanpa scenario terpisah menyesatkan. Tiga iterasi x 100 detik cukup untuk baseline awal, belum membuktikan steady-state compaction, long-tail latency, atau crash recovery. Artikel sumber tidak memublikasikan TPS, p95/p99, CPU, IO, atau footprint disk; angka hasil harus berasal dari run nyata Anda dan disimpan sebagai artifact.
Klaim repository TidesDB tentang ACID/MVCC atau low amplification membutuhkan correctness test terpisah; sysbench throughput saja tidak membuktikannya. Deskripsi MariaDB Foundation soal baseline stable atau production-grade adalah konteks penulis/sponsor, bukan validasi independen. Tidak ada universal winner TidesDB versus InnoDB atau RocksDB pada sumber ini.
Untuk perbandingan metodologi benchmark database pada stack web, lihat ringkasan benchmark MySQL, PostgreSQL, SQLite, Redis, dan Supabase dengan aturan parity durability yang sama. Admin MariaDB yang sudah memakai fitur vector dapat menempatkan engine baru di samping integrasi MariaDB Vector di Laravel 13 sebagai workload terpisah, bukan satu angka agregat.
Langkah reproduksi dan reporting
Alur disarankan: pin commit TAF; unduh RPM cocok; verifikasi checksum atau signature bila ada; install via TAF; ganti absolute paths; build sysbench client terhadap install aktif (–action=build-client); validasi RAM, storage, background service; jalankan prepare, warmup, run; arsipkan properties, config server, log, raw results, errors; ulangi sesuai properties; laporkan median dan dispersion.
Setiap laporan hasil kelak wajib membawa CPU/RAM/storage/OS/kernel, versi MariaDB/TideSQL/TAF/sysbench, config lengkap, workload rows/tables, isolation dan sync mode, throughput dan latency distribution (bukan rata-rata saja), errors, CPU/IO, disk growth, serta perintah reproduce. Jalankan hanya di host test non-production; backup rutin tetap relevan seperti pada prosedur impor/ekspor backup database.
CTA operasional: clone commit baseline, jalankan di lab, lalu rancang perbandingan fair dengan satu variabel berubah atau scenario durability eksplisit. Jangan publikasikan fastest, production-ready, atau X% lebih cepat tanpa raw method dan limitation.
