Vector Database Adalah: Cara Kerja, Contoh & Pilihannya

Pencarian di dalam database biasa bekerja dengan mencocokkan huruf. Anda mengetik satu kata, database menyisir kolom teks, lalu mengembalikan baris yang memuat rangkaian huruf yang sama persis. Cara ini menopang hampir semua aplikasi selama puluhan tahun, dan bekerja baik selama pembaca memakai kata yang sama dengan penulisnya.

Masalahnya muncul ketika kata yang dipakai berbeda meski maksudnya sama. Seseorang yang mengetik "cara menghemat listrik" tidak akan menemukan artikel berjudul "tips mengurangi tagihan PLN", karena tidak ada satu pun kata yang cocok. Bagi database, dua kalimat itu tidak berhubungan sama sekali. Bagi manusia, keduanya jelas membicarakan hal yang sama.

Vector database adalah jenis penyimpan data yang mencari berdasarkan kedekatan makna, bukan kecocokan huruf. Data di dalamnya tidak disimpan sebagai teks, melainkan sebagai deretan angka yang mewakili artinya, sehingga dua kalimat dengan maksud serupa dapat ditemukan meski tidak berbagi satu kata pun.

Vector Database Adalah? Pengertian dan Bedanya

Vector database adalah sistem penyimpanan yang dirancang khusus untuk menampung vektor (deretan angka berdimensi tinggi yang mewakili makna sebuah data) dan menemukan vektor lain yang posisinya paling berdekatan. Sebagian orang menuliskannya terbalik menjadi database vector, sebagian lagi menerjemahkannya menjadi database vektor, tetapi yang dimaksud tetap sama.

Perbedaannya dengan database biasa terletak pada pertanyaan yang bisa dijawab. Database relasional menjawab pertanyaan berbentuk "mana baris yang nilainya sama dengan ini". Vector database menjawab pertanyaan berbentuk "mana sepuluh data yang paling mirip dengan ini". Yang pertama menghasilkan jawaban benar atau salah; yang kedua menghasilkan peringkat kemiripan.

Konsekuensinya, hasil pencarian di vector database selalu berupa daftar terurut beserta skor kedekatannya. Tidak ada istilah "tidak ditemukan", karena selalu ada data yang paling dekat sekalipun kedekatannya rendah. Menentukan batas skor mana yang layak ditampilkan adalah tanggung jawab aplikasi Anda, bukan databasenya.

Pencarian kata gagal menemukan apa pun, sedangkan vector database mengembalikan tiga artikel PLN yang maknanya dekat.

Perlu diluruskan sejak awal, vector database bukan pengganti database yang sudah Anda pakai. Ia menjawab satu jenis pertanyaan yang tidak bisa dijawab tabel baris-kolom, dan pada hampir semua aplikasi nyata keduanya berjalan berdampingan. Data pesanan, pengguna, dan transaksi tetap tinggal di database relasional.

Apa yang Sebenarnya Disimpan di Dalamnya

Isi sebuah vector database adalah embedding, yaitu hasil olahan sebuah model AI yang mengubah teks, gambar, atau suara menjadi deretan angka bermakna. Model itulah yang menentukan kualitas pencarian Anda; databasenya hanya menyimpan dan mencarinya kembali.

Yang berguna untuk diketahui adalah panjang deretan angka tersebut, karena angka itu menentukan biaya penyimpanan Anda. Model text-embedding-3-small dari OpenAI menghasilkan 1.536 angka untuk setiap potongan teks, sedangkan text-embedding-3-large menghasilkan 3.072 angka. Model sumber terbuka yang berukuran lebih kecil umumnya berada di kisaran 384 sampai 768 angka.

Setiap angka itu memakan tempat. Ekstensi pgvector pada PostgreSQL menyimpan satu vektor sebesar 4 × dimensi + 8 byte, sehingga satu vektor 1.536 dimensi memakan 6.152 byte. Kalikan dengan satu juta potongan dokumen, dan Anda membutuhkan sekitar 6,15 GB hanya untuk vektornya, belum termasuk teks aslinya, metadata, maupun indeksnya.

Angka ini penting dipahami sebelum memilih model. Memilih dimensi dua kali lipat berarti melipatduakan tagihan penyimpanan dan kebutuhan memori selamanya, demi peningkatan akurasi yang sering kali hanya beberapa persen.

Cara Kerja Vector Database: Mencari Tetangga Terdekat

Alur kerjanya berlangsung dalam tiga tahap yang selalu sama. Pertama, data Anda dilewatkan ke model embedding dan berubah menjadi vektor. Kedua, vektor itu disimpan bersama teks aslinya dan metadata seperti kategori atau tanggal. Ketiga, pertanyaan yang masuk diubah menjadi vektor dengan model yang sama, lalu database mencari vektor tersimpan yang paling berdekatan dengannya.

Kedekatan diukur dengan rumus jarak. Yang paling umum dipakai adalah cosine distance, yang mengukur seberapa searah dua vektor menunjuk. Dua rumus lain yang sering muncul adalah L2 distance untuk jarak garis lurus dan inner product untuk kesejajaran arah sekaligus panjangnya. Pada pgvector ketiganya tersedia sebagai operator terpisah: <=> untuk cosine, <-> untuk L2, dan <#> untuk inner product. Memilih rumus yang berbeda dari yang dipakai saat model dilatih akan menghasilkan peringkat yang meleset.

Persoalan sesungguhnya ada pada tahap ketiga. Mencari vektor terdekat secara benar-benar tepat berarti membandingkan pertanyaan dengan seluruh isi database satu per satu. Cara ini disebut pencarian eksak dan tetap paling akurat, tetapi menjadi terlalu mahal ketika datanya membesar.

Tiga tahap vector database: ubah dokumen jadi vektor, simpan bersama metadata, lalu cari vektor yang paling terdekat.

Di sinilah masuk approximate nearest neighbor atau pencarian tetangga terdekat secara perkiraan. Pendekatan ini membangun indeks khusus supaya database cukup memeriksa sebagian kecil data saja.

Dua bentuk indeks yang paling banyak dipakai adalah HNSW dan IVF. HNSW, singkatan dari Hierarchical Navigable Small World, membangun graf berlapis tempat pencarian melompat dari lapisan renggang ke lapisan rapat sampai menemukan kawasan yang tepat. Gagasannya diperkenalkan Yu. A. Malkov dan D. A. Yashunin lewat makalah Maret 2016, dan masih menjadi bawaan hampir semua produk sampai hari ini. IVF mengambil jalan berbeda: data dikelompokkan lebih dulu, lalu pencarian hanya menyisir kelompok yang paling menjanjikan.

Kata "perkiraan" di sini bukan kiasan. Indeks perkiraan memang sengaja melewatkan sebagian data demi kecepatan, sehingga ada kemungkinan jawaban yang paling benar justru tidak ikut terambil. Persentase jawaban benar yang berhasil ditemukan disebut recall, dan menaikkannya selalu berarti menurunkan kecepatan.

Vector Database Itu SQL atau NoSQL?

Pertanyaan ini sering muncul, dan jawaban jujurnya adalah bukan keduanya. SQL dan NoSQL membedakan database berdasarkan cara data disusun dan diakses. Kemampuan vektor bukan cara menyusun data, melainkan satu jenis indeks dan satu jenis operasi pencarian yang bisa ditambahkan ke bentuk penyimpanan mana pun.

Angka peringkat DB-Engines pada Agustus 2026 memperlihatkannya dengan jelas. Kategori vector DBMS berisi 26 sistem, tetapi hanya 10 di antaranya yang model tunggalnya memang vector. Enam belas sisanya adalah database multi-model yang menambahkan kemampuan ini di atas fungsi lamanya.

Gambarannya berubah lebih jauh lagi kalau database yang menaruh kemampuan vektor sebagai fungsi sampingan ikut dihitung. Jumlahnya menjadi 37 sistem, dan lima teratasnya bukan nama-nama baru sama sekali: Oracle dengan skor 1.123,43, PostgreSQL 684,58, MongoDB 384,88, Redis 156,51, dan Apache Cassandra 99,98. Skor Oracle sendirian lebih dari seratus kali lipat skor Pinecone.

Artinya, pertanyaan yang lebih berguna bukan "vector database itu SQL atau NoSQL", melainkan "apakah database yang sudah saya pakai sanggup menyimpan vektor". Untuk sebagian besar pembaca, jawabannya sudah ya.

Kegunaan Vector Database dan Contoh Penerapannya

Kemampuan mencari berdasarkan kemiripan makna melahirkan sejumlah penerapan yang mungkin sudah Anda pakai setiap hari:

1. Pencarian semantik: mesin pencari internal yang memahami maksud, sehingga pertanyaan "berapa lama garansinya" menemukan halaman berjudul "ketentuan klaim purnajual".
2. RAG: teknik RAG (Retrieval-Augmented Generation) mencari potongan dokumen yang relevan di vector database, lalu menyerahkannya ke sebuah LLM sebagai bahan jawaban. Inilah cara chatbot bisa menjawab dari dokumen perusahaan Anda sendiri, dan penerapan yang paling banyak mendorong pemakaian vector database hari ini.
3. Sistem rekomendasi: produk, lagu, atau artikel yang vektornya berdekatan dianggap mirip, lalu disarankan tanpa perlu aturan yang ditulis manual.
4. Pencarian gambar dan audio: mengunggah foto sepatu untuk menemukan model serupa di katalog, atau mencocokkan rekaman dengan lagu aslinya.
5. Deteksi duplikat dan anomali: menemukan dua tiket bantuan yang isinya sama meski kalimatnya berbeda, atau menandai transaksi yang polanya menyimpang.
6. Memori jangka panjang untuk AI agent: menyimpan riwayat percakapan supaya asisten dapat memanggil kembali bagian yang relevan tanpa memuat seluruh riwayat.

Benang merahnya sama: yang dicari bukan data yang identik, melainkan data yang paling mirip.

Enam penerapan vector database: pencarian semantik, RAG, rekomendasi, pencarian gambar, deteksi duplikat, memori AI agent.

Pilihan Vector Database: Khusus, Open Source, atau Menumpang

Alih-alih memilih dari daftar sepuluh produk terbaik, akan lebih mudah memilah pilihan menjadi tiga jalur dengan konsekuensi yang berbeda.

Jalur pertama, vector database khusus. Produk-produk ini dibangun dari nol untuk satu tugas, sehingga fitur pencariannya paling lengkap. Pinecone adalah layanan terkelola berbayar tanpa versi yang bisa Anda pasang sendiri. Sisanya sumber terbuka dan gratis dipakai:

Di antara keempatnya, Chroma paling ringan untuk dicoba karena bisa berjalan sebagai pustaka di dalam program Anda, sedangkan Milvus paling berat karena dirancang untuk kluster berskala besar.

Jalur kedua, database yang sudah Anda pakai. Untuk PostgreSQL tersedia ekstensi pgvector, yang juga menjadi mesin di balik fitur vektor pada Supabase. Redis 8 membawa tipe vector set ke dalam intinya. Cassandra 5.0 menambahkan tipe data vector beserta klausa ANN OF. Elasticsearch dan OpenSearch sudah lama memiliki pencarian kNN.

MySQL adalah pengecualian yang perlu diwaspadai. Sejak MySQL 9 memang tersedia tipe VECTOR(N) yang menampung 2 sampai 16.383 angka. Namun fungsi DISTANCE() untuk menghitung kedekatan hanya tersedia bagi pengguna MySQL HeatWave dan MySQL AI, dan tidak disertakan pada edisi Community maupun Commercial. MySQL biasa karenanya dapat menyimpan vektor tanpa bisa mencarinya.

Jalur ketiga, penyimpanan objek. Amazon S3 Vectors, yang resmi umum dipakai sejak 2 Desember 2025, menyimpan vektor langsung di dalam bucket S3 dengan kapasitas sampai 2 miliar vektor per indeks. AWS mengklaim penghematan biaya sampai 90 persen dibanding vector database khusus, dengan konsekuensi waktu jawab di kisaran 100 milidetik, jauh lebih lambat daripada indeks yang seluruhnya berada di memori.

Satu nama yang sering salah dimasukkan ke daftar ini adalah FAISS. Pustaka buatan Meta yang terbit pada 2017 itu memang mesin pencarian vektor yang sangat cepat, tetapi ia bukan database. Tidak ada penyimpanan permanen, tidak ada API jaringan, dan tidak ada penanganan banyak pengguna sekaligus. FAISS adalah komponen di dalam sebuah sistem, bukan sistem yang berdiri sendiri.

Tiga jalur vector database: produk khusus paling lengkap, database yang sudah ada paling cepat, penyimpanan objek termurah.

Kelemahan dan Hal yang Perlu Anda Pertimbangkan

Sebelum memutuskan, ada beberapa keterbatasan yang sebaiknya Anda ketahui lebih dulu:

1. Hasilnya perkiraan, bukan kepastian: begitu indeks perkiraan dipakai, jawaban paling relevan bisa tidak ikut terambil. Pada pencarian dokumen hukum atau rekam medis, kehilangan satu hasil bisa berakibat serius.
2. Menyaring hasil justru menyulitkan: pada pgvector, penyaringan dijalankan setelah indeks disisir. Dengan nilai bawaan hnsw.ef_search sebesar 40, sebuah saringan yang cocok dengan 10 persen baris rata-rata hanya menyisakan 4 baris dari sepuluh yang Anda minta. Kegagalannya senyap, karena tidak ada pesan galat sama sekali.
3. Batas dimensi indeks lebih rendah daripada batas kolom: pgvector menampung sampai 16.000 dimensi dalam satu kolom, tetapi indeks HNSW dan IVFFlat menolak apa pun di atas 2.000 dimensi. Vektor text-embedding-3-large yang berdimensi 3.072 karenanya tersimpan rapi lalu tidak bisa diindeks, kecuali Anda memakai tipe halfvec yang batas indeksnya 4.000.
4. Ganti model berarti membangun ulang semuanya: vektor dari dua model berbeda tidak dapat dibandingkan. Berpindah model mengharuskan Anda memproses ulang seluruh dokumen dari awal, dengan biaya dan waktu yang sama seperti pengisian pertama.
5. Kebutuhan memori nyata: indeks HNSW baru cepat ketika seluruhnya berada di RAM. Satu juta vektor 1.536 dimensi sudah menempati 6,15 GB sebelum indeksnya dihitung, sehingga server dengan RAM 8 GB akan terasa sesak.
6. Tidak ada relasi antardata: tidak ada JOIN, dan jaminan transaksi umumnya lebih longgar.
7. Kualitasnya bergantung pada bahasa: kemampuan menangkap makna bahasa Indonesia sepenuhnya ditentukan model embedding yang Anda pilih. Tolok ukur pencarian multibahasa MIRACL menempatkan bahasa Indonesia sebagai bahasa berpenutur banyak namun miskin sumber data, sehingga selisih kualitas antarmodel di sini lebih lebar daripada di bahasa Inggris.

Kapan Anda Belum Membutuhkan Vector Database

Nasihat "pakai vector database kalau datanya besar" tidak banyak menolong tanpa angka. Untuk mendapatkan angkanya, kami mengukur sendiri berapa lama pemindaian menyeluruh berlangsung pada vektor 1.536 dimensi, memakai NumPy di sebuah komputer Apple M5 dengan RAM 16 GB.

Angka ini adalah batas bawah satu proses tanpa lapisan database, jaringan, maupun pengguna bersamaan, sehingga sistem sungguhan pasti lebih lambat. Yang dibuktikannya adalah urutan besaran, dan itu sudah cukup untuk mengambil keputusan.

Sebelum butuh vector database: 10.000 vektor terpindai 0,78 ms, 100.000 dalam 8,01 ms, dan sejuta dalam 86,02 ms.

Di bawah sekitar 100.000 vektor, pemindaian menyeluruh masih selesai dalam hitungan milidetik. Pada kisaran ini Anda tidak membutuhkan indeks perkiraan sama sekali, apalagi produk khusus. PostgreSQL dengan pgvector tanpa indeks sudah memberi jawaban yang benar-benar tepat dengan cepat. Barulah di atas satu juta vektor biaya pemindaian menjadi terasa dan indeks mulai berbayar, dan di atas puluhan juta vektor barulah produk khusus dengan kemampuan sharding benar-benar diperlukan.

Cara Mencoba Vector Database Tanpa Biaya

Cara termurah mencobanya adalah lewat PostgreSQL yang mungkin sudah Anda jalankan. Contoh berikut memakai vektor tiga dimensi supaya angkanya bisa ditulis utuh dan langsung Anda jalankan sendiri:

CREATE EXTENSION vector;

CREATE TABLE dokumen (
  id bigserial PRIMARY KEY,
  isi text,
  embedding vector(3)
);

INSERT INTO dokumen (isi, embedding) VALUES
  ('cara menghemat listrik', '[0.9,0.1,0.2]'),
  ('resep rendang padang', '[0.1,0.8,0.3]');

SELECT isi FROM dokumen
ORDER BY embedding <=> '[0.85,0.15,0.25]'
LIMIT 5;

Perintah terakhir mengurutkan baris berdasarkan cosine distance terhadap vektor pertanyaan, dan baris tentang listrik muncul lebih dulu karena arah vektornya paling berdekatan. Pada pemakaian sungguhan, tiga angka itu diganti keluaran model embedding yang panjangnya ratusan sampai ribuan. Selama barisnya masih di bawah ratusan ribu, Anda belum perlu membuat indeks apa pun.

Kalau ingin mencoba produk khusus, Chroma dapat dijalankan sebagai pustaka tanpa server terpisah, sedangkan Qdrant paling praktis dijalankan lewat Docker. Keduanya memakai port sendiri dan membutuhkan akses root, yang tidak tersedia pada shared hosting. Untuk keperluan ini, satu VPS Indonesia dengan RAM 4 GB sudah memadai untuk berlatih dengan ratusan ribu vektor.

Biaya yang tersisa hanyalah pembuatan embedding-nya. Dengan text-embedding-3-small seharga $0,02 per satu juta token, memproses 100.000 potongan dokumen sepanjang sekitar 400 token menghabiskan kira-kira $0,80. Angka itu bisa menjadi nol kalau Anda menjalankan model embedding secara lokal lewat Ollama, dengan pertukaran berupa waktu proses yang lebih lama.

Pertanyaan yang Sering Muncul Soal Vector Database

Beberapa pertanyaan berikut paling sering muncul ketika orang mulai mencari tahu apa itu vector database.

Apa itu vector database dan apa bedanya dari database biasa?

Database biasa mencari baris yang nilainya cocok persis, sedangkan vector database mencari data yang maknanya paling berdekatan dan mengembalikannya sebagai daftar berperingkat.

Apakah vector database termasuk SQL atau NoSQL?

Bukan keduanya. Kemampuan vektor adalah jenis indeks dan operasi pencarian, bukan cara menyusun data, sehingga bisa ditambahkan ke database relasional maupun non-relasional. Buktinya, PostgreSQL yang relasional dan MongoDB yang berbasis dokumen sama-sama sudah mendukungnya.

Apa vector database yang paling banyak dipakai?

Menurut peringkat DB-Engines Agustus 2026, Elasticsearch memimpin kategori ini dengan skor 94,34, disusul OpenSearch dan Couchbase. Pinecone dengan skor 9,32 adalah produk vector murni dengan peringkat tertinggi, diikuti Milvus, Qdrant, dan Weaviate.

Apakah ada vector database gratis?

Ada, dan pilihannya banyak. Qdrant, Milvus, Chroma, dan Weaviate semuanya open source dan boleh Anda pasang sendiri tanpa biaya lisensi, begitu pula ekstensi pgvector untuk PostgreSQL. Yang tetap berbayar hanyalah server tempat menjalankannya dan pembuatan embedding kalau memakai model berbayar.

Apakah FAISS termasuk vector database?

Tidak. FAISS adalah pustaka pencarian kemiripan buatan Meta yang berjalan di dalam program Anda. Ia tidak menyimpan data secara permanen dan tidak menyediakan API jaringan, sehingga lebih tepat disebut komponen daripada database.

Apakah MySQL bisa dipakai sebagai vector database?

Untuk saat ini tidak sepenuhnya. MySQL 9 memang punya tipe VECTOR, tetapi fungsi DISTANCE() yang menghitung kedekatan hanya tersedia di MySQL HeatWave dan MySQL AI, bukan di edisi Community. Kalau Anda memakai MySQL biasa, PostgreSQL dengan pgvector adalah jalan yang jauh lebih mulus.

Berapa besar penyimpanan yang dibutuhkan satu juta vektor?

Dengan rumus pgvector 4 × dimensi + 8 byte per vektor, satu juta vektor berdimensi 1.536 memakan 6,15 GB dan yang berdimensi 3.072 memakan 12,30 GB. Angka itu belum menghitung teks asli, metadata, maupun indeksnya, jadi siapkan kapasitas dua sampai tiga kali lipatnya.

Kesimpulan

Vector database adalah penyimpan data yang menampung makna dalam bentuk deretan angka dan mencarinya berdasarkan kedekatan, bukan kecocokan huruf. Cara kerjanya berpijak pada pencarian tetangga terdekat, yang dipercepat indeks seperti HNSW dengan konsekuensi sebagian hasil sengaja dilewatkan. Dari sanalah lahir pencarian semantik, rekomendasi, dan RAG.

Yang perlu diingat, ini bukan kategori produk yang wajib dibeli terpisah. Lima database terpopuler dunia sudah bisa menyimpan vektor, dan di bawah seratus ribu vektor pemindaian menyeluruh masih selesai dalam hitungan milidetik. Mulailah dari database yang sudah Anda punya, ukur sendiri kapan ia kewalahan, lalu pindah ke produk khusus ketika angkanya menuntut. Semoga artikel ini membantu.