Hampir setiap aplikasi yang menambahkan fitur AI hari ini berakhir dengan kebutuhan yang sama: menyimpan embedding, lalu mencari vektor yang paling mirip. Selama beberapa tahun jawabannya terbelah dua: pasang database vektor terpisah, atau tetap di PostgreSQL dengan pgvector dan indeks HNSW. Pilihan pertama menambah biaya dan pekerjaan sinkronisasi; pilihan kedua boros RAM begitu tabelnya membesar. Pada 13 Oktober 2026, Tiger Data (dulu Timescale) merilis jalan ketiga: pg_vectorsearch, ekstensi PostgreSQL open source berlisensi PostgreSQL, dengan metode indeks baru bernama PRISM. Statusnya masih alpha, dan itu yang menentukan apakah ia layak masuk server produksi Anda.

Kenapa HNSW mulai terasa mahal

HNSW, indeks vektor paling umum di pgvector, bekerja seperti peta jalan: setiap vektor menjadi simpul yang terhubung ke tetangga terdekatnya, dan pencarian berjalan melompat dari simpul ke simpul. Masalahnya RAM. Lompatan antar simpul sulit diprediksi, sehingga prosesor sering menunggu data, dan grafnya harus tetap tinggal di memori agar cepat. Di benchmark Tiger Data pada 100 juta vektor, mesin terkecil yang berhasil menyelesaikan pembangunan indeks HNSW berkapasitas 512 GB RAM. Itulah yang mendorong banyak tim pindah ke database vektor terpisah.

Apa yang berbeda dari PRISM

PRISM (Partitioned Routing Index for Similarity Matching) membuang graf dan kembali ke pendekatan partisi, mirip IVFFlat tetapi dengan kuantisasi modern. Vektor dikelompokkan berdasarkan kemiripan, lalu disimpan sebagai daftar terkompresi (kode RaBitQ, kira-kira satu bit per dimensi) yang dipadatkan ke halaman database. Saat query datang, PostgreSQL menelusuri pohon centroid untuk menemukan partisi terdekat, memindai daftar tersebut secara berurutan, menyaring kandidat memakai batas galat RaBitQ, lalu rerank dengan vektor presisi penuh dari tabel. Hasilnya: indeks jauh lebih kecil, pembacaan berurutan yang ramah SIMD, dan kebutuhan RAM turun drastis. PRISM juga bukan layanan terpisah. Ia benar-benar index access method di dalam PostgreSQL, jadi backup, replikasi, dan tooling yang sudah ada tetap berlaku.

Angka benchmark versi Tiger Data

Semua angka berikut berasal dari benchmark internal Tiger Data memakai tool publik mereka (rekall), dengan recall@10 diukur terhadap hasil brute-force, dan semua pembanding HNSW memakai halfvec 16-bit. Belum ada validasi independen, jadi perlakukan sebagai klaim vendor:

• 100 juta vektor di AWS r8i.4xlarge (16 vCPU, 128 GiB): PRISM membangun indeks dalam 1 jam 40 menit, ukuran indeks 25 GB, latensi p50 6 ms pada recall 95% dan 21 ms pada recall 99%.
• Di mesin yang sama, HNSW tidak selesai membangun indeks sama sekali.
• Di mesin 4x lebih mahal (512 GiB): HNSW butuh 42 jam, indeks 180 GB, 8 ms pada recall 95%, dan tidak mencapai 99% pada latensi wajar. PRISM: 49 menit, 4 ms dan 19 ms.
• 1 juta vektor: PRISM membangun indeks sekitar 3 menit di mesin 4 GiB, sementara HNSW sekitar 21,7 jam karena grafnya tidak muat. Di mesin 2 GiB, PRISM melayani 99% recall dalam 15 ms; HNSW butuh 392 ms di mesin 4 GiB.

Cara mencoba di server sendiri

Kebutuhan minimum: PostgreSQL 18 atau lebih baru beserta header development, GCC 11+ atau Clang 14+, dan Meson.

git clone https://github.com/timescale/pg_vectorsearch
cd pg_vectorsearch
meson setup builddir --buildtype=release
meson install -C builddir

Untuk tabel baru, pgvector tidak dibutuhkan. Perhatikan urutannya: muat data dulu, karena PRISM menentukan ukuran indeks dari jumlah baris saat CREATE INDEX.

CREATE EXTENSION pg_vectorsearch;

CREATE TABLE documents (
  id        bigserial PRIMARY KEY,
  body      text,
  embedding vec32(768)
);

-- muat data lebih dulu, baru bangun indeks
CREATE INDEX ON documents USING prism (embedding vec32_l2_ops);

-- 0 = otomatis (target ~95% recall); naikkan bila butuh recall lebih tinggi
SET prism.nprobe = 40;

SELECT id, body
FROM documents
ORDER BY embedding <-> $1
LIMIT 10;

Kalau tabel pgvector Anda sudah jalan, indeks PRISM bisa dibangun langsung di kolom yang ada tanpa menulis ulang atau menyalin data, dan query lama tetap memakai operator pgvector (<->, <#>, <=>):

CREATE EXTENSION pg_vectorsearch;

CREATE INDEX documents_embedding_prism
  ON documents USING prism (embedding vec32_cosine_ops);

-- vec32_* untuk kolom vector, vec16_* untuk halfvec
-- pilihan metrik: _l2_ops, _ip_ops, _cosine_ops

Setelah itu cek rencana query dengan EXPLAIN (COSTS OFF). Kalau planner sudah memakai indeks PRISM, indeks HNSW lama boleh di-DROP untuk menghemat ruang dan waktu tulis.

Batasannya: jangan buru-buru ke produksi

• Wajib PostgreSQL 18+, penghalang nyata bagi server yang masih di versi 15 sampai 17.
• Dimensi vektor maksimal 1.968; tabel unlogged dan expression index belum didukung.
• Filter belum bisa digabung dengan pencarian (WHERE + ORDER BY) sampai GA. Ini penting untuk aplikasi multi-tenant yang menyaring per instansi atau sekolah lebih dulu.
• Data yang ramai membuat kualitas partisi menurun karena daftar posting tidak terpecah otomatis; jalankan prism_rebalance atau REINDEX. Jangan bangun indeks di tabel kosong lalu diisi belakangan.
• Baris terhapus hanya jadi tombstone; ruangnya kembali setelah REINDEX.
• Upgrade antar prerelease bisa tidak kompatibel, jadi siapkan drop dan buat ulang ekstensi beserta indeksnya. Replikasi fisik, backup/restore, dan throughput banyak klien belum diuji.
• pgvectorscale (indeks DiskANN) resmi masuk mode maintenance; arah pengembangan Tiger Data kini di PRISM.

Artinya untuk tim IT di daerah

Daya tarik terbesarnya bukan kecepatan, melainkan tidak perlu server baru. Fitur "cari dokumen mirip" sering berhenti di tahap rencana karena harus menambah database vektor plus biaya operasionalnya. Kalau PRISM stabil, pencarian semantik arsip surat, peraturan desa, atau katalog produk UMKM bisa ikut di PostgreSQL yang sudah ada: satu backup, satu monitoring, satu tim.

Langkah paling aman sekarang: pasang di salinan staging berisi data asli, bangun indeks, lalu ukur sendiri recall@10 terhadap hasil exact dengan 20 sampai 50 query yang mewakili pemakaian nyata. Bandingkan dengan HNSW yang sudah ada. Kalau 95% tercapai dengan RAM jauh lebih kecil, Anda punya alasan kuat menunggu GA, dan sudah tahu persis apa yang akan dilakukan saat itu tiba.

Sumber: Tiger Data: pengumuman pg_vectorsearch; GitHub: timescale/pg_vectorsearch; InfoQ: pg_vectorsearch untuk pencarian vektor di PostgreSQL.