Aurora PostgreSQL + pgvector
pgvector menambahkan tipe data vektor ke PostgreSQL. Kalau aplikasimu sudah memakai Aurora, ini sering pilihan paling praktis — dan paling murah.
Intisari
- Ekstensi
pgvectormenambahkan tipevectordan operator jarak ke PostgreSQL. - Satu
JOINbisa menggabungkan pencarian vektor dengan tabel bisnismu — tanpa dua sistem. - Indeks HNSW lebih cepat dan akurat untuk query; IVFFlat lebih cepat dibangun.
- Untuk knowledge base, field metadata untuk filter harus kamu buat sendiri di Aurora.
- Aurora Serverless v2 bisa turun sampai nol ACU — sering jauh lebih murah daripada OpenSearch untuk data kecil.
Menyiapkan
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE potongan (
id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
teks text NOT NULL,
vektor vector(1024) NOT NULL,
departemen text,
tahun int,
sumber text
);
-- HNSW: lebih cepat dan akurat saat query, lebih lambat saat dibangun
CREATE INDEX ON potongan USING hnsw (vektor vector_cosine_ops);
-- Filter metadata jauh lebih cepat kalau kolomnya juga diindeks
CREATE INDEX ON potongan (departemen, tahun);
Mencari
-- <=> adalah operator jarak cosine
SELECT teks, sumber, 1 - (vektor <=> $1) AS kemiripan
FROM potongan
WHERE departemen = 'hr' AND tahun >= 2024
ORDER BY vektor <=> $1
LIMIT 5;
| Operator | Jarak | Dipakai dengan |
|---|---|---|
<=> | Cosine | vector_cosine_ops — paling umum untuk teks |
<-> | Euclidean (L2) | vector_l2_ops |
<#> | Inner product negatif | vector_ip_ops |
Operator indeks harus cocok dengan operator query. Indeks yang dibuat dengan
vector_l2_ops tidak akan dipakai oleh query yang memakai <=> —
PostgreSQL diam-diam beralih ke pemindaian penuh. Gejalanya bukan error, melainkan query yang mendadak
lambat saat data bertambah. Periksa dengan EXPLAIN.
Keunggulan sesungguhnya: satu JOIN
SELECT p.teks, d.judul, d.pemilik, d.terakhir_diubah
FROM potongan p
JOIN dokumen d ON d.id = p.dokumen_id
WHERE d.pemilik = $2 -- kontrol akses dari tabel bisnismu
AND d.status = 'terbit'
ORDER BY p.vektor <=> $1
LIMIT 5;
Inilah yang tidak bisa dilakukan vector store terpisah tanpa menyalin data: aturan otorisasi dan status dokumen tinggal di tabel yang sama, dijalankan dalam satu transaksi, dan selalu konsisten. Untuk aplikasi multi-tenant yang datanya sudah di PostgreSQL, ini sering keputusan yang benar.
Aurora atau OpenSearch?
| Aurora + pgvector | OpenSearch Serverless | |
|---|---|---|
| Sudah punya datanya di sini | Keunggulan besar | Perlu sistem tambahan |
| Hybrid search (kata kunci) | Perlu tsvector, digabung manual | Bawaan |
| Skala sangat besar | Perlu penyetelan | Lebih alami |
| Biaya untuk data kecil | Bisa mendekati nol dengan Serverless v2 | Ada kapasitas minimum |
| Field metadata untuk KB | Harus dibuat manual | Ditangani otomatis |
| Vektor biner | Tidak | Ya |
Menghubungkan ke Knowledge Bases
Bedrock terhubung ke Aurora lewat Data API, dengan kredensial dari Secrets Manager. Yang perlu kamu siapkan sebelum membuat knowledge base:
- Ekstensi
vectoraktif. - Tabel dengan kolom vektor, teks, dan metadata yang dikelola Bedrock.
- Kolom untuk tiap atribut metadata yang ingin kamu filter — di Aurora ini tidak otomatis.
- Data API diaktifkan pada cluster.
- Kredensial tersimpan di Secrets Manager, dan role KB boleh membacanya.
Latihan: buat cluster Aurora Serverless v2 PostgreSQL kecil, aktifkan pgvector, dan muat 20 potongan
beserta embedding-nya dari latihan Titan. Jalankan query kemiripan dengan filter departemen, lalu
jalankan EXPLAIN dan pastikan indeks HNSW benar-benar dipakai.
Rangkuman ini sengaja dipangkas ke bagian yang dipakai di roadmap. Buka sumber aslinya saat kamu butuh detail lengkap atau referensi parameter.