Databricks додає повнотекстовий та векторний пошук до Lakebase Postgres

Databricks 28 вересня 2026 року представив Lakebase Search, вбудований механізм пошуку для його бази даних Lakebase Postgres, що постачається через два розширення: lakebaseвектор для пошуку приблизних найближчих сусідів і lakebasetext для повнотекстового пошуку BM25. Обидва розширення загальнодоступні в AWS та Azure.

Розширення дозволяють розробникам виконувати семантичний, ключовий та гібридний пошук безпосередньо в Postgres поряд з операційними даними. Databricks зазначив, що традиційні системи OLTP не створені для вимог пошуку AI‑агентів, які потребують низької затримки, високої точності отримання результатів і часто виконують масштабні паралельні пошуки, і що до цього часу їх вирішення означало підключення окремого механізму пошуку до основної бази даних за допомогою ETL‑конвеєра. Компанія повідомила, що створила Lakebase Search, враховуючи відгуки сотень бета‑клієнтів.

Результати бенчмарків та розгортання Conexiom

Databricks заявив, що lakebase_вектор забезпечує вдвічі більшу пропускну здатність, ніж наступна краща система у бенчмарку VectorDBBench 100M, який використовує набір даних LAION, і що він у чотири рази дешевший, ніж постачальник хмарного Postgres, що використовує pgvector, не враховуючи додаткових заощаджень від автмасштабування. Компанія повідомила про P99 затримку 71 мілісекунду при 97 % recall, що означає, що механізм успішно знаходив справжніх найближчих сусідів у 97 % випадків, і зазначила, що pgvector і DiskANN тестувалися лише на одному великому інстансі.

Databricks також повідомив про результат клієнта Conexiom, який виконує гібридний пошук BM25 понад 100 мільйонів рядків при вдвічі меншому обчислювальному навантаженні порівняно з його попередньою конфігурацією pgvector. За словами компанії, витрати Conexiom на інфраструктуру знизилися втричі, а пропускна здатність зросла в п’ять разів у порівнянні з pgvector.

“Lakebase Search надає нам абсолютно новий рівень масштабованості порівняно з pgvector і відкриває BM25 у тому ж безсерверному базі даних,” сказав Джордан Вовес, архітектор AI/ML у Conexiom. “Ми використовуємо Lakebase для підключення даних до наших агентів у масштабі.”

Обмеження pgvector, що лежать в основі дизайну

Databricks зазначив, що pgvector є найчастіше встановленим розширенням у Lakebase Postgres, і описав три постійні проблеми, які спостерігаються у клієнтів при його масштабному використанні.

Перша — це вартість, яка зростає пропорційно обсягу даних, а не використанню. pgvector зберігає свій індекс HNSW у пам’яті бази даних, і оскільки пошук HNSW покладається на випадковий доступ до графу, продуктивність падає в 10‑50 разів, коли індекс переходить на диск і запити перетворюються на ланцюги випадкових читань. Вектор розмірністю 768 у форматі float32 займає близько 3,3 кілобайта пам’яті з урахуванням зв’язків графу та накладних витрат Postgres, тому індекс понад 100 мільйонів рядків потребує приблизно 330 гігабайт ОЗУ, які залишаються резидентними, повністю виділеними незалежно від того, чи звертаються до них запити.

Друга — це обслуговування індексу. Коли побудова індексу перейшла на диск, індекс pgvector зайняв майже 50 годин на створення на стандартному хмарному інстансі, повідомив Databricks, і запису також страждає від того ж вузького місця, оскільки вставка вектора вимагає випадкового обходу та модифікації кількох шарів графу. Оскільки у HNSW немає глобального перебалансування, відновлення якості пошуку означає запуск повного REINDEX, операції, що блокує таблицю та зупиняє продуктивні записи.

Третя — це те, що один запит не може бути паралелізований. Запит pgvector виконується одним процесом бекенду Postgres, залишаючи сканування індексу HNSW без будь‑якої паралелізації. Підвищення recall вимагає відвідування більшої кількості вузлів графу, що додає випадкові читання пам’яті та порівняння відстаней, збільшуючи затримку та зменшуючи кількість запитів за секунду, тому масштабування пропускної здатності означає додавання з’єднань з базою даних або реплік читання.

Як створюється Lakebase_vector

Lakebase Postgres розділяє сховище та обчислення: постійні дані розташовані в недорогому хмарному об’єктному сховищі, тоді як ОЗУ та локальний NVMe слугують короткоживучими кешами, що утримують активний робочий набір. На цій основі Databricks поєднав два підходи.

Ієрархічне кластеризація IVF групує вектори у кластери, що зберігаються як суцільні блоки. Запит оцінює центроїди кластерів у пам’яті, а потім читає лише кілька блоків, які виглядають перспективними, як великі послідовні зчитування замість багатьох випадкових переходів. Бінарна квантизація за допомогою методу RaBitQ стискає кожен вектор до приблизно одного біту на вимір, що приблизно в 32 рази менше, ніж float32, тому запити сканують компактні коди, щоб сформувати короткий список кандидатів і переоцінювати лише цей список проти векторів повної точності.

Оскільки дизайн без стану, він масштабується до нуля, і в стані спокою користувачі сплачують лише за сховище. Databricks повідомив виміряний P90 у 1,13 секунди для першого запиту після масштабування до нуля на наборі даних з 100 мільйонами векторів, розмірністю 768, і зазначив, що 100 мільйонів векторів можна обслуговувати на одному Lakebase Compute Unit.

Побудова індексу навчає центроїди кластеру один раз на невеликій випадковій вибірці; кожний вектор потім призначається до найближчого центроїда, квантується та записується у відповідний блок як незалежна операція, тому робота розподіляється на стільки ядер, скільки доступно. Databricks заявив, що його архітектура LTAP переносить створення індексів з основної бази даних на розподілені движки, такі як Spark, скорочуючи час побудови до хвилин, і повідомив, що попереду ще більше функціоналу. Оскільки предикати застосовуються під час сканування блоку, відфільтровані запити уникають надмірного отримання кандидатів і зберігають високий рівень відновлення, а один запит паралелізується на ядра CPU.

Текстовий пошук BM25 та гібридні запити

Databricks зазначив, що стандартний пошук tsvector у Postgres не має контексту релевантності на рівні всього корпусу. lakebase_text оцінює терміни, використовуючи глобальну зворотну частоту документів, надаючи більшу вагу рідкісним, високонамірам термінам і меншу — поширеним заповнювальним словам. Він також перевіряє верхні межі оцінки під час обходу індексу, відкидаючи цілі блоки постингів, які не можуть вплинути на результат топ‑K, що, за словами компанії, робить його швидшим за tsvector з індексами GIN.

Комбінація цих двох розширень забезпечує нативний гібридний пошук у Postgres: один запит може застосовувати звичайні SQL‑фільтри, об’єднувати живі операційні таблиці та поєднувати семантичне оцінювання векторів з релевантністю ключових слів BM25. Databricks зазначив, що система масштабується від одного рядка до мільярда векторів і від одного запиту в секунду до тисяч без ручного перепризначення ресурсів, описуючи дизайн як орієнтований на AI‑агентів, чий робочий процес може генерувати тисячі одночасних запитів на отримання даних за секунди.

Databricks позиціонує Lakebase Search для користувачів, які бажають консолідувати операційні та пошукові дані в одній базі даних, тоді як Databricks AI Search залишається його керованим рушієм для пошуку, який працює одразу після запуску. Lakebase Search загальнодоступний на AWS та Azure; існуючі користувачі Lakebase можуть увімкнути розширення, а нові користувачі можуть зареєструватися в Lakebase.