Databricks Lakebase Search, 분리된 검색 스택에 도전
Databricks가 관리형 Postgres 서비스 안에 두 개의 검색 엔진을 탑재한 Databricks Lakebase Search를 AWS와 Azure에서 정식 출시했다. 9월 28일 공개된 이 기능은 별도의 검색 데이터베이스 없이 벡터 검색과 BM25 키워드 랭킹을 지원한다. 이는 Postgres가 운영 레코드를 보관하고, 다른 시스템이 검색을 위해 복제본을 인덱싱하는 익숙한 AI 아키텍처에 도전장을 던진다.
Databricks는 새 벡터 확장 기능이 1억 개 벡터를 97% 재현율과 71밀리초 P99 지연 시간으로 검색할 수 있다고 밝혔다. 또한 자체 벤치마크에서 차선의 시스템보다 두 배 높은 처리량과 pgvector를 실행하는 클라우드 Postgres보다 네 배 낮은 비용을 제공한다고 주장한다. 이 수치는 상당하지만, 테스트는 Databricks가 수행했으며 완전한 독립 검증 결과는 공개되지 않았다.
더 큰 이야기는 또 하나의 벡터 인덱스가 아니다. Databricks Lakebase Search는 운영용 Postgres가 에이전트 규모에서 시맨틱, 키워드, 하이브리드 검색을 처리하도록 만들려는 시도다. 이 아키텍처가 실제 프로덕션 워크로드에서 작동한다면, 일부 팀은 검색 서비스와 이를 둘러싼 데이터 파이프라인을 없앨 수 있다. 그 압력은 pgvector 배포 환경과 뛰어난 확장성을 근거로 복잡성을 정당화해 온 전용 검색 시스템 모두에 가해진다.
Databricks Lakebase Search, 검색을 Postgres로 가져오다
이번 출시는 검색을 부가 서비스에서 운영 데이터베이스의 관리형 기능으로 전환한다.
기술 발표는 두 가지 Postgres 확장 기능을 소개한다. lakebase_vector는 가능한 모든 레코드를 비교하지 않고 쿼리와 가까운 벡터를 찾는 근사 최근접 이웃 검색을 처리한다. lakebase_text는 컬렉션 전반의 용어 빈도, 문서 길이, 용어 희소성을 반영하는 랭킹 방식인 BM25를 제공한다.
두 확장 기능은 AWS와 Azure의 Lakebase 프로젝트에서 정식으로 제공된다. 개발자는 어느 한 확장 기능을 설치하거나, 하이브리드 검색을 위해 함께 사용할 수 있다. 벡터 검색과 키워드 검색은 서로 다른 실패 모드를 해결하기 때문에 이 조합은 중요하다.
벡터 검색은 의미를 수치화한 표현인 임베딩을 비교한다. 정확히 같은 단어가 없더라도 “fast sports car” 같은 쿼리를 자동차 모델을 언급하는 레코드와 연결할 수 있다. 반면 키워드 검색은 식별자, 이름, 오류 코드, 제품 번호처럼 문자 그대로의 형태가 의미를 지니는 용어에서 여전히 더 뛰어나다.
하이브리드 검색은 두 방식을 함께 실행하고 랭킹을 결합한다. AI 지원 에이전트는 시맨틱 유사도를 활용해 개념적으로 관련된 인시던트를 찾으면서도 특정 오류 코드의 정확한 일치를 유지할 수 있다. 이커머스 에이전트는 사용자가 요청한 모델 번호를 놓치지 않으면서 쇼핑객의 의도를 해석할 수 있다.
이 작업은 별도로 동기화된 복제본이 아니라 트랜잭션 레코드 옆에서 실행된다. 개발자는 테넌트, 재고 상태, 접근 권한, 워크플로 상태 같은 현재 필드를 사용해 검색 결과를 필터링할 수 있다. Databricks는 lakebase_vector가 인덱스 블록을 스캔하는 동안 필터를 적용하므로, 광범위한 후보 집합을 가져온 뒤 권한이 없거나 관련 없는 행을 나중에 버릴 필요를 줄인다고 설명한다.
이 설계는 검색 시스템에서 지속적으로 나타나는 문제를 겨냥한다. 레코드의 최신 버전은 흔히 애플리케이션 데이터베이스에 있지만, 검색 가능한 버전은 추출 파이프라인을 거쳐 나중에 도착한다. 짧은 지연만으로도 에이전트가 삭제된 문서, 오래된 권한 정보, 더는 존재하지 않는 재고를 보게 될 수 있다.
검색을 운영 데이터와 가깝게 유지하면 이러한 동기화 구간을 줄일 수 있다. 또한 엔지니어가 모니터링, 보안 관리, 복구해야 하는 시스템 수를 줄일 수 있다. 특히 접근 제어와 문서 변경 사항이 검색 결과와 일치해야 하는 검색 가능한 지식 베이스를 구축하는 팀에 관련성이 크다.
Lakebase Search가 모든 데이터 이동 단계를 없애는 것은 아니다. 임베딩은 여전히 생성해야 하고, 원본 콘텐츠는 Postgres 외부에서 비롯될 수 있으며, 레이크하우스 테이블은 제공 전에 동기화가 필요하다. 차이는 애플리케이션이 익숙한 Postgres 타입과 연산자를 통해 생성된 인덱스를 쿼리할 수 있다는 점이다.
Databricks는 이 기능을 더 넓은 레이크하우스 플랫폼과도 연결하고 있다. 제품 문서는 Unity Catalog 테이블을 Lakebase로 동기화하는 방법을 설명한다. 이 과정에서 임베딩 열은 Postgres 벡터가 되고, 원본 텍스트는 PostgreSQL의 텍스트 검색 최적화 표현인 tsvector가 될 수 있다.
따라서 즉각적인 변화는 구체적이다. Lakebase는 이제 의미 기반 검색과 정확한 용어 검색을 위한 네이티브 관리형 인덱스를 제공하며, 애플리케이션은 이를 운영 필드와 함께 쿼리할 수 있다. 긴장은 이 통합이 무엇을 대체하는지에서 시작된다.
AI 에이전트, 분리된 검색 파이프라인에 압박을 가하다
에이전트 워크로드는 동기화 오류와 유휴 인프라를 정당화하기 어렵게 만든다.
전통적인 검색 아키텍처는 대체로 최소 두 개의 데이터 저장소를 포함한다. Postgres는 트랜잭션과 애플리케이션 상태를 기록한다. 검색 엔진이나 벡터 데이터베이스는 추출, 변환, 적재 파이프라인을 통해 변환된 복제본을 받는다.
이 분리는 대규모 환경에서 잘 작동할 수 있지만, 운영상 의무를 만든다. 팀은 실패한 업데이트를 감지하고, 누락된 레코드를 재처리하며, 스키마 변경을 조율하고, 삭제 의미론을 보존하고, 다른 시스템 안에서 데이터베이스 권한을 재현해야 한다. 애플리케이션을 중단하지 않고 인덱스를 재구축할 계획도 필요하다.
AI 에이전트는 검색이 의사결정 루프의 일부가 되기 때문에 이러한 의무를 증폭시킨다. 일반적인 검색 페이지는 사용자가 대안을 검토하는 동안 완벽하지 않은 결과를 허용할 수 있다. 에이전트는 레코드를 검색한 직후 행동할 수 있으므로 최신성 및 권한 부여의 중요성이 더 커진다.
계정 관리 에이전트는 이 문제를 잘 보여준다. 이 에이전트는 회의록을 시맨틱 방식으로 검색하고, 정확한 계약 식별자를 매칭하며, 현재 사용자의 권한으로 결과를 필터링할 수 있다. 이 세 신호가 서로 다른 시스템에 있다면, 애플리케이션은 모델이 안전하게 응답하기 전에 이를 조정해야 한다.
상거래에서도 같은 문제가 나타난다. 쇼핑 에이전트는 임베딩을 통해 모호한 요청을 해석할 수 있지만, 재고 여부와 지역 제한은 빠르게 바뀌는 운영 열에서 나온다. 오래된 복제본을 검색하면 구매할 수 없는 상품에 대해 그럴듯한 답을 내놓을 수 있다.
급증하는 사용량도 또 다른 압박 요인이다. 사람을 위한 엔터프라이즈 검색은 대개 예측 가능한 업무 시간을 따른다. 에이전트는 작업을 계획하고, 검증하고, 수정하는 과정에서 많은 병렬 검색 호출을 생성할 수 있다. 한 번의 사용자 요청이 하나가 아니라 여러 번의 검색을 유발할 수 있다.
Databricks는 이러한 불균등한 수요를 중심으로 Lakebase Search를 설계했다. Lakebase는 내구성 있는 스토리지와 컴퓨팅을 분리해 데이터를 객체 스토리지에 보관하고, 메모리와 로컬 NVMe를 캐시로 사용한다. 검색 컴퓨팅은 유휴 상태일 때 중지됐다가 다른 쿼리가 도착하면 재개될 수 있다.
Databricks는 768차원의 벡터 1억 개를 담은 인덱스에서 스케일 투 제로 이후 첫 쿼리의 P90 지연 시간이 1.13초라고 보고했다. 또한 같은 컬렉션을 하나의 Lakebase Compute Unit으로 제공할 수 있다고 밝혔다. 이는 보편적인 기대치가 아니라 회사 측정치이지만, 의도한 운영 모델을 보여준다.
1초의 콜드 쿼리는 모든 인터랙티브 애플리케이션에 적합하지는 않다. 하지만 대규모 검색 클러스터를 계속 실행하지 않아도 된다면, 드물게 사용되는 내부 에이전트에는 허용될 수 있다. 팀은 지연 시간이 중요할 때 컴퓨팅을 활성 상태로 유지하고, 조용한 환경에서는 중지되도록 할 수 있다.
인덱스 구축도 기본 트랜잭션 경로에서 벗어난다. Databricks는 샘플에서 중심점을 학습하고, 벡터 할당과 양자화를 분산 처리한 다음, 독립적인 인덱스 블록을 작성할 수 있다고 설명한다. Spark 같은 분산 엔진으로의 향후 오프로드는 회사가 지향하는 방향의 일부지만, 발표문은 이 더 폭넓은 기능을 기다려 달라고 언급한다.
이는 대규모 인덱스 빌드가 같은 프로세서, 메모리, 스토리지 리소스를 소비할 경우 트랜잭션 워크로드와 경쟁하기 때문에 중요하다. 이 작업을 기본 데이터베이스에서 분리하면 간섭을 줄일 수 있다. 또한 비용 모델을 영구적으로 프로비저닝된 인덱스 서버 유지에서 활성 검색 컴퓨팅과 내구성 있는 스토리지에 비용을 지불하는 방식으로 바꾼다.
압박의 대상이 모든 전용 검색 배포 환경은 아니다. 대규모 검색 팀은 특수 분석기, 맞춤 랭킹 파이프라인, 고급 관측성, 또는 수년간 개발된 기능을 필요로 하는 경우가 많다. Lakebase가 압박하는 것은 Postgres 검색이 편안하게 확장되지 못한다는 이유만으로 두 번째 시스템이 존재하는 일반적인 아키텍처다.
이 구분은 발표를 현실에 맞게 유지한다. Databricks는 하나의 데이터베이스가 모든 검색 워크로드를 수행해야 한다고 주장하지 않는다. 대신 더 많은 AI 애플리케이션이 분리를 미루거나, 단순화하거나, 피할 수 있다고 주장한다.
Lakebase Vector Search, pgvector의 메모리 모델을 겨냥하다
핵심 경쟁 구도는 대규모 환경에서 스토리지 기반 Lakebase Search와 메모리 집약적인 pgvector 인덱스의 대결이다.
Pgvector는 Postgres를 시맨틱 검색의 실용적인 출발점으로 만들었다. 개발자가 익숙하지 않은 데이터베이스 인터페이스로 이동하지 않고도 벡터 타입, 거리 연산자, 정확 검색, 근사 인덱스를 추가할 수 있다. 여전히 오픈 소스이며 호스팅형 Postgres 서비스 전반에서 널리 제공된다.
표준 근사 검색 옵션에는 HNSW와 IVFFlat이 포함된다. HNSW는 가까운 벡터를 연결하는 다층 그래프를 만든다. 속도와 재현율의 균형이 좋지만, 그래프 구축에는 시간이 걸리고 인덱스는 상당한 메모리를 소비한다. IVFFlat은 벡터를 리스트로 묶고 가장 유망한 그룹을 검색해 메모리와 구축 비용을 줄이지만, 일반적으로 쿼리 성능은 더 낮다.
프로젝트의 자체 pgvector 가이드는 이러한 상충 관계를 문서화한다. HNSW 인덱스는 그래프가 maintenance_work_mem에 들어갈 때 훨씬 빠르게 구축된다고 명시한다. 또한 검색 후보를 늘리면 쿼리 속도를 희생하는 대신 재현율이 향상된다고 경고한다.
Databricks는 HNSW 그래프가 한 시스템의 메모리를 넘어 커질 때 이러한 제약이 더 어려워진다고 주장한다. 원격 객체 스토리지에서 그래프 노드 체인을 가져오면 작고 무작위적인 읽기가 많이 발생할 수 있다. 상주 메모리에 최적화된 설계는 작업 집합이 콜드 상태일 때 효율이 떨어진다.
Lakebase 벡터 검색은 계층형 역파일 클러스터링을 사용해 이러한 접근 패턴을 바꾼다. 벡터는 연속된 블록으로 그룹화된다. 쿼리는 먼저 클러스터 중심점을 평가한 뒤, 가장 유망한 클러스터와 연결된 블록을 읽는다.
이 확장 기능은 초기 후보 점수 산정을 위해 각 벡터를 차원당 약 1비트로 압축하는 RaBitQ 이진 양자화를 이 레이아웃과 결합한다. Databricks는 이 표현이 표준 32비트 부동소수점 벡터보다 약 32배 작다고 설명한다. 이후 시스템은 전체 정밀도 벡터를 사용해 제한된 후보 집합의 순위를 다시 매긴다.
이 메커니즘은 인덱스를 객체 스토리지와 로컬 캐싱 모두에 더 적합하게 만든다. 콜드 쿼리는 수백 개의 그래프 링크를 따라가는 대신 관련 블록 여러 개를 읽는다. 웜 쿼리는 더 작은 활성 메모리 풋프린트를 유지하면서 압축된 이진 코드를 스캔할 수 있다.
Databricks는 단일 lakebase_ann 인덱스에 10억 개 이상의 벡터를 담을 수 있다고 말합니다. 문서에서는 인덱스 구축 속도도 HNSW보다 50~100배 빠르다고 주장합니다. 이 수치는 회사의 구현 방식을 설명하는 것이며, 모든 스키마, 임베딩 모델 또는 필터 분포에 자동으로 적용해서는 안 됩니다.
대표 벤치마크는 LAION 데이터셋의 벡터 1억 개를 사용했습니다. Databricks에 따르면 Lakebase는 테스트된 차상위 시스템보다 두 배 높은 처리량을 제공했습니다. 또한 P99 71밀리초에서 97% 재현율을 기록했다고 보고했는데, 이는 측정된 쿼리의 99%가 해당 지연 시간 내에 완료되면서 명시된 비율로 실제 이웃을 검색했다는 의미입니다.
이 벤치마크는 pgvector를 사용하는 이름이 공개되지 않은 클라우드 Postgres 공급업체와 비교해 비용이 4분의 1 수준이라는 주장도 내놓았습니다. Databricks는 pgvector와 DiskANN이 단일 대형 인스턴스에서 테스트됐다고 언급합니다. 아키텍처, 구성, 하드웨어, 동시성 및 가격 가정에 따라 결과가 크게 달라질 수 있으므로, 이 단서는 비교의 범위를 제한합니다.
벤치마크는 특정 접근 방식이 평가할 가치가 있음을 보여줄 수는 있지만 구매 결정을 대신해 주지는 않습니다. Databricks는 모든 pgvector 워크로드가 마이그레이션해야 한다는 점을 입증하지 않았습니다. 더 작은 인덱스는 메모리에 무리 없이 들어갈 수 있으며, 기존 pgvector 설치는 저렴하고 이식성이 높으며 운영하기 쉬울 수 있습니다.
Pgvector는 바이너리 양자화, 반정밀도 인덱싱, 반복 스캔, 파티셔닝 및 구성 가능한 검색 노력도 지원합니다. 이미 배포를 튜닝한 팀은 단순한 기준선 차트가 시사하는 것보다 더 많은 선택지를 갖고 있습니다. 오픈소스 확장 프로그램은 여러 Postgres 환경에서 작동하는 반면, Lakebase Search는 관리형 Databricks 서비스에 속합니다.
다만 호환성은 마이그레이션 비용을 낮춥니다. Databricks는 lakebase_vector가 pgvector의 벡터 유형, 거리 연산자 및 쿼리 구문을 사용한다고 말합니다. 애플리케이션은 익숙한 SQL을 유지하면서 HNSW 또는 IVFFlat 인덱스 대신 lakebase_ann 인덱스를 만들 수 있습니다.
이는 의도적인 경쟁 전략입니다. Databricks는 개발자에게 pgvector 프로그래밍 모델을 포기하라고 요구하지 않습니다. 거의 동일한 인터페이스 아래에 다른 스토리지 및 인덱싱 엔진을 제공하는 것입니다.
고객 사례는 하나의 실질적 신호를 제공합니다. Conexiom은 이전 pgvector 구성의 절반 수준 컴퓨팅 사용량으로 1억 행이 넘는 데이터에 대해 하이브리드 BM25 검색을 실행한다고 Databricks에 전했습니다. 이 사례는 운영 워크로드를 설명한다는 점에서 유용하지만, 독립적으로 공개된 방법론이 없는 공급업체 선정 고객의 진술이라는 한계가 남습니다.
Lakebase 벡터 검색의 근거는 컬렉션 규모가 크고, 쿼리 수요가 불규칙하며, 운영상 필터가 중요할 때 가장 강합니다. 팀이 인프라 이식성을 우선시하거나, 항상 켜진 수요가 예측 가능하거나, 이미 pgvector로 지연 시간 목표를 달성하고 있다면 그 근거는 약해집니다.
네이티브 BM25가 전문 검색의 판도를 바꾼다
이번 릴리스에서 더 조용한 부분이 벡터 벤치마크보다 더 중요할 수 있습니다.
많은 AI 검색 제품은 임베딩을 과도하게 강조합니다. 시맨틱 매칭은 사용자와 문서가 서로 다른 단어로 같은 개념을 표현할 때 도움이 됩니다. 하지만 쿼리에 임베딩 모델이 약하거나 낯선 신호로 취급하는 정확한 식별자가 포함되면 신뢰성이 떨어집니다.
에이전트가 “CVE-2026-1234”, 고객 계정 번호 또는 특정 컴포넌트 이름을 검색하는 상황을 생각해 보겠습니다. 유사도 검색은 개념적으로 관련된 레코드를 반환하면서도 정확한 문자열의 중요성을 놓칠 수 있습니다. 키워드 랭킹은 리터럴 일치를 보존하는 별도의 검색 신호를 제공합니다.
Lakebase의 lakebase_text 확장 프로그램은 PostgreSQL tsvector 값 및 텍스트 쿼리 연산자와 호환되는 lakebase_bm25 인덱스를 추가합니다. BM25는 컬렉션 전체의 용어 빈도와 문서 길이를 반영해, 희귀 용어가 일반 용어보다 더 크게 기여하도록 돕습니다.
PostgreSQL은 이미 상당한 전문 검색 기능을 제공합니다. 문서를 파싱하고, 단어를 정규화하며, 불용어를 제거하고, GIN 인덱스를 구축하며, ts_rank 또는 ts_rank_cd로 결과 순위를 매길 수 있습니다. 공식 랭킹 문서는 내장 랭킹 함수가 어휘 빈도, 근접성 및 구조적 정보를 사용한다고 설명합니다.
이 함수들은 BM25와 같은 방식으로 전역 컬렉션 통계를 사용하지 않습니다. 제품에 단순 매칭이 아니라 검색 엔진 수준의 관련성이 필요할 때 이 차이가 중요해집니다. 팀들은 역사적으로 맞춤형 랭킹 로직을 추가하거나 텍스트를 전용 엔진으로 옮겨 왔습니다.
Databricks는 lakebase_text가 상위 K 검색에 Block-Max WAND를 사용한다고 말합니다. 이 알고리즘은 현재 최고 점수와 경쟁할 수 있는 결과를 만들 수 없는 영역을 건너뜁니다. 일치하는 모든 문서에 완전한 점수를 매기는 대신, 엔진은 요청된 결과 집합에 들어갈 수 있는 후보에 작업을 집중합니다.
이 접근 방식은 벡터 검색을 보완합니다. 지원 쿼리는 정확한 오류 텍스트를 위해 lakebase_bm25를 대상으로 실행하고, 의미적으로 유사한 인시던트 설명을 위해 lakebase_ann을 대상으로 실행할 수 있습니다. 이후 상호 순위 융합은 원시 점수가 같은 척도를 공유한다고 가정하지 않고 두 정렬 목록을 결합할 수 있습니다.
이 지점에서 Databricks Lakebase Search는 단순히 더 빠른 벡터 인덱스를 넘어섭니다. 동일한 데이터베이스 안에 서로 다른 두 검색 모델을 갖춘 검색 스택을 제공합니다. 운영 행, 임베딩, 텍스트 표현 및 필터링 속성을 한곳에 유지할 수 있습니다.
이러한 통합은 편의성만큼이나 보안에도 영향을 줍니다. 애플리케이션은 검색과 함께 테넌트 경계 및 권한 검사를 SQL 조건으로 표현할 수 있습니다. 엔지니어는 여전히 모든 인덱스 경로가 필터를 올바르게 적용하는지 테스트해야 하지만, 별도 서비스에서 전체 권한 부여 모델을 다시 만들 필요는 없습니다.
쓰기 동작도 단순해집니다. 새로 삽입된 레코드는 두 번째 데이터베이스가 이벤트를 확인할 때까지 기다리지 않고 검색 가능해질 수 있습니다. 업데이트와 삭제는 익숙한 트랜잭션 환경 안에 남지만, 인덱스 유지보수 시점과 동기화된 레이크하우스 소스는 여전히 측정이 필요합니다.
전용 엔진은 중요한 장점을 유지합니다. Elasticsearch 및 유사 시스템은 광범위한 언어 분석, 맞춤형 스코어링, 집계, 하이라이팅, 쿼리 도구 및 검색을 위해 특별히 개발된 운영 제어 기능을 지원합니다. Lakebase의 BM25 지원이 이러한 차이를 없애지는 않습니다.
따라서 의미 있는 비교는 아키텍처 차원에서 이뤄집니다. 애플리케이션에 시맨틱 검색, 정확한 용어 랭킹, 최신 운영 필터 및 일반 SQL이 필요하다면 Lakebase는 더 많은 워크로드를 한곳에서 처리할 수 있습니다. 검색 자체가 제품이라면 전문 기능이 여전히 별도 시스템을 정당화할 수 있습니다.
벤치마크는 프로덕션 질문에 답하지 못한다
Databricks는 매력적인 메커니즘을 제시했지만, 구매자는 여전히 워크로드별 증거가 필요합니다.
가장 큰 불확실성은 벤치마크의 독립성입니다. Databricks는 공개 비교의 기반이 된 시스템, 구성, 데이터셋, 인스턴스 형태 및 비용 가정을 선택했습니다. 회사는 VectorDBBench와 LAION 1억 데이터셋을 명시하지만, 발표문만으로는 모든 결과를 재현하기에 충분한 세부 정보를 제공하지 않습니다.
재현율과 지연 시간도 상호작용합니다. 근사 검색은 의도적으로 완전 탐색을 피하므로, 엔지니어는 쿼리가 검사하는 클러스터 또는 후보의 수를 조정합니다. 더 높은 재현율에는 흔히 더 많은 작업이 필요합니다. 단일 성능 지점으로는 서로 다른 목표 재현율 수준에 걸친 전체 곡선을 설명할 수 없습니다.
필터링은 이 곡선을 다시 바꿀 수 있습니다. 실제 비즈니스 쿼리는 테넌트, 지역, 시간, 재고 상태 또는 권한에 따라 결과를 제한할 수 있습니다. 균일하게 분포된 벤치마크가 매우 선택적이거나 불균등한 프로덕션 필터를 반드시 대표하는 것은 아닙니다.
데이터 형태도 중요합니다. LAION의 이미지 임베딩은 엔터프라이즈 문서 임베딩, 제품 카탈로그, 소스 코드 또는 고객 레코드와 다릅니다. 차원 수는 달라지고, 중복이 나타나며, 업데이트는 불균등하게 도착하고, 일부 테넌트가 트래픽을 지배합니다. 각 요인은 캐시 동작과 인덱스 품질에 영향을 줄 수 있습니다.
콜드 스타트 성능은 신중하게 해석할 필요가 있습니다. 보고된 P90 1.13초는 특정 1억 벡터, 768차원 구성에 적용됩니다. 엄격한 인터랙티브 목표를 가진 애플리케이션은 scale-to-zero보다 활성 컴퓨팅이 필요할 수 있습니다. 팀은 첫 번째 쿼리와 그 뒤의 버스트를 모두 테스트해야 합니다.
운영상 제약도 주의가 필요합니다. 문서에 따르면 Lakebase Search를 활성화하면 프로젝트의 모든 컴퓨팅 리소스가 재시작되고, 활성 연결이 끊기며, 되돌릴 수 없습니다. 따라서 활성화는 무해한 확장 프로그램 토글이 아니라 계획된 인프라 변경입니다.
이식성도 또 다른 트레이드오프입니다. Lakebase는 표준 Postgres 유형과 익숙한 pgvector 구문을 제공하지만, 새로운 인덱스 액세스 방식은 독점적인 관리형 기능입니다. 팀은 애플리케이션 SQL의 상당 부분을 유지할 수 있지만, 인덱스 동작, 확장 및 가격 측면에서는 Databricks에 의존하게 됩니다.
BM25에도 같은 우려가 적용됩니다. 표준 tsvector 열은 알아볼 수 있는 Postgres 객체로 남지만, lakebase_bm25 인덱스와 그 실행 특성은 Lakebase에 특화돼 있습니다. 다른 환경으로 이전하려면 인덱스를 다시 구축하고 다른 곳에서 랭킹 품질을 재테스트해야 할 수 있습니다.
비용 주장은 직접 측정해야 합니다. 서버리스 일시 중지는 불규칙한 사용의 비용을 낮출 수 있지만, 지속적인 높은 동시성에서는 다른 모델이 더 유리할 수 있습니다. 임베딩 생성, 동기화된 테이블, 스토리지, 데이터 전송 및 주변 Databricks 서비스가 전체 아키텍처 비용에 기여합니다.
따라서 팀은 일반적인 리더보드가 아니라 대표적인 질문으로 Lakebase Search를 평가해야 합니다. 유용한 테스트 코퍼스에는 현재 레코드, 삭제된 레코드, 액세스 제어 문서, 희귀 식별자, 모호한 자연어 쿼리 및 재현율을 가장 낮출 가능성이 큰 필터가 포함됩니다.
운영 결과도 비교해야 합니다. 데이터 최신성, 장애 복구, 인덱스 구축 영향, 권한 일관성 및 파이프라인 관리에 필요한 인력 시간을 측정해야 합니다. 원시 쿼리 지연 시간이 거의 변하지 않더라도 외부 서비스를 제거하는 것은 가치가 있을 수 있습니다.
이 질문들 중 어느 것도 이번 릴리스를 무효화하지 않습니다. 이는 공급업체 벤치마크 밖에서 “최첨단”이 무엇을 의미해야 하는지를 정의합니다. 이 아키텍처에는 신뢰할 만한 기술적 근거가 있지만, 프로덕션 증거는 그 장점이 각 구매자의 데이터 분포와 워크로드에서도 유지되는지 보여줘야 합니다.
Lakebase Search가 GA에 도달한 뒤 주목할 점
Lakebase Search가 기본 Postgres 기능이 될지, Databricks 특화 옵션으로 남을지를 세 가지 신호가 결정할 것입니다.
첫 번째 신호는 재현 가능한 성능입니다. 독립적인 테스트는 여러 재현율 목표에서 Lakebase를 튜닝된 pgvector, DiskANN 기반 서비스 및 전용 검색 엔진과 비교해야 합니다. 인스턴스 사양, 동시성, 필터 선택도, 캐시 상태, 인덱스 구축 시간 및 완전한 비용 가정을 공개해야 합니다.
결과가 Databricks의 주장에 근접한다면, 스토리지 기반 클러스터형 인덱스가 메모리 중심 그래프보다 대규모 서버리스 컬렉션에 더 적합하다는 주장을 강화할 것입니다. 통합이 여전히 운영상 이점을 제공하더라도, 큰 격차는 성능 서사를 약화시킬 것입니다.
두 번째 신호는 두 시스템 아키텍처를 대체하는 팀들 사이의 도입입니다. Conexiom은 초기 사례를 제공하지만, 시장에는 프로덕션 규모, 업데이트 빈도, 쿼리 볼륨 및 권한 모델을 설명하는 더 많은 사례가 필요합니다. 가장 설득력 있는 이야기는 단순한 성공적 시연이 아니라 제거된 검색 클러스터 또는 ETL 파이프라인을 기록할 것입니다.
도입은 익숙한 Postgres 구문이 마이그레이션 마찰을 줄이는지도 보여줄 것입니다. 팀이 데이터 모델과 쿼리를 유지하면서 인덱스 정의를 바꿀 수 있다면, Lakebase Search는 기존 애플리케이션에 진입할 실용적인 경로를 갖게 됩니다. 마이그레이션에 광범위한 랭킹 변경이 필요하다면 호환성 주장은 설득력을 덜 갖게 될 것입니다.
세 번째 신호는 경쟁사의 대응이다. Pgvector는 양자화, 필터링, 반복 스캔을 위한 옵션을 계속 추가하고 있다. 관리형 Postgres 벤더는 스토리지 아키텍처를 개선하거나 자체 검색 확장을 도입할 수 있다. 전용 검색 제공업체는 성숙한 랭킹 제어 기능, 배포 유연성, 하이브리드 검색 기능을 강조할 수 있다.
Databricks는 2025년 출시 발표에서 Lakebase를 AI 애플리케이션용 관리형 Postgres로 포지셔닝하기 시작했다. 이번 릴리스는 그 포지셔닝을 더욱 구체화한다. 모든 본격적인 검색 쿼리가 여전히 시스템을 벗어나야 한다면, 트랜잭션 기능만으로는 데이터베이스가 에이전트에 적합하다고 할 수 없다.
당장의 핵심은 더 좁지만 더 유용하다. Databricks Lakebase Search는 개발자에게 운영 레코드, 벡터 유사도, BM25 랭킹, SQL 필터링을 한곳에서 제공한다. 클러스터링 및 양자화된 벡터 인덱스는 대규모 pgvector 배포를 제약하는 메모리 모델을 직접 겨냥한다.
다음 결정은 엔지니어링 팀의 몫이다. 대표적인 검색 테스트를 구축하고, 콜드 및 웜 트래픽을 포함하며, 실제 권한 필터를 적용한 뒤 전체 운영 부담을 비교해야 한다. Lakebase가 관련성을 유지하면서 동기화 인프라를 제거한다면, 아키텍처 단순화의 가치는 어떤 개별 벤치마크 수치보다 중요해질 것이다.
