Turbopuffer v3 dan Matinya Kategori Vector Database

turbopuffer mempublikasikan rencana v3 pada akhir September 2026 dengan judul yang provokatif: RIP, vector database. Isinya bukan pengumuman penutupan produk, melainkan keputusan arsitektural yang jauh lebih menarik dari itu. Mereka memindahkan posisi indeks vektor dari kursi utama menjadi sekadar indeks sekunder. Untuk developer yang membangun pencarian semantik atau RAG, perubahan ini layak dibaca bukan sebagai berita vendor, tapi sebagai bukti bahwa kategori vector database sedang melebur ke dalam mesin pencari generik.

Awal Mula: Dokumen Berarti ID dan Vektor

Di versi pertama, turbopuffer lahir sebagai serverless vector database yang sangat spesifik untuk satu tugas: menyajikan pencarian vektor yang murah dan cukup cepat. Rumus ekonominya sederhana, object storage dipakai sebagai sumber kebenaran, dan performa dijaga dengan cache berlapis pada NVMe dan memori. Pilihan itu menurunkan biaya secara drastis dibanding menjalankan kluster indeks vektor sendiri.

Bentuk datanya juga minimal. Sebuah dokumen hanya terdiri dari ID dan vektor. Pada masa itu wisdom yang berlaku adalah indeks berbasis graf, tapi tim turbopuffer menemukan bahwa indeks berbasis hierarchical clustering lebih cocok dengan karakter object storage. Mereka memulai dengan SPANN, lalu bermigrasi ke SPFresh supaya indeks bisa di-update secara inkremental, bukan dibangun ulang.

Detail kecil ini ternyata menentukan seluruh cerita berikutnya. Karena kunci penyimpanan adalah alamat ANN, semua hal lain yang menempel pada dokumen ikut terikat ke alamat tersebut.

v2: Filter Atribut dan Teks Penuh Menumpuk di Atas Fondasi yang Salah

Seiring waktu turbopuffer berkembang punya text search dan regex yang kuat, dan mulai dipakai untuk kasus non-search, misalnya sync engine di Linear. Query engine ikut berevolusi untuk menopang semua bentuk rencana query, tapi arsitektur penyimpanan nyaris tidak berubah. Indeks ANN tetap menjadi indeks utama yang menjadi pusat gravitasi.

Untuk membuat filter atribut cepat dan ber-recall tinggi, nilai atribut dimodelkan sebagai inverted index yang memetakan satu nilai ke alamat ANN dokumen yang memuatnya. Proyeksi atribut juga disimpan berdampingan dengan ID dan vektor. Full-text search dengan BM25 bekerja dengan pola mirip: term dipetakan ke alamat dokumen, lalu isi dokumen dibaca dari alamat yang sama.

Tiga Beban yang Membatasi

Tim turbopuffer menyatakan sudah mendorong arsitektur vector-primary sampai batasnya. Di atas arsitektur itu mereka sanggup membawa pencarian vektor ke indeks tunggal berisi lebih dari 100 miliar vektor, melayani baca 200 ms pada p99, dengan ribuan query per detik. Angka itu bukan kecil. Justru karena hasilnya bagus, keputusan untuk mengubah fondasi butuh alasan yang kuat, dan alasan itu datang dalam tiga bentuk.

1. Amplifikasi storage

Seluruh isi dokumen disimpan di bawah alamat ANN-nya. Kalau ada satu vektor per dokumen, tidak ada duplikasi. Masalahnya muncul pada representasi multi-vektor, seperti document nesting atau late interaction, di mana satu dokumen punya beberapa vektor. Karena setiap alamat membawa salinan isi dokumen, kontennya berduplikasi mengikuti jumlah vektor. Tim itu menyebut hal ini sebagai penyebab beberapa batas produk yang tidak nyaman.

2. Amplifikasi tulis

Setiap insert, update, atau delete bisa memicu SPFresh melakukan rebalance supaya vektor tetap tercluster dengan baik, karena kalau tidak, recall turun. Dan karena konten dokumen disimpan mengikuti alamat ANN, rebalance menyeret pindah dokumen penuh, bukan hanya angka vektornya. Efeknya mereka ungkap terbuka: upaya tuning throughput indeks sudah masuk fase diminishing return.

3. Vectorization yang terkunci

Mesin query modern bekerja secara vektorisasi, yaitu loop ketat atas blok nilai, yang mengamortisasi biaya tetap per blok, mengompresi lebih baik, menjaga pipeline CPU terisi, dan membuka jalan ke SIMD. Angka blok dari beberapa sistem menunjukkan arah trennya: DuckDB bekerja dalam batch 2.048 baris, ClickHouse sampai sekitar 65 ribu, dan blok posting Lucene berukuran 256 dokumen.

Bukti paling meyakinkan justru datang dari rumah sendiri. Versi pertama full-text search turbopuffer membagi posting list mengikuti batas cluster ANN, sehingga median satu blok hanya berisi sekitar 1,5 posting. Blok yang hampir kosong membuat vektorisasi tidak punya apa-apa untuk diproses. Saat FTS versi dua ditata ulang menjadi blok tetap berisi sekitar 256 posting, indeks menjadi 10 kali lebih kecil dan query lebih cepat. Satu perubahan tata letak, beda besar hasil.

Keputusan v3: Berhenti Meng-key pada Alamat ANN

Solusinya terdengar hampir terlalu simpel: jangan pakai alamat ANN sebagai kunci. Itulah perubahan inti turbopuffer v3, dengan konsekuensi indeks ANN turun jabatan menjadi indeks sekunder, dan ada indeks utama baru yang menjadi dasar penataan dokumen. Mereka mengaku ini bukan perubahan trivial.

Melebur indeks primer bukan soal pindah tabel, tapi menulis ulang cara dokumen dan indeks ditata, ditulis, di-compaction, dan di-query. Proses compaction inilah yang biasanya paling sakit di sistem berbasis log, karena data yang ditulis secara append-only harus dirapikan ulang tanpa mengganggu baca yang sedang jalan. Progres yang dilaporkan pada pos tersebut: pada awal bulan itu seluruh CI sudah lulus di v3. Urutan kerjanya eksplisit, mulai fokus pada kebenaran, lalu membuat yang benar itu cepat. Timnya bahkan menulis bahwa melihat angka benchmark turun di fase ini menyakitkan, tanda bahwa pekerjaan beratnya belum selesai.

Kenapa Ini Penting untuk Stack AI di Indonesia

Kebanyakan tim yang memakai vector database sedang menjalankan satu dari dua pola: retrieval untuk RAG, atau pencarian campuran antara teks dan semantik. Pola kedua inilah yang selama ini dipaksakan ke infrastruktur yang didesain untuk pola pertama. Ketika ANN menjadi indeks sekunder di atas mesin yang lebih umum, beberapa keluhan harian ikut hilang, terutama batas ukuran payload per dokumen, biaya update pada dataset yang sering berubah, dan performa filter atribut yang ketat.

Kebutuhan nyata di produksi	Yang terjadi dengan ANN sebagai indeks utama	Yang dijanjikan arsitektur v3
Dataset sering di-update	Rebalance menyeret dokumen penuh, throughput indeks cepat mentok	Tata letak ditulis ulang, amplifikasi tulis turun
Filter atribut ketat lalu ranking	Filter ditopang indeks tambahan yang tetap bergantung alamat ANN	Indeks vektor jadi salah satu indeks sekunder, bukan fondasi
Campur BM25 dan semantik	Posting list terpotong batas cluster, median blok berisi 1,5 posting	Blok tetap sekitar 256 posting, indeks lebih kecil dan query lebih cepat
Dokumen multi-vektor	Konten terduplikasi per vektor, memunculkan batas produk	Dokumen tidak lagi dikunci alamat vektor

Skala yang mereka klaim hari ini memberi konteks seberapa jauh arsitektur lama sudah diperas: turbopuffer menyebut memegang lebih dari satu triliun dokumen, memproses lebih dari 10 juta tulis per detik, dan melayani lebih dari 25 ribu query per detik. Perubahan fondasi di skala itu adalah pekerjaan berisiko, dan keputusan untuk tetap melakukannya adalah sinyal bahwa vector-primary memang plafon, bukan preferensi.

Yang Tidak Otomatis Berubah Meski Arsitekturnya Berubah

Ada tiga hal yang tetap jadi tanggung jawab pemakai, apa pun layout di bawahnya. Pertama, kualitas retrieval ditentukan chunking dan pemilihan embedding, bukan oleh indeks. Memindahkan beban ke mesin yang lebih cepat tidak memperbaiki recall kalau potongannya salah. Kedua, biaya tetap mengikuti pola akses. Arsitektur object storage menguntungkan karena baca jarang dan simpan murah, sehingga dataset yang ditanya berulang-ulang dengan fan-out besar bisa jadi lebih mahal daripada yang terlihat di halaman harga. Ketiga, filter metadata wajib dieksekusi lebih dulu di sisi aplikasi kalau datanya sensitif, misalnya dokumen milik tenant tertentu, karena indexed filter yang cepat tetap tidak boleh dianggap pengganti otorisasi.

Pengalaman umum di proyek RAG lokal juga mengingatkan hal yang lebih membosankan: sebagian besar kegagalan bukan soal engine, tapi soal pipeline data yang membiarkan informasi masa depan bocor ke konteks masa lalu, atau indeks yang tidak pernah di-refresh setelah dokumen sumber berubah. Ganti engine boleh saja, selama akar masalahnya sudah diverifikasi lebih dulu.

Pelajaran Arsitektur: Kunci Primer Adalah Kontrak Jangka Panjang

Pola yang berulang di banyak sistem: pilihan kunci penyimpanan utama diam-diam menentukan siapa yang boleh cepat di masa depan. Kalau kunci utama adalah alamat indeks tertentu, maka semua fitur lain, termasuk teks, filter, dan metadata, harus rela menumpang pada layout itu. Ketika fitur-fitur itu kemudian jadi beban utama, sistem mulai berperang dengan fondasinya sendiri, dan setiap optimasi menjadi kosmetik.

Untuk tim yang hari ini memilih lapisan penyimpanan, pertanyaan yang lebih berguna bukan apakah mesinnya mendukung vektor, melainkan apa yang menjadi kunci primer. Pertanyaan kedua: apa yang terjadi ketika kasus use terbesar bergeser dari semantik ke campuran, karena pergeseran itu hampir selalu terjadi setelah produk punya pengguna sungguhan. Pertanyaan ketiga: apakah batas-batas produk saat ini lahir dari desain sadar, atau dari konsesi yang tidak pernah ditinjau ulang.

Nuansa yang jujur perlu ditulis: pos turbopuffer adalah materi pemasaran teknis dari vendor yang punya kepentingan. Klaim benchmark internal mereka soal FTS dan skala produksi belum diverifikasi pihak ketiga, dan v3 belum dinyatakan tersedia umum. Yang bisa diambil sebagai fakta adalah keputusan arsitekturnya dan alasan yang mereka uraikan, bukan angka jualannya. Untuk pembanding yang lebih netral soal arah pencarian teks di ekosistem database relasional, tulisan mengenai TIN, ekstensi full-text search Postgres dari PlanetScale mendokumentasikan tren serupa dari sisi yang berbeda, dan panduan retrieval augmented generation untuk pemula menjelaskan bagian stack tempat perubahan ini paling terasa.

Yang Perlu Diikuti Sampai v3 Keluar

Ada beberapa penanda yang bisa dipakai untuk menilai apakah klaim ini benar-benar mengubah pengalaman pakai, bukan hanya memperbaiki diagram arsitektur. Yang paling mudah diukur adalah batas payload per dokumen dan batas jumlah vektor per dokumen: kalau dua batas itu naik atau hilang, artinya amplifikasi storage benar-benar sudah diselesaikan. Penanda kedua adalah biaya dan throughput pada workload tulis, karena amplifikasi tulis hanya terasa saat dataset di-update sering. Penanda ketiga adalah konsistensi hasil pencarian campuran, yaitu apakah ranking BM25 dan ranking vektor tetap sama setelah tata letak berubah, karena pindah fondasi tanpa regresi kualitas adalah pekerjaan yang sulit.

Satu hal lagi yang layak dicatat sebagai pelajaran metodologi. Tim turbopuffer mempublikasikan prosesnya sebelum produk selesai, memakai CI yang lulus sebagai bukti sementara, dan terbuka untuk diikuti. Bagi calon pemakai, transparansi seperti ini lebih berguna daripada satu halaman benchmark final, karena ia memperlihatkan arah keputusan dan bukan hanya hasilnya.

Versi Ringkas

turbopuffer v3 memindahkan indeks vektor dari posisi fondasi ke posisi alat, karena tata letak yang luar biasa bagus untuk satu jenis query ternyata menghambat tiga hal sekaligus: storage, tulis, dan vektorisasi. Judul RIP, vector database memang cocok dipakai untuk menandai matinya sebuah kategori, tapi yang sebenarnya mati bukan produknya, melainkan ide bahwa pencarian semantik berhak menentukan cara seluruh data ditata.