Databricks Membawa Pencarian Teks Penuh dan Vektor ke Lakebase Postgres

Databricks pada 28 September 2026, memperkenalkan Lakebase Search, sebuah mesin pencari bawaan untuk basis data Lakebase Postgres miliknya yang disediakan melalui dua ekstensi: lakebasevektor untuk pencarian tetangga terdekat perkiraan dan lakebasetext untuk pencarian teks penuh BM25. Kedua ekstensi tersedia secara umum di AWS dan Azure.

Ekstensi memungkinkan pengembang menjalankan pencarian semantik, kata kunci, dan hibrida langsung di dalam Postgres bersamaan dengan data operasional. Databricks mengatakan sistem OLTP tradisional tidak dirancang untuk kebutuhan pencarian agen AI, yang memerlukan pengambilan data berlatensi rendah, akurasi tinggi, dan sering melakukan pencarian paralel masif, dan bahwa menyelesaikan hal ini hingga kini berarti menempelkan mesin pencari mandiri ke basis data utama dengan pipeline ETL. Perusahaan tersebut mengatakan bahwa ia membangun Lakebase Search bersamaan dengan umpan balik dari ratusan pelanggan beta.

Hasil Benchmark dan Penerapan Conexiom

Databricks mengatakan lakebase_vektor memberikan dua kali throughput sistem terdekat pada benchmark VectorDBBench 100M, yang menggunakan dataset LAION, dan bahwa harganya empat kali lebih murah dibandingkan vendor Postgres cloud yang menggunakan pgvector, sebelum penghematan tambahan dari penskalaan otomatis. Perusahaan melaporkan latensi P99 sebesar 71 milidetik dengan recall 97%, yang berarti mesin berhasil mengambil tetangga terdekat yang sebenarnya 97% waktu, dan mencatat bahwa pgvector dan DiskANN hanya diuji pada satu instance besar.

Databricks juga melaporkan hasil pelanggan dari Conexiom, yang menjalankan pencarian hibrida BM25 pada lebih dari 100 juta baris dengan jejak komputasi setengah dari konfigurasi pgvector sebelumnya. Biaya infrastruktur Conexiom turun tiga kali lipat dan throughput naik lima kali lipat dibandingkan pgvector, kata perusahaan.

“Lakebase Search memberi kami tingkat skalabilitas yang benar-benar baru dibandingkan pgvector, dan membuka BM25 dalam basis data serverless yang sama,” kata Jordan Voves, seorang arsitek AI/ML di Conexiom. “Kami menggunakan Lakebase untuk menghubungkan data ke agen kami secara skala besar.”

Batasan Pgvector di Balik Desain

Databricks mengatakan pgvector adalah ekstensi yang paling banyak dipasang di Lakebase Postgres, dan menggambarkan tiga masalah berulang yang diamati dari pelanggan yang menjalankannya pada skala besar.

Yang pertama adalah biaya yang meningkat seiring volume data bukan penggunaan. pgvector menyimpan indeks HNSW-nya di memori basis data, dan karena pencarian HNSW bergantung pada penelusuran grafik akses acak, kinerja menurun antara 10 hingga 50 kali setelah indeks tumpah ke disk dan kueri menjadi rangkaian pembacaan acak. Vektor float32 berdimensi 768 memakan sekitar 3,3 kilobyte memori setelah tautan grafik dan overhead Postgres termasuk, sehingga indeks pada 100 juta baris memerlukan kira-kira 330 gigabyte RAM untuk tetap berada di memori, disediakan secara penuh terlepas apakah kueri mengaksesnya atau tidak.

Yang kedua adalah pemeliharaan indeks. Ketika sebuah pembuatan indeks tumpah ke disk, indeks pgvector memakan hampir 50 jam untuk dibangun pada instance cloud standar, kata Databricks, dan penulisan mengalami kemacetan yang sama karena menyisipkan vektor memerlukan penelusuran akses acak dan modifikasi beberapa lapisan grafik. Karena HNSW tidak memiliki penyeimbangan ulang global, memulihkan kualitas pencarian berarti menjalankan REINDEX penuh, sebuah operasi yang mengunci tabel dan menghentikan penulisan produksi.

Yang ketiga adalah bahwa satu kueri tidak dapat diparalelkan. Kueri pgvector dieksekusi oleh satu proses backend Postgres, sehingga pemindaian indeks HNSW tidak memiliki paralelisasi. Meningkatkan recall memerlukan kunjungan ke lebih banyak node grafik, yang menambah pembacaan memori acak dan perbandingan jarak, meningkatkan latensi dan mengurangi kueri per detik, sehingga meningkatkan throughput berarti menambah koneksi basis data atau replika baca.

Cara Lakebase_vector Dibangun

Lakebase Postgres memisahkan penyimpanan dari komputasi: data permanen berada di penyimpanan objek cloud berbiaya rendah, sementara RAM dan NVMe lokal berfungsi sebagai cache singkat yang menyimpan set kerja aktif. Di atas fondasi itu, Databricks menggabungkan dua teknik.

Klasterisasi IVF hierarkis mengelompokkan vektor ke dalam klaster yang disimpan sebagai blok berurutan. Sebuah kueri menilai pusat klaster di memori, kemudian membaca hanya beberapa blok yang tampak menjanjikan sebagai bacaan berurutan besar alih-alih melakukan banyak lompatan acak. Kuantisasi biner, menggunakan metode RaBitQ, mengompresi setiap vektor menjadi sekitar satu bit per dimensi, kira-kira 32 kali lebih kecil daripada float32, sehingga kueri memindai kode kompak untuk membuat daftar pendek kandidat dan menata ulang hanya daftar pendek tersebut melawan vektor presisi penuh.

Karena desainnya tanpa status, ia dapat diskalakan hingga nol, dan saat tidak aktif pengguna hanya membayar penyimpanan. Databricks melaporkan P90 terukur sebesar 1,13 detik untuk kueri pertama setelah skala-ke-nol pada dataset 100 juta vektor berdimensi 768, dan mengatakan 100 juta vektor dapat dilayani pada satu Lakebase Compute Unit.

Konstruksi indeks melatih pusat klaster satu kali pada sampel acak kecil; setiap vektor kemudian ditetapkan ke pusat terdekat, dikuantisasi, dan ditulis ke blok yang sesuai sebagai operasi independen, sehingga pekerjaan tersebar ke sebanyak inti yang tersedia. Databricks menyatakan bahwa arsitektur LTAP‑nya memindahkan pembuatan indeks dari basis data utama ke mesin terdistribusi seperti Spark, memperpendek waktu pembuatan menjadi hitungan menit, dan menambahkan bahwa lebih banyak fitur akan datang terkait kemampuan tersebut. Karena predikat diterapkan selama pemindaian blok itu sendiri, kueri yang difilter menghindari pengambilan kandidat berlebih dan menjaga recall tetap tinggi, serta satu kueri diparalelkan di seluruh inti CPU.

Pencarian Teks BM25 dan Kueri Hibrida

Databricks menyatakan bahwa pencarian tsvector standar pada Postgres tidak memiliki konteks relevansi seluruh korpus. lakebase_text memberi skor pada istilah dengan menggunakan frekuensi dokumen terbalik global, memberikan bobot lebih tinggi pada istilah yang jarang dan berniat tinggi serta bobot lebih rendah pada kata pengisi yang umum. Ia juga memeriksa batas atas skor saat menelusuri indeks, membuang seluruh blok posting yang tidak dapat memengaruhi hasil top‑K, yang menurut perusahaan membuatnya lebih cepat dibandingkan tsvector dengan indeks GIN.

Menggabungkan kedua ekstensi memungkinkan pencarian hibrida native di dalam Postgres: satu kueri dapat menerapkan predikat filter SQL biasa, bergabung dengan tabel operasional langsung, dan menggabungkan penilaian vektor semantik dengan relevansi kata kunci BM25. Databricks menyatakan bahwa sistem ini dapat diskalakan dari satu baris hingga satu miliar vektor dan dari satu kueri per detik hingga ribuan kueri tanpa perlu reprovisi manual, menggambarkan desain ini ditujukan untuk agen AI yang alur kerjanya dapat memicu ribuan permintaan pengambilan secara bersamaan dalam hitungan detik.

Databricks memposisikan Lakebase Search untuk pengguna yang menginginkan data operasional dan pencarian terkonsolidasi dalam satu basis data, sementara Databricks AI Search tetap menjadi mesin terkelola untuk pengambilan yang siap pakai. Lakebase Search tersedia secara umum di AWS dan Azure; pengguna Lakebase yang ada dapat mengaktifkan ekstensi, dan pengguna baru dapat mendaftar untuk Lakebase.