Databricks, Lakebase Postgres에 전체 텍스트 및 벡터 검색을 도입

Databricks는 2026년 9월 28일에 Lakebase Search를 소개했다, 이는 Lakebase Postgres 데이터베이스용 내장 검색 엔진으로 두 가지 확장 기능을 통해 제공됩니다: lakebase벡터는 근사 최근접 이웃 검색 및 Lakebasetext는 BM25 전체 텍스트 검색을. 두 확장 기능은 AWS와 Azure에서 일반적으로 사용 가능합니다.

이 확장 기능을 사용하면 개발자가 운영 데이터와 함께 Postgres 내부에서 의미론적, 키워드 및 하이브리드 검색을 직접 실행할 수 있습니다. Databricks는 기존 OLTP 시스템이 낮은 지연 시간과 높은 정확도의 검색을 요구하고 대규모 병렬 검색을 자주 수행하는 AI 에이전트의 검색 요구에 맞게 설계되지 않았으며, 지금까지 이를 해결하려면 독립형 검색 엔진을 기본 데이터베이스에 ETL 파이프라인으로 연결해야 했다고 밝혔습니다. 회사는 수백 명의 베타 고객 피드백과 함께 Lakebase Search를 구축했다고 전했습니다.

벤치마크 결과 및 Conexiom 배포

Databricks는 lakebase_벡터가 VectorDBBench 100M 벤치마크(LAION 데이터셋 사용)에서 차선 시스템보다 두 배 높은 처리량을 제공하며, pgvector를 사용하는 클라우드 Postgres 공급업체보다 네 배 저렴하고, 자동 스케일링에 따른 추가 절감 효과가 있다고 밝혔습니다. 회사는 P99 지연 시간이 71밀리초이며 재현율 97%를 기록했다고 보고했으며, 이는 엔진이 실제 최근접 이웃을 97%의 비율로 성공적으로 검색했음을 의미합니다. 또한 pgvector와 DiskANN은 단일 대형 인스턴스에서만 테스트되었다고 언급했습니다.

Databricks는 또한 Conexiom의 고객 결과를 보고했는데, Conexiom은 이전 pgvector 설정 대비 절반 수준의 컴퓨팅 자원으로 1억 개 이상의 행에 대해 BM25 하이브리드 검색을 수행합니다. 회사에 따르면 Conexiom의 인프라 비용은 3배 감소했으며 처리량은 pgvector 대비 5배 증가했습니다.

“Lakebase Search는 pgvector에 비해 새로운 차원의 확장성을 제공하고, 동일한 서버리스 데이터베이스에서 BM25를 활용할 수 있게 해줍니다.” 라고 Conexiom의 AI/ML 아키텍트 Jordan Voves가 말했습니다. “우리는 Lakebase를 사용해 데이터를 에이전트와 대규모로 연결합니다.”

설계 뒤에 있는 Pgvector 제한 사항

Databricks는 pgvector가 Lakebase Postgres에서 가장 많이 설치된 확장 기능이며, 대규모로 운영하는 고객들에게서 관찰된 세 가지 반복적인 문제점을 설명했습니다.

첫 번째는 사용량이 아니라 데이터 양에 따라 비용이 증가한다는 점입니다. pgvector는 HNSW 인덱스를 데이터베이스 메모리에 유지하는데, HNSW 검색은 임의 접근 그래프 탐색에 의존하므로 인덱스가 디스크로 스필되면 성능이 10배에서 50배까지 감소하고 쿼리는 임의 읽기 체인으로 전환됩니다. 768 차원의 float32 벡터는 그래프 링크와 Postgres 오버헤드를 포함하면 약 3.3KB의 메모리를 차지하므로, 1억 행에 대한 인덱스는 약 330GB의 RAM을 상주하도록 전체 할당해야 하며, 쿼리가 접근 여부와 관계없이 프로비저닝됩니다.

두 번째는 인덱스 유지 관리입니다. Databricks에 따르면 빌드가 디스크로 스필될 경우 표준 클라우드 인스턴스에서 pgvector 인덱스를 구축하는 데 거의 50시간이 소요되었으며, 벡터 삽입이 임의 접근 탐색 및 여러 그래프 레이어 수정이 필요하기 때문에 쓰기 작업도 동일한 병목 현상을 겪습니다. HNSW는 전역 재균형이 없으므로 검색 품질을 회복하려면 전체 REINDEX를 실행해야 하며, 이는 테이블을 잠그고 프로덕션 쓰기를 중단합니다.

세 번째는 단일 쿼리를 병렬화할 수 없다는 점입니다. pgvector 쿼리는 하나의 Postgres 백엔드 프로세스에서 실행되므로 HNSW 인덱스 스캔에 병렬 처리가 전혀 적용되지 않습니다. 재현율을 높이려면 더 많은 그래프 노드를 방문해야 하는데, 이는 임의 메모리 읽기와 거리 비교를 추가해 지연 시간을 증가시키고 초당 처리 가능한 쿼리 수를 감소시킵니다. 따라서 처리량을 확장하려면 데이터베이스 연결이나 읽기 복제본을 추가해야 합니다.

Lakebase_vector 구축 방식

Lakebase Postgres는 스토리지를 컴퓨팅과 분리합니다. 영구 데이터는 저비용 클라우드 객체 스토리지에 저장되고, RAM 및 로컬 NVMe는 활성 작업 집합을 보관하는 단기 캐시 역할을 합니다. 이러한 기반 위에 Databricks는 두 가지 기술을 결합했습니다.

계층적 IVF 클러스터링은 벡터를 연속 블록으로 저장되는 클러스터로 그룹화합니다. 쿼리는 메모리 내에서 클러스터 중심점을 점수화한 뒤, 많은 무작위 접근 대신 대규모 순차 읽기로 유망해 보이는 소수의 블록만을 읽습니다. RaBitQ 방식을 이용한 이진 양자화는 각 벡터를 차원당 약 1비트로 압축하여 float32보다 약 32배 작게 만들며, 따라서 쿼리는 압축 코드를 스캔해 후보를 선별하고 그 후보군을 전체 정밀도 벡터와 재순위화합니다.

이 설계는 무상태(stateless)이므로 제로 스케일이 가능하고, 사용자는 저장소 비용만 지불합니다. Databricks는 1억 개 벡터, 768 차원 데이터셋에 대해 제로 스케일 후 첫 번째 쿼리의 측정된 P90이 1.13초였으며, 1개의 Lakebase Compute Unit으로 1억 개 벡터를 서비스할 수 있다고 보고했습니다.

인덱스 구축은 작은 무작위 샘플에 대해 클러스터 중심점을 한 번만 학습합니다; 각 벡터는 가장 가까운 중심점에 할당되고 양자화된 뒤 독립적인 작업으로 적절한 블록에 기록되어, 사용 가능한 코어 수에 따라 작업이 분산됩니다. Databricks는 자체 LTAP 아키텍처가 인덱스 빌드를 기본 데이터베이스에서 Spark와 같은 분산 엔진으로 오프로드하여 빌드 시간을 몇 분으로 단축시킨다고 밝혔으며, 해당 기능에 대해 추가 업데이트가 예정되어 있다고 말했습니다. 블록 스캔 중에 프레디케이트가 적용되기 때문에, 필터링된 쿼리는 후보를 과도하게 가져오는 것을 방지하고 재현율을 높게 유지하며, 단일 쿼리는 CPU 코어 전체에 병렬화됩니다.

BM25 텍스트 검색 및 하이브리드 쿼리

Databricks는 표준 Postgres tsvector 검색이 전체 코퍼스 수준의 관련성 컨텍스트를 제공하지 못한다고 밝혔습니다. lakebase_text는 전역 역문서 빈도(global inverse document frequency)를 사용해 용어에 점수를 매겨, 희귀하고 의도가 높은 용어에 더 큰 가중치를 부여하고 일반적인 불필요 단어에는 낮은 가중치를 부여합니다. 또한 인덱스를 탐색하면서 점수 상한을 확인하여 상위 K 결과에 영향을 줄 수 없는 전체 포스팅 블록을 폐기하는데, 이는 회사가 GIN 인덱스를 사용한 tsvector보다 더 빠르다고 말한 이유입니다.

두 확장을 결합하면 Postgres 내부에서 네이티브 하이브리드 검색이 가능해집니다. 단일 쿼리에서 일반 SQL 필터 프레디케이트를 적용하고, 실시간 운영 테이블을 조인하며, 의미 벡터 점수와 BM25 키워드 관련성을 병합할 수 있습니다. Databricks는 이 시스템이 한 행에서 10억 개의 벡터까지, 초당 한 쿼리에서 수천 개의 쿼리까지 수동 재프로비저닝 없이 확장된다고 밝히며, 설계가 수초 내에 수천 개의 동시 검색 요청을 트리거할 수 있는 워크플로를 가진 AI 에이전트를 위해 의도되었다고 설명했습니다.

Databricks는 운영 데이터와 검색 데이터를 하나의 데이터베이스에 통합하고자 하는 사용자를 위해 Lakebase Search를 제공하는 반면, Databricks AI Search는 즉시 사용할 수 있는 관리형 검색 엔진으로 남아 있습니다. Lakebase Search는 AWS와 Azure에서 일반적으로 제공되며, 기존 Lakebase 사용자는 확장을 활성화할 수 있고, 신규 사용자는 Lakebase에 가입할 수 있습니다.