Vector search DynamoDB

DynamoDB mendapatkan vector search native pada 5 Agustus 2026. Anda menyimpan embedding sebagai List berisi nilai Number biasa pada item Anda, menambahkan vector index, dan menjalankan query approximate nearest neighbor dengan API SearchVectors yang baru.

Sampai sekarang, similarity search berarti mereplikasi tabel Anda ke OpenSearch atau vector database terpisah dan menjaga keduanya tetap sinkron. Pipeline itu kini hilang. Model penagihan yang menggantikannya tidak seperti apa pun di DynamoDB.

Apakah DynamoDB mendukung vector search?

Ya — secara native, sejak 5 Agustus 2026. Anda menyimpan embedding sebagai List berisi nilai Number biasa, menambahkan vector index, dan menjalankan query approximate nearest neighbor dengan API SearchVectors — tanpa replika OpenSearch, tanpa vector database terpisah. Ia bekerja hanya pada tabel on-demand, hingga 4,096 dimensi, dan ditagih per byte yang ditulis, dicari, dan disimpan.

• Keluarga indeks ketiga: vector index duduk di samping GSI dan LSI. Satu API baca baru (SearchVectors), hanya ANN, hanya tabel on-demand, hingga 4,096 dimensi.
• Cepat, dan terukur: terhadap indeks 1024 dimensi live kami di us-east-1, SearchVectors menjawab secepat GetItem dari klien yang sama (p50 39 ms vs 44 ms), dan write yang baru menjadi dapat dicari dalam ~136 ms.
• Metering-nya per byte: $0.52 per GB write vektor, $0.002 per GB data vektor yang diperiksa sebuah pencarian, $0.25 per GB-bulan storage (us-east-1). Mengindeks sebuah embedding membuat salinan tabel dasarnya ditagih tepat 4 byte per dimensi; list yang sama tanpa indeks ditagih ~1.9×.
• S3 Vectors tetap menjadi bulk store: kira-kira 8× lebih murah saat diam dan jauh lebih murah untuk batch-load. DynamoDB menang di baca milidetik, write streaming, dan vektor yang hidup di samping item yang dideskripsikannya.

Cara kerja vector index

Tidak ada tipe atribut baru. Embedding adalah list angka biasa pada item, {"L": [{"N": "0.0132"}, {"N": "-0.0475"}, …]} di wire, ditulis dengan PutItem dan UpdateItem yang sama yang sudah Anda pakai.

Indeksnya adalah struktur terpisah. DynamoDB mereplikasi vektor ke dalamnya secara asinkron pada presisi float 32-bit, bersama atribut apa pun yang Anda project atau filter. Hasil pencarian bersifat eventually consistent, seperti baca GSI.

Lag-nya kecil dalam praktik. Terhadap indeks uji live kami, vektor yang baru ditulis muncul di hasil pencarian sekitar 136 ms setelah PutItem kembali. Tetap saja, jangan pernah membangun alur read-your-own-write di atasnya.

Posisinya di samping tipe indeks yang sudah Anda kenal:

Setiap indeks mengunci jumlah dimensinya (hingga 4,096) dan satu dari tiga distance function saat dibuat. COSINE dan EUCLIDEAN memberi skor makin-rendah-makin-mirip; DOT_PRODUCT memberi skor makin-tinggi-makin-mirip dan bisa negatif. Tidak ada yang bisa diubah belakangan.

Satu catatan presisi sebelum Anda mem-benchmark apa pun. Indeks menampung vektor pada f32; nilai berpresisi lebih tinggi diterima tetapi kehilangan presisi di jalan masuk. Jika Anda datang dengan embedding float64, setiap jarak dihitung terhadap salinan f32, jadi ukur recall terhadap f32, bukan terhadap aslinya.

Buat satu dan cari di dalamnya

Misalkan Anda menjalankan semantic search atas tiket support, agar seorang agen bisa menemukan "pelanggan yang pernah mengalami ini sebelumnya" tanpa mencocokkan kata kunci. Setiap item tiket membawa embedding dari subject dan body-nya, dihasilkan oleh model apa pun yang Anda suka (Titan Text Embeddings V2 berbiaya $0.02 per juta token input di Bedrock).

Tambahkan indeksnya ke tabel yang sudah ada. Elemen HASH melingkupi setiap pencarian ke satu nilai product; atribut INLINE_FILTER (hingga 18) mengizinkan filter equality saat pencarian:

aws dynamodb update-table \
  --table-name SupportTickets \
  --attribute-definitions AttributeName=product,AttributeType=S \
                          AttributeName=severity,AttributeType=S \
  --vector-index-updates '[{"Create": {
    "IndexName": "TicketEmbeddings",
    "VectorAttribute": {"AttributeName": "embedding"},
    "SearchSchema": [
      {"AttributeName": "product", "SearchSchemaElementType": "HASH"},
      {"AttributeName": "severity", "SearchSchemaElementType": "INLINE_FILTER"}
    ],
    "Projection": {"ProjectionType": "KEYS_ONLY"},
    "Dimensions": 1024,
    "DistanceFunction": "COSINE"
  }}]'

Proses build berperilaku seperti backfill GSI dengan tepi yang lebih tajam. SearchVectors mengembalikan ValidationException selama seluruh build, tanpa hasil parsial.

AWS memperingatkan endpoint pencarian bisa terus menolak sebentar bahkan setelah DescribeTable mengatakan ACTIVE. Tidak ada waiter; probe dengan pencarian nyata dalam retry loop. Saat kami membuat indeksnya bersama sebuah tabel kosong, ia menjadi ACTIVE dalam 26 detik dan menerima pencarian 0.6 s kemudian.

Pencarian menerima query embedding sebagai array JSON telanjang berisi nilai {"N": …}. Jangan membungkusnya dalam L DynamoDB. Atribut yang tersimpan memakai tipe list, parameter request tidak, dan menukar keduanya adalah kesalahan pertama yang mudah terjadi:

aws dynamodb search-vectors \
  --table-name SupportTickets \
  --index-name TicketEmbeddings \
  --search-vector file://query-embedding.json \
  --top-k 5 \
  --search-condition-expression "product = :p AND severity = :sev" \
  --expression-attribute-values '{":p": {"S": "checkout"}, ":sev": {"S": "high"}}'

Anda mendapatkan kembali hingga TopK item terurut paling-mirip-dulu, masing-masing dengan Score, plus ConsumedCapacity bila Anda memintanya. TopK mentok di 100, tidak ada pagination, dan respons mentok di 16 MB.

Embedding-nya sendiri dikecualikan dari hasil kecuali Anda mem-project dan memintanya. Default itu disengaja; mengembalikan vektor menggelembungkan respons sekaligus tagihan pencarian.

Filter expression hanya menerima equality, tanpa BETWEEN, IN, atau begins_with. Saat indeks mendefinisikan atribut HASH, setiap pencarian harus mematok tepat satu nilai untuknya. Kata-kata AWS soal operator range adalah "not yet available", jadi ini mungkin melonggar.

Dua kejutan operasional layak diketahui sebelum deploy pertama. SearchVectors butuh action IAM baru dynamodb:SearchVectors, yang tidak ada di satu pun policy baca Anda yang sudah ada.

Ia juga berbicara ke endpoint terpisah, search-dynamodb.{region}.amazonaws.com. Allowlist egress dan konfigurasi VPC endpoint yang hanya mencakup dynamodb.{region} mematahkan vector search saja, dengan error koneksi yang tidak pernah menyebut alasannya.

Apa yang ditagih vector index

Tiga meter baru, semuanya per byte, dengan minimum 1 KB per write dan per request pencarian, di atas biaya tabel normal (us-east-1, dari API harga AWS, 2026-08-15):

Dokumennya memperingatkan bahwa salinan tabel dasar sebuah embedding, disimpan sebagai string desimal di dalam List, bisa "considerably larger" daripada salinan f32 di indeks. Kami mengukur penagihan write-unit terhadap tabel live di us-east-1, dan kenyataannya lebih aneh.

Embedding pada atribut tanpa vector index ditagih menurut aturan desimal yang terdokumentasi, kira-kira 1.9× ukuran f32-nya. Arahkan sebuah vector index ke atribut yang sama dan penagihan tabel dasarnya turun menjadi tepat 4 byte per dimensi:

Diukur dengan binary-search atas batas write-unit memakai atribut padding, key item baru untuk setiap write, terkalibrasi sampai ke byte. Item tiket 1024 dimensi penuh kami menagih 5 write unit; item identik tanpa indeks pada embedding menagih 8.

Meter write vektor mengikuti ukuran f32 dengan ketat pada run yang sama. VectorWriteRequestBytes kembali sebagai 4 byte per dimensi plus 11 B overhead key pada indeks polos, dan plus 65 B dengan search schema dua-atribut kami.

Penagihan pencarian adalah meter yang tidak bisa Anda hitung di muka. VectorSearchRequestBytes melacak berapa banyak data vektor yang diperiksa traversal ANN, dan panduan AWS sendiri adalah mengukurnya via ReturnConsumedCapacity alih-alih mengestimasi dari jumlah dimensi.

Probe kami memberikan titik data pertama. TopK=10 atas partisi 50 vektor memeriksa 22.2-22.4 KB per pencarian; pencarian yang sama atas partisi 1 vektor tetap memeriksa 21.4 KB, jadi pada skala kecil ada lantai kira-kira 21 KB (sekitar $0.00000004) per query. Tutorial AWS melaporkan 31,449 byte untuk contoh 50 vektornya sendiri.

Modelkan biaya sisi tabel di kalkulator harga; meter vektor menumpuk di atas write unit yang sudah dihitungnya.

Vector search DynamoDB vs S3 Vectors

AWS kini menjual dua vector store serverless, dan keduanya dibangun untuk access pattern yang berlawanan. S3 Vectors (GA Desember 2025) menampung hingga 2 miliar vektor per indeks pada $0.06/GB-bulan, menjawab dalam rentang 100 ms sampai 1 s, dan menagih setiap query terhadap ukuran seluruh indeks.

DynamoDB menjawab dalam milidetik dan menagih terhadap apa yang diperiksa pencarian, bukan terhadap apa yang ditampung indeks.

Minimum write memutuskan kasus streaming, dan arahnya berlawanan dengan tarif storage. Menulis satu vektor 1024 dimensi sekali waktu, per juta write (dari tarif terverifikasi dan hasil ukur kami 5 write unit + 4,161 byte write vektor per item):

Minimum 128 KB per PUT milik S3 menjadikannya opsi mahal justru untuk workload yang orang kira murah baginya. Stream vektor satu per satu ke S3 Vectors dan Anda membayar hampir 5× tarif DynamoDB; batch-load dan Anda membayar kira-kira 7× lebih murah.

Total bulanan storage dan query untuk korpus 1024 dimensi pada 1M query per bulan, dihitung dari tarif terverifikasi (biaya write ada di tabel per-juta di atas). Biaya query S3 Vectors mengikuti formula terpublikasinya, ukuran seluruh indeks dikali tarif bertingkat.

Biaya query DynamoDB bergantung pada byte yang diperiksa, jadi kami menampilkan rentang sensitivitas alih-alih pura-pura tahu traversal Anda:

Dua hal jatuh dari tabel itu. Biaya per-query DynamoDB tidak tumbuh dengan ukuran korpus — pencarian ANN memeriksa satu lingkungan, bukan indeksnya, dan pelingkupan partition key mengecilkannya lebih jauh.

Keunggulan storage S3 Vectors (~8×, karena DynamoDB menyimpan dua salinan f32 pada 4× tarifnya) terus berbunga selamanya, ada yang meng-query atau tidak.

Kapan memakai yang mana

• Vektor mendeskripsikan item hidup yang sudah Anda simpan di DynamoDB (tiket, produk, sesi user, memori agen): pakai vector index. Satu jalur write, satu item, tanpa pipeline sinkronisasi yang bisa melenceng.
• Jutaan embedding, di-query sesekali (RAG atas dokumen, arsip, job malam): pakai S3 Vectors. Batch-load dengan murah, bayar $0.06/GB saat diam, toleransi beberapa ratus ms.
• QPS tinggi dengan ranking hybrid (relevansi teks + vektor, faceting, agregasi): OpenSearch tetap jawabannya, dengan lantai infrastruktur kira-kira $350/bulan untuk collection serverless klasik.
• Vektor yang di-join ke data relasional: Aurora PostgreSQL dengan pgvector, yang bisa scale ke nol dan mendarat di bawah ~$50/bulan untuk workload RAG kecil.

Default jujur untuk shop DynamoDB adalah keduanya. Simpan vektor panas yang bisa difilter di tabel tempat write atomik dengan item-nya, dan arsipkan long tail ke S3 Vectors, yang write batch strongly consistent-nya menjadikannya sink yang bersih.

Jebakannya

• De-indexing senyap: item yang tidak punya atribut HASH indeks menulis ke tabel dengan baik dan tidak pernah masuk vector index. Kami mereproduksinya live: PutItem-nya berhasil, dan vektornya absen dari setiap partisi 15 detik kemudian. Tanpa error, tanpa hasil, tidak ada apa pun di respons yang memberi tahu Anda.
• Write berdimensi salah ditolak: ganti model embedding tanpa migrasi dan setiap write gagal dengan ValidationException yang menyebut atribut dan kedua ukurannya (Invalid size for parameter, direkam verbatim di halamannya sendiri), karena indeks mematok jumlah dimensi selamanya.
• Embedding basi: DynamoDB tidak pernah menghitung ulang vektor. Edit teks tiket tanpa menulis ulang embedding dan pencarian diam-diam mencocokkan konten lama. Streams plus consumer regenerasi adalah perbaikan standarnya.
• TopK selalu mengembalikan K item: dengan tiga kecocokan bagus dan --top-k 10, Anda tetap mendapat 10. Nilai relevansi dari Score, bukan dari jumlah hasil, dan ingat arah skor berbalik antar distance function.
• Minimum 1 KB: vektor berdimensi rendah tidak di-meter lebih murah secara proporsional, baik pada write maupun pencarian.
• Semuanya immutable: dimensi, distance function, dan set atribut proyeksi INCLUDE semuanya butuh delete-dan-buat-ulang untuk berubah. Storage indeks menagih sepanjang umur indeks, di-query atau tidak.

Coba pada tabel Anda sendiri

Vector search mewarisi disiplin biaya yang diajarkan bagian lain DynamoDB kepada Anda. Ukur embedding sebelum Anda berkomitmen padanya, karena limit ukuran item tetap berlaku dan embedding 3072 dimensi menambahkan 12 KB pada setiap write item di kedua meter.

Mekanika indeksnya akan terasa akrab jika Anda tahu bagaimana GSI mereplikasi secara asinkron dan kapan memilih GSI ketimbang LSI. Untuk pencarian leksikal atas data yang sama, DynamoDB tetap tidak punya mesin full-text; vector search mencocokkan makna alih-alih ejaan.

Periksa biaya byte nyata sebuah embedding di kalkulator ukuran item, lalu coba DynoTable untuk menelusuri item di balik vector index Anda — embedding dirender sebagai atribut list biasa tepat di samping field yang Anda filter.