Databricks, Lakebase Postgres Compute Cache 개선… 진짜 시험대는 Autoscaling

Databricks가 프로덕션 측정에서 처리량을 최대 두 배까지 높인 새 구성으로 Lakebase Postgres compute cache 성능을 개선하고 있다. 이 변경 사항은 이미 80 compute units 이상을 갖춘 고정 크기 Databricks compute에서 활성화됐다. 그러나 더 어려운 문제는 아직 해결되지 않았다. Postgres가 실행 중인 상태에서 확장·축소되는 compute에도 동일한 메모리 전략을 적용하는 일이다.

이번 업데이트는 자주 요청되는 데이터베이스 페이지가 머무르는 위치를 바꾼다. 대형 고정 크기 compute는 이제 사용 가능한 메모리의 최대 75%를 Postgres shared buffers에 할당한다. 이 버퍼는 데이터베이스 엔진에서 가장 빠른 인메모리 캐시다. Databricks는 운영체제 내부의 주소 변환 작업을 줄이기 위해 이 메모리를 2 MB huge pages로 지원한다.

이 조합은 분리형 데이터베이스의 핵심적인 긴장을 겨냥한다. 영속 스토리지와 compute를 분리하면 빠른 재시작, 독립적인 확장, 저렴한 object storage가 가능하다. 하지만 실행 중인 쿼리와 필요한 데이터 사이의 거리도 더 멀어진다. Amazon Aurora, AlloyDB 등 다른 클라우드 데이터베이스도 이 문제의 변형에 직면하지만, Databricks는 Lakebase 아래의 Neon 아키텍처에 이 해결책을 적용하고 있다.

Lakebase Postgres Compute Cache 개선은 고정 Compute에서 시작된다

Databricks는 Lakebase cache의 가장 뜨거운 부분을 로컬 디스크에서 Postgres 메모리로 옮겼지만, 충분히 큰 고정 크기 머신에서만 적용된다.

이 변경 사항은 2026년 9월 9일 공개됐다. 회사의 compute cache 업데이트에 따르면, 80 compute units 이상을 갖춘 고정 크기 Lakebase compute에서 활성화돼 있다. Neon의 동등한 배포 범위는 18 compute units 이상을 갖춘 고정 compute다.

Lakebase는 분리형 스토리지를 사용한다. 즉, Postgres compute와 영속 데이터 스토리지가 별도의 계층으로 작동한다. Compute 노드는 데이터베이스 엔진을 실행하지만 데이터의 권위 있는 복사본을 보유하지는 않는다. 이 설계 덕분에 운영자는 전체 데이터베이스를 옮기지 않고도 compute를 교체, 재시작 또는 크기 조정할 수 있다.

읽기는 계층 구조를 거친다. Postgres는 먼저 DRAM의 shared buffers를 확인한다. 페이지가 없다면 이전 구성은 compute 노드의 NVMe 드라이브에 저장된 로컬 file cache를 확인한다. 여기에서도 누락되면 요청은 분산 스토리지 계층으로 전달되고, pageserver가 데이터베이스 페이지를 재구성해 반환한다.

이 로컬 file cache는 초기의 중요한 문제를 해결했다. 표준 Postgres 설치 환경은 일반적으로 shared buffers와 운영체제 page cache의 이점을 모두 누린다. Lakebase는 원격 페이지 읽기를 전통적인 로컬 파일시스템으로 라우팅하지 않기 때문에, 일반적인 두 번째 계층에 의존할 수 없다.

따라서 Databricks와 Neon은 로컬 file cache를 탄력적인 대체 수단으로 구축했다. 이는 정적인 Postgres buffer 할당을 넘어선 용량을 차지할 수 있었고 serverless compute에 맞춰 조정될 수 있었다. 이 구성은 Postgres가 실행 중에 shared buffers 크기를 조정하지 않아도 autoscaling을 지원했다.

하지만 이전 구성은 shared buffers를 약 1 GB로 제한했다. DRAM의 최대 75%에 이를 수 있는 나머지 compute-cache 용량 대부분은 로컬 file cache에 할당됐다. 대형 머신에서는 이 균형 때문에 캐시할 수 있었던 많은 읽기 요청이 메모리 대신 NVMe를 거쳤다.

새 고정-compute 구성은 해당 경로에서 로컬 file cache를 제거한다. DRAM의 75%를 shared buffers에 할당해 훨씬 더 큰 working set을 Postgres 내부에 유지한다. 발표에 따르면 관리자가 show shared_buffers를 실행하면 80-unit Databricks endpoint는 120 GB를 표시해야 한다.

DRAM 액세스는 로컬 cache에 필요한 디스크 입출력을 피한다. 또한 Postgres가 캐시된 페이지와 그 사용 방식에 대해 직접 파악할 수 있게 한다. 운영체제 cache나 별도의 디스크 계층은 어떤 페이지를 제거할지 결정할 때 데이터베이스 상태에 관한 정보가 더 적다.

이것이 Lakebase Postgres compute cache 개선의 즉각적인 의미다. 새 인덱스, 쿼리 플래너 또는 스토리지 형식이 아니다. Databricks는 기존 Postgres 실행 엔진을 둘러싼 메모리 할당과 가상 메모리 메커니즘을 바꿨다.

적용 범위가 중요하다. 고정 크기 배포는 메모리 상한이 알려진 상태로 유지되므로 시작 시 shared buffers를 할당할 수 있다. Autoscaling endpoint는 같은 가정을 할 수 없다. 사용 가능한 메모리는 워크로드 수요에 따라 변하지만 표준 Postgres 설정은 시작 후 정적으로 유지된다.

이 때문에 첫 릴리스는 의미가 있지만 완전하지는 않다. Databricks는 메모리를 더 직접적으로 사용하면 대형 Lakebase endpoint를 개선할 수 있음을 보여줬다. 분리형 Postgres를 매력적으로 만드는 serverless 운영 모델 전반에 동일한 설계를 아직 제공한 것은 아니다.

Lakebase Cache 성능이 우선순위가 된 이유

스토리지 분리는 운영 유연성을 제공하지만, 모든 cache miss는 그 유연성에 가려진 지연 시간과 CPU 비용을 드러낸다.

전통적인 Postgres는 일반적으로 쿼리 엔진, write-ahead log, 데이터베이스 파일을 한 머신 또는 긴밀히 연결된 스토리지에 함께 둔다. 운영체제는 최근 액세스한 파일 페이지를 page cache에 유지할 수 있다. Postgres 역시 선택된 페이지를 shared buffers에 보관한다.

이 구성은 메모리에서 데이터를 중복시킬 수 있다. Databricks는 RAM 4 GB와 shared buffers에 할당된 1 GB를 갖춘 머신의 예를 든다. 파일시스템을 통해 1 GB를 읽으면 운영체제 cache에 또 다른 복사본이 남아, 데이터베이스 페이지 1 GB를 캐시하는 데 2 GB를 소비할 수 있다.

Lakebase는 경로를 바꾼다. storage architecture는 시스템을 stateless Postgres compute와 영속 스토리지 서비스로 나눈다. Safekeeper는 write-ahead log 레코드를 복제하고, pageserver는 페이지 버전을 재구성해 object storage에 영속화한다.

이 아키텍처는 저장된 데이터와 독립적으로 compute를 확장할 수 있게 한다. 전체 데이터베이스를 복사하지 않고도 scale-to-zero, 빠른 branching, read replicas, failover 같은 기능을 지원한다. 이런 이점은 영속 상태를 compute 노드 밖에 유지하는 데 달려 있다.

하지만 stateless compute도 쿼리를 처리하는 동안에는 가까운 곳에 상태가 필요하다. 애플리케이션은 인덱스, 테이블 페이지, catalog records 및 기타 구조에 반복적으로 액세스한다. 이 페이지들이 DRAM에 남아 있다면 읽기는 계층 구조상 가장 낮은 지연 시간의 부분에서 완료된다.

Shared buffers에서 누락되면 더 긴 경로를 거친다. 로컬 NVMe cache는 원격 스토리지보다 빠르지만, 여전히 디스크 액세스와 추가 소프트웨어 처리가 필요하다. 여기서도 누락되면 pageserver에 도달하며, 네트워크 트래픽과 페이지 재구성 작업이 추가될 수 있다.

그 결과 지연 시간에 민감한 애플리케이션을 위해 대형 Lakebase instance를 사용하는 팀에 부담이 집중된다. 이 고객들은 상당한 메모리를 프로비저닝하지만, 이전의 1 GB shared-buffer 상한은 Postgres가 가장 빠른 cache 경로를 통해 그 메모리 대부분을 사용하는 것을 막았다.

Working set이 커질수록 불일치는 더 뚜렷해진다. Working set은 애플리케이션이 특정 기간 동안 자주 액세스하는 페이지 모음이다. 이것이 작은 메모리 cache를 초과하면 머신에 충분한 DRAM이 있더라도 요청은 더 느린 계층으로 흘러간다.

Lakebase가 이제 분석 작업뿐 아니라 운영 워크로드도 처리하기 때문에 Databricks에는 더 나은 해법이 필요했다. 사용자 대면 애플리케이션은 지연 시간 분포의 느린 끝부분에 가까운 요청을 반영하는 tail latency에 민감하다. 평균은 양호하게 유지될 수 있지만 p99 요청은 여전히 눈에 띄는 지연을 만들 수 있다.

AI 애플리케이션 역시 운영 데이터베이스에 불균등한 압력을 가한다. Agent는 retrieval, 쓰기, checkpoint, 동시 tool call의 급증을 유발할 수 있다. 트래픽이 일정한 요청 흐름이 아닌 군집 형태로 유입될 때 예측 가능한 cache 동작은 더욱 중요해진다.

그렇다고 모든 워크로드가 동일한 이점을 얻는 것은 아니다. 이미 이전 shared-buffer 할당 범위에 들어가는 데이터셋은 개선 여지가 적다. 페이지 재사용이 거의 없는 scan 중심 워크로드는 buffer 크기와 관계없이 계속 하위 cache 계층에 도달할 수 있다.

가장 유력한 대상은 이전 1 GB 한도를 초과한 재사용 가능한 working set을 가진 대형 endpoint다. 이들의 기존 메모리는 이제 더 많은 hot pages를 Postgres 내부에 직접 보관할 수 있다. 이것이 Databricks가 보편적인 두 배 향상을 약속하는 대신 프로덕션 사례를 제시한 이유다.

따라서 Lakebase cache 성능은 머신 크기만큼이나 워크로드 형태에 좌우된다. 새 구성은 하나의 아키텍처 병목을 제거한다. 하지만 cache locality, 쿼리 설계, indexing 또는 메모리 경합을 지배하는 기본 규칙을 없애지는 않는다.

Huge Pages가 더 큰 Buffer Pool을 실용적으로 만든다

Postgres에 더 많은 메모리를 할당하면 Lakebase가 데이터베이스 프로세스 전반에서 해당 메모리를 매핑하는 비용도 줄이지 않는 한 자체적인 오버헤드가 발생한다.

Postgres는 프로세스 기반 아키텍처를 사용한다. 활성 연결마다 일반적으로 backend process가 할당되고, 각 backend는 shared-buffer 영역을 자신의 가상 주소 공간에 매핑한다. 운영체제는 이런 가상 주소를 물리 메모리 위치로 변환하는 page-table entries를 유지한다.

표준 Linux 메모리 페이지는 일반적으로 4 KB다. 이 페이지 크기에서는 shared buffers 1 GB에 대해 영역을 매핑하는 각 프로세스마다 262,144개의 page-table entries가 필요하다. Databricks는 512개 backend에 걸친 shared buffers 32 GB가 약 43억 개의 entries를 요구할 수 있다고 계산한다.

회사는 이러한 entries가 32 GB cache를 매핑하는 데만 약 32 GB의 page tables를 소비할 것으로 추정한다. 이는 더 큰 buffer 할당이 어떻게 오버헤드를 다른 곳으로 옮길 수 있는지를 보여주는 극단적인 사례다. 메모리 관리가 과도한 RAM과 CPU 시간을 소비한다면 더 큰 cache 용량이 자동으로 유용해지는 것은 아니다.

프로세서는 translation lookaside buffer, 즉 TLB도 유지한다. 이 하드웨어 cache는 최근의 가상-물리 주소 변환을 저장한다. 데이터 페이지가 Postgres 메모리에 있어도 TLB miss 이후 CPU는 그 위치를 찾는 데 여전히 비용을 치를 수 있다.

Huge pages는 더 큰 단위로 메모리를 매핑해 이러한 부담을 줄인다. Lakebase는 새 고정-compute 구성에 명시적 2 MB HugeTLB pages를 사용한다. 각 huge page는 표준 4 KB 페이지보다 512배 많은 메모리를 포괄하므로, 필요한 mapping entries 수도 같은 비율로 줄어든다.

PostgreSQL은 이미 운영체제 huge-page controls를 제공한다. resource documentation은 명시적 huge pages가 대규모 연속 shared-memory 영역과 관련된 오버헤드를 줄일 수 있다고 설명한다. 이 이점은 shared_buffers가 매우 커질 때 특히 중요하다.

가상화는 구현을 더 어렵게 만든다. Lakebase는 bare-metal host에서 경량 guest virtual machines 내부로 Postgres를 실행한다. 따라서 주소 변환은 guest와 host 계층을 모두 거친다. Huge pages는 의도한 이점을 유지하기 위해 host, hypervisor, guest 전반에서 일관되게 지원돼야 한다.

Databricks는 이 스택 전체에 전용 huge-page 지원을 추가했다고 밝힌다. 대형 고정 크기 virtual machines는 미리 정해진 수량의 huge pages로 시작한다. Postgres가 초기화된 후 compute 시스템은 데이터베이스가 필요로 하지 않는 용량을 해제한다.

회사는 transparent huge pages 대신 명시적 HugeTLB pages를 선택했다. Transparent huge pages는 운영체제가 메모리를 자동으로 승격하도록 하지만, 이 동작은 최선의 노력에 기반한다. 명시적 예약은 데이터베이스 환경이 페이지 가용성과 레이아웃을 더 엄격하게 제어할 수 있게 한다.

Databricks 벤치마크 테스트에서 huge page는 테일 읽기 지연 시간을 최대 약 40% 줄였습니다. CPU 사용률은 최대 약 30% 감소했습니다. 이는 회사 측정치이며, 모든 Lakebase 워크로드에 대한 독립적인 보장은 아닙니다.

이 구분은 중요합니다. huge page만으로 보고된 개선 효과 전체를 설명할 수는 없기 때문입니다. 두 가지 변화가 함께 도입됐습니다. 더 많은 데이터가 shared buffer에 유지됐고, 더 큰 해당 영역에 접근하는 데 필요한 페이지 변환 횟수도 줄었습니다. 워크로드마다 두 메커니즘에서 얻는 이점의 비중은 다를 수 있습니다.

관리자는 Postgres를 통해 배포된 설정을 확인할 수 있습니다. 적격한 80-unit Lakebase 엔드포인트에서 show huge_pages를 실행하면 on이 반환되어야 합니다. 이를 shared_buffers 값과 함께 보면 새 구성이 특정 컴퓨트에 적용됐는지 직접 확인할 수 있습니다.

이 메커니즘은 일반적인 Postgres 배포에서 단순히 shared_buffers를 늘리는 것만으로는 완전한 해답이 아닌 이유도 설명합니다. 데이터베이스에 예약된 메모리는 연결, 쿼리 작업, 유지보수 작업, 운영체제 요구 사항과 공존해야 합니다. 주변 시스템이 이를 고려해 설계되지 않았다면 대규모 할당은 새로운 제약을 만들 수 있습니다.

Databricks는 가상 머신, 컴퓨트 이미지, 캐시 경로, 스토리지 프로토콜을 제어합니다. 이러한 엔드투엔드 제어를 통해 huge page 예약을 Postgres 시작 과정과 조율할 수 있습니다. 자체 관리 팀이라면 이 계층들을 각각 튜닝하고 자체 워크로드에서 결과를 검증해야 합니다.

따라서 Lakebase 캐싱 방식은 단순히 “RAM을 더 사용한다”는 것보다 복잡합니다. 개선 효과는 핫 데이터를 적절한 메모리 영역에 배치하고, 그 영역을 효율적으로 매핑하며, 버퍼 풀 밖의 모든 요소를 위해 충분한 메모리를 남겨 두는 데 달려 있습니다.

프로덕션 결과는 개선을 보여주지만 보편적 기준선은 아니다

Databricks는 세 개의 프로덕션 엔드포인트에서 상당한 개선을 보고했지만, 공개된 사례가 플랫폼 전체의 평균 성능을 입증하는 것은 아닙니다.

첫 번째 사례에는 8월 11일 06:10 UTC경 새 구성이 적용됐습니다. Databricks가 처리량의 대리 지표로 사용한 초당 접근 Postgres 블록 수는 두 배가 됐습니다. 스토리지 GetPage 요청은 초당 약 8,000건에서 약 1,500건으로 줄었습니다.

고객은 전날, 전주, 전월과 비교해 중앙값 및 p99 지연 시간이 낮아졌다고도 보고했습니다. 다만 이번 발표에는 기본 지연 시간 값, 워크로드 정의, 쿼리 구성, 통제된 비교 환경이 제공되지 않았습니다. 독자는 이를 표준화된 벤치마크가 아니라 프로덕션 결과로 해석해야 합니다.

두 번째 엔드포인트는 8월 14일 01:30 UTC경 변경됐습니다. 보고된 처리량은 약 43% 증가했고, 컴퓨트 캐시 적중률은 100%에 근접했습니다. 롤아웃 후 요청은 거의 전적으로 shared buffer에서 처리됐습니다.

세 번째 엔드포인트는 8월 15일 변경됐습니다. Databricks는 CPU 소비가 20코어에서 4코어로 감소했고, 캐시 적중률이 100%에 근접했으며, 측정 처리량이 두 배가 됐다고 밝혔습니다. CPU 사용량이 5분의 1로 줄었다는 점은 눈에 띄지만, 공개 게시물은 모든 외부 워크로드 조건이 동일하게 유지됐는지는 명시하지 않습니다.

이 사례들은 함께 신뢰할 만한 메커니즘을 뒷받침합니다. 더 많은 요청이 DRAM에서 적중했고, 분산 스토리지 서비스까지 도달한 읽기는 줄었으며, 프로세서는 주소 변환에 쓰는 시간이 감소했습니다. 이는 설계 변경과 일치하는 결과입니다.

그러나 모든 적격 컴퓨트가 두 배 빨라진다는 뜻은 아닙니다. Databricks는 “최대”라는 표현을 사용했고, 세 결과도 서로 다릅니다. 한 사례는 43%의 처리량 증가를 기록한 반면, 두 사례는 이전 측정치의 약 두 배에 도달했습니다.

워크로드 구성은 여전히 가장 큰 변수입니다. 크지만 제한된 워킹 세트에 반복 접근하는 캐시 민감형 쿼리는 더 큰 이득을 얻을 가능성이 큽니다. 쓰기 비중이 높은 작업, 재사용이 적은 스캔, 락 경합, 비효율적인 쿼리 또는 네트워크 병목 애플리케이션 로직은 가시적인 개선 폭을 제한할 수 있습니다.

기존 로컬 파일 캐시도 유용한 역할을 했습니다. 이는 초기 shared buffer 할당보다 더 큰 용량을 제공했고, 많은 스토리지 계층 요청을 피하게 했습니다. 핫 페이지를 NVMe에서 DRAM으로 옮기면 가장 빠른 경로는 개선되지만, 이 보조 계층을 제거하면 워킹 세트가 가용 메모리를 초과할 때의 동작은 달라집니다.

Databricks는 이제 이러한 고정 컴퓨트에서 미스가 shared buffer를 거쳐 분산 스토리지로 진행된다고 말합니다. 이는 유난히 크거나 변화가 잦은 워크로드에 중요한 질문을 제기합니다. 더 높은 메모리 적중률은 확장된 버퍼 풀 밖으로 벗어난 페이지에 대한 더 큰 페널티와 공존할 수 있습니다.

공개된 엔드포인트는 활성 데이터가 더 큰 할당 범위에 잘 들어맞았기 때문에 혜택을 얻은 것으로 보입니다. 두 사례에서 거의 100%에 달한 적중률은 강한 지역성을 시사합니다. 지역성이 낮은 애플리케이션에서는 빠른 적중과 원격 미스 사이의 균형이 다르게 나타날 수 있습니다.

재시작 동작도 주의가 필요합니다. Shared buffer는 일시적이므로 새로 시작한 컴퓨트는 일반적으로 핫 워킹 세트가 메모리에 없는 상태로 시작합니다. Databricks는 별도로 automatic cache prewarming을 문서화하고 있으며, 이는 계획된 업데이트 중 자주 사용하는 데이터를 다시 채웁니다.

프리워밍은 업데이트 후 콜드 캐시 페널티를 줄일 수 있지만, 애플리케이션은 재시작 중에도 짧은 연결 중단을 경험할 수 있습니다. 드라이버, 풀, 재시도 로직은 이 이벤트를 처리해야 합니다. 캐시 개선이 연결 복원력의 필요성을 없애지는 않습니다.

독립적인 벤치마크 결과가 나오면 근거는 더 강해질 것입니다. 유용한 테스트는 데이터세트 크기, 연결 수, 쿼리 분포, 버퍼 상태, 컴퓨트 크기, 지연 시간 백분위수를 공개해야 합니다. 또한 안정적인 워킹 세트와 변화하는 워킹 세트 모두에서 기존 및 새 캐시 경로를 비교해야 합니다.

현재로서는 더 좁은 결론이 근거를 갖습니다. Lakebase Postgres 컴퓨트 캐시 개선은 Databricks가 측정한 대규모 프로덕션 엔드포인트에서 효과적인 것으로 보입니다. 다른 애플리케이션에서의 개선 폭은 운영자가 자체 지연 시간, 적중률, CPU, 스토리지 읽기 지표로 답해야 할 실증적 질문으로 남아 있습니다.

핵심 충돌은 고정 메모리와 오토스케일링 사이에 있다

이번 릴리스는 Lakebase의 더 단순한 절반을 개선하지만, 제품의 서버리스 약속은 Postgres를 재시작하지 않고 캐시 메모리 크기를 조정하는 데 달려 있습니다.

shared_buffers 설정은 일반적으로 Postgres가 시작되기 전에 선택됩니다. 데이터베이스가 초기화 중 shared-memory 영역을 설정하므로 이를 변경하려면 재시작이 필요합니다. 이 동작은 트래픽을 처리하는 중에도 메모리 용량이 바뀌는 오토스케일링 컴퓨트와 직접 충돌합니다.

고정 컴퓨트는 이 충돌을 피합니다. Databricks는 가상 머신의 메모리 용량을 알고, 그중 75%를 shared buffer에 할당하고, 이에 해당하는 huge page를 예약한 뒤 Postgres를 시작합니다. 이 할당은 머신 수명 동안 변경되지 않은 채 유지될 수 있습니다.

오토스케일링 엔드포인트는 확장과 축소를 모두 지원해야 합니다. 수요가 증가하면 Postgres는 버퍼 용량을 확보해야 하고, 게스트는 이를 효율적으로 매핑하는 데 필요한 정확한 huge page 수를 받아야 합니다. 수요가 줄면 두 리소스 모두 활성 상태를 손상하거나 방해적인 재시작을 유발하지 않고 반환되어야 합니다.

이는 상당히 다른 엔지니어링 과제입니다. Shared memory에는 활성 백엔드가 읽고, 수정하고, 고정하거나, 검사하는 페이지가 포함될 수 있습니다. 영역을 축소하려면 캐시 제거와 동시 데이터베이스 활동을 안전하게 조율해야 합니다.

Databricks는 동적 shared buffer와 함께 huge page를 확장하는 프로토콜을 개발했다고 말합니다. 회사는 두 번째 기술 게시물에서 이 구현을 설명할 계획입니다. 또한 기반 메커니즘을 위해 오픈소스 PostgreSQL 커뮤니티와 협력할 의향도 밝혔습니다.

해당 작업이 출시되기 전까지 Lakebase에는 두 가지 캐시 전략이 있습니다. 대형 고정 컴퓨트에는 확장된 shared-buffer 설계가 적용됩니다. 오토스케일링 컴퓨트는 보수적으로 설정된 shared buffer와 로컬 파일 캐시의 기존 조합에 계속 의존합니다.

이 분리는 제품 포지셔닝에 압력을 가합니다. 고정 용량은 현재 가장 명확한 성능 개선을 제공하는 반면, 오토스케일링은 서버리스 데이터베이스와 연관된 유연성을 제공합니다. 고객은 아직 동일한 컴퓨트 모드에서 두 특성을 모두 얻는다고 가정할 수 없습니다.

그렇다고 모든 배포에서 오토스케일링이 열등한 것은 아닙니다. 변동이 크거나 간헐적인 애플리케이션은 가능한 최저 캐시 지연 시간보다 scale-to-zero와 탄력적 용량을 더 중요하게 여길 수 있습니다. 안정적이고 메모리 집약적인 프로덕션 서비스는 예측 가능한 고정 리소스를 선호할 수 있습니다.

이 결정은 워크로드 증가에도 달려 있습니다. 고정 컴퓨트는 운영자가 사전에 충분한 용량을 선택하도록 요구합니다. 오토스케일링은 트래픽 변화를 흡수할 수 있지만, 현재 캐시 경로에서는 워킹 세트가 작은 shared-buffer 할당을 초과할 때 더 많은 적중이 로컬 NVMe를 거칠 수 있습니다.

이것이 Lakebase 캐시 성능의 실질적인 경쟁 시험대입니다. 다른 관리형 Postgres 서비스도 분산 내구성, 로컬 캐싱, 복제본, 탄력적 리소스 관리를 결합합니다. 아키텍처 세부 사항은 다르므로 헤드라인 벤치마크 수치만으로 깔끔한 제품 순위를 매길 수는 없습니다.

Databricks는 대신 자사의 스토리지 분리가 목표 워크로드에 피할 수 있는 페널티를 부과하지 않는다는 점을 보여야 합니다. 동적 shared buffer를 제공하면 Lakebase는 상태 비저장 컴퓨트 모델을 유지하면서도 더 많은 탄력적 메모리를 Postgres의 직접 제어 아래 둘 수 있습니다.

업스트림 협업은 Lakebase를 넘어 영향을 확대할 수 있습니다. 동적 버퍼 크기 조정은 할당 메모리가 시간에 따라 바뀌는 컨테이너화 및 탄력적 Postgres 환경에도 관련성이 있습니다. 그러나 Databricks는 발표에서 설명한 코드, 검토 상태, 릴리스 경로를 아직 공개하지 않았습니다.

이 불확실성은 명시적으로 유지되어야 합니다. 회사는 방향을 제시했고 오토스케일링 프로토콜이 존재한다고 말합니다. 하지만 오토스케일링 shared buffer의 출시일, 지원 컴퓨트 범위, 프로덕션 측정치를 제공하지는 않았습니다.

따라서 고정 컴퓨트 롤아웃은 개선이자 미리보기입니다. 이는 안정적인 메모리 조건에서 캐시 배치와 huge-page 메커니즘을 검증합니다. 다음 단계에서는 가용성이나 예측 가능한 성능을 희생하지 않고도 이러한 메커니즘이 변화하는 머신을 따라갈 수 있음을 입증해야 합니다.

Lakebase 사용자가 지금 측정해야 할 것

중요한 질문은 공개된 벤치마크가 인상적인지가 아니라, 적격 워크로드가 새로운 미스 페널티 없이 더 빨라지는지입니다.

적격 사용자는 먼저 구성을 확인할 수 있습니다. show shared_buffers는 현재 Postgres 버퍼 할당을 보여주고, show huge_pages는 명시적 huge page가 활성 상태인지 보고합니다. 회사 사례에 따르면 80-unit Databricks 엔드포인트는 120 GB와 on을 표시해야 합니다.

구성만으로 가치를 입증할 수는 없습니다. 팀은 동등한 트래픽 기간에 걸쳐 캐시 적중률, 스토리지 GetPage 활동, CPU 소비, 처리량, p50 및 p99 쿼리 지연 시간을 비교해야 합니다. 비교 시 배포, 데이터 증가, 유지보수, 애플리케이션 변경 사항을 고려해야 합니다.

캐시 적중률은 맥락과 함께 해석해야 합니다. 100%에 가까운 비율은 활성 워킹 세트가 메모리에 들어맞는다는 뜻일 수 있습니다. 그러나 처리량과 지연 시간 없이 살펴보면 요청 비용, 쿼리 빈도, 워크로드 구성의 차이를 가릴 수도 있습니다.

스토리지 읽기는 또 다른 직접적인 신호를 제공합니다. 감소는 더 많은 페이지가 pageserver까지 도달하지 않고 Postgres 내부에 유지된다는 점을 시사합니다. Databricks는 첫 사례에서 초당 약 8,000건에서 1,500건으로 감소한 것을 근거로 GetPage 요청이 약 5.3배 줄었다고 보고했습니다.

CPU 측정은 huge page와 디스크 캐시 처리 회피의 이점을 보여줄 수 있습니다. 그러나 CPU 사용량 감소는 안정적이거나 증가한 처리량과 함께 볼 때 가장 유용합니다. 한가한 기간에는 효율성 향상을 반영하지 않고도 CPU와 완료 작업량이 모두 줄어들 수 있습니다.

팀은 재시작 및 워밍업 동작도 점검해야 합니다. 계획된 업데이트는 컴퓨트 재시작을 유발하지만, Databricks는 일반적으로 몇 초밖에 걸리지 않는다고 말합니다. 해당 구간 전후의 연결 재시도와 테일 레이턴시를 테스트하면 정상 상태 차트에서 놓치는 운영상 영향을 드러낼 수 있습니다.

구체적인 사례로, 활성 인덱스와 자주 접근되는 행이 수십 기가바이트를 차지하는 트랜잭션 애플리케이션을 들 수 있습니다. 이전 구성에서는 그중 일부만 공유 버퍼에 유지될 수 있었습니다. DRAM에 활용되지 않은 여력이 있었음에도 많은 조회가 로컬 NVMe 캐시까지 내려갔습니다.

업데이트 후에는 해당 워킹 세트가 확장된 버퍼 풀에 거의 전부 들어갈 수 있습니다. 팀은 스토리지 요청 감소, 읽기 지연시간 단축, CPU 오버헤드 감소를 예상해야 합니다. 이런 신호가 변하지 않는다면 다른 병목이 더 큰 영향을 미치고 있을 가능성이 큽니다.

AI 에이전트 서비스는 두 번째 시나리오를 제시합니다. 이 서비스는 대화 상태, 도구 결과, 작업 상태 또는 벡터 메타데이터를 Postgres에 저장할 수 있습니다. 자주 재사용되는 페이지가 메모리에 유지되면 순간적으로 몰리는 동시 읽기 요청의 이점을 얻을 수 있지만, 연결 수와 쿼리 패턴은 여전히 백엔드 프로세스에 가해지는 부하를 결정합니다.

이런 변경을 검토하는 엔지니어에게 필요한 것은 개별 스크린샷이 아니라 공유 가능한 근거입니다. 검색 가능한 engineering knowledge base는 나중에 비교할 수 있도록 벤치마크 조건, 쿼리 계획, 구성 스냅샷, 롤아웃 관찰 결과를 보존할 수 있습니다.

평가에는 실패 사례도 포함해야 합니다. 워킹 세트가 확장된 공유 버퍼를 초과하면 고정 컴퓨트에는 더 이상 중간 계층의 기존 로컬 파일 캐시가 없습니다. 콜드 스타트, 대규모 스캔, 급격한 워킹 세트 변화 중의 지연시간을 측정하면 원격 캐시 미스가 더 두드러지는지 확인할 수 있습니다.

이러한 점검이 회사의 핵심 주장을 받아들이거나 거부할 필요는 없습니다. 대신 제안된 메커니즘을 관측 가능한 신호로 전환합니다. 동등한 수요 조건에서 더 많은 읽기가 공유 버퍼에 적중하고 CPU 사용량과 테일 레이턴시가 감소한다면, 이 업데이트는 해당 워크로드에 효과를 내고 있는 것입니다.

처리량이 그대로라면 팀은 결과를 Lakebase 탓으로 돌리기 전에 잠금 대기, 애플리케이션 네트워킹, 쿼리 계획, 인덱스, 쓰기 부하를 검토해야 합니다. 캐시 변경만으로 데이터베이스 지연시간의 모든 원인을 해결할 수는 없습니다.

캐시 재설계의 중요성을 결정할 세 가지 신호

오토스케일링 제공, 독립적인 워크로드 근거, 업스트림 PostgreSQL의 진전이 이것이 광범위한 Lakebase 이점으로 자리 잡을지를 결정할 것입니다.

첫 번째 신호는 오토스케일링 컴퓨트를 위한 동적 공유 버퍼의 프로덕션 출시입니다. Databricks는 대용량 페이지 지원이 올바른 크기로 유지되는 가운데 공유 버퍼 용량이 메모리와 함께 확장·축소될 수 있음을 보여야 합니다. 적용 대상, 롤아웃 동작, 운영상 한계를 공개한 출시는 회사의 아키텍처 논거를 강화할 것입니다.

해당 출시에는 프로덕션 측정치가 수반되어야 합니다. 유의미한 비교는 오토스케일링과 무관한 고정형 벤치마크의 비교가 아닙니다. 스케일업 이벤트, 스케일다운 이벤트, 캐시 적중률, CPU 사용량, p99 지연시간을 포함해 동적 버퍼 적용 전후의 동일한 탄력적 워크로드를 비교하는 것입니다.

오토스케일링이 중단을 유발하는 재시작 없이 유사한 캐시 효율성에 도달한다면, 현재 분석은 더욱 설득력을 얻습니다. 이는 분리형 Postgres가 탄력적 컴퓨트와 대규모 엔진 관리형 메모리 캐시를 결합할 수 있음을 보여줄 것입니다. 장기간 지연된다면 가장 빠른 경로는 고정 용량에만 제한될 것입니다.

두 번째 신호는 더 폭넓은 벤치마크 근거입니다. Databricks는 유리한 프로덕션 사례 세 건을 공개했지만, 사용자는 서로 다른 워킹 세트 크기와 쿼리 패턴 전반의 결과를 필요로 합니다. 독립 테스트에는 읽기 중심 트랜잭션, 읽기와 쓰기가 혼합된 작업, 높은 연결 수, 콜드 스타트, 가용 DRAM보다 큰 워크로드가 포함되어야 합니다.

일관된 성능 향상에 대한 근거는 주장된 메커니즘을 뒷받침할 것입니다. 결과가 매우 가변적이라고 해서 이번 출시가 무효가 되는 것은 아니지만, 혜택을 볼 가능성이 높은 애플리케이션의 범위는 좁아질 것입니다. 로컬 디스크 계층 제거 이후 캐시 미스에서 성능 저하가 발생한다면 더 면밀한 주의가 필요합니다.

세 번째 신호는 오픈소스 PostgreSQL에서의 가시적인 진전입니다. Databricks는 동적 공유 버퍼와 관련해 업스트림과 협력할 계획이라고 밝혔습니다. 구체적인 제안, 패치, 기술 토론, 리뷰어 피드백은 솔루션의 어느 정도가 Postgres 자체에 속하는지를 보여줄 것입니다.

업스트림의 수용은 설계에 더 폭넓은 기술적 검토를 제공하고, 한 벤더를 넘어 유용하게 만들 것입니다. 또한 탄력적인 클라우드 환경과 고정된 머신을 전제로 설계된 Postgres 설정 간의 장기적 격차를 줄일 수 있습니다.

업스트림으로 작업을 반영하지 못한다고 해서 Databricks가 플랫폼 특화 구현을 출시하지 못하는 것은 아닙니다. 다만 외부인이 호환성, 유지보수, 이식성을 평가하기는 더 어려워질 것입니다.

Lakebase Postgres 컴퓨트 캐시 개선은 이미 일부 고정 컴퓨트에서 측정 가능한 결과를 내고 있습니다. 더 중요한 시험은 Databricks가 스토리지 분리가 제공하는 탄력성을 약화시키지 않으면서 캐시를 동적으로 만들 수 있는지 여부입니다.

적용 대상 엔드포인트를 운영하는 팀의 다음 조치는 명확합니다. 설정을 확인하고 안정적인 기준선을 확보한 뒤, 롤아웃 후 실제 워크로드 지표를 비교하십시오. 오토스케일링 사용자는 동일한 성능 향상이 적용된다고 가정하기 전에 두 번째 엔지니어링 출시를 지켜봐야 합니다. 오늘날 애플리케이션에 더 중요한 것은 고정 메모리 성능입니까, 아니면 수요에 맞춰 용량을 확장할 자유입니까?