원문 소식, 쉽게 읽기

클라우드플레어는 2026년 10월 13일 서버리스 SQL 데이터베이스 D1의 확장 구조를 공개했다. D1은 SQLite 방식의 SQL을 쓰면서 Workers나 HTTP API에서 접근하는 관리형 서비스다. 회사는 AI로 앱을 만드는 플랫폼이 사용자·앱·미리보기 환경·입주 기업마다 작은 데이터베이스를 따로 두는 흐름에 대응해 구조를 바꿨다고 설명했다. 출처

2026년 10월 8일 기준 D1 데이터베이스는 550만 개를 넘어섰다. 삭제되지 않은 데이터베이스 수는 1년 동안 15배, 2년 동안 65배 늘었고, 하루에 한 번 이상 쿼리를 실행한 활성 데이터베이스 수는 1년 동안 18배 증가했다. 이 수치는 클라우드플레어가 공개한 플랫폼 전체 집계다. 특정 이용자의 성능과 계정별 생성 한도는 별도 지표다. 출처

핵심 설계는 쿼리를 처리하는 데이터 경로와 데이터베이스 생성·삭제 같은 관리 경로를 분리한 것이다. 각 D1 데이터베이스는 SQLite를 실행하는 하나의 Durable Object와 연결된다. SQL 쿼리는 이용자 가까운 엣지의 Worker에서 D1 Eyeball Worker를 거쳐 해당 Durable Object로 전달된다. 중앙의 Postgres는 데이터베이스 목록과 상태 같은 관리용 정보를 저장하지만, 정상적인 쿼리마다 중앙 서버를 거치게 하지는 않는다. 출처

HTTP API로 쿼리를 보낼 때는 Workers KV에 저장된 데이터베이스 ID와 Durable Object의 연결 정보를 먼저 읽는다. KV에 정보가 없는 드문 경우에만 Hyperdrive의 캐시와 중앙 Postgres 읽기 복제본을 차례로 확인한다. Worker에 D1 Binding을 연결한 요청은 필요한 연결 정보를 Binding이 이미 갖고 있어 Eyeball Worker와 Durable Object로 바로 간다. 중앙 데이터베이스 장애나 캐시 초기화가 모든 쿼리의 병목으로 번지는 위험을 줄이려는 구조다. 출처

새 데이터베이스를 만들 때는 고유한 데이터베이스 ID와 Durable Object ID를 생성하고, Durable Object를 초기화한 다음 중앙 Postgres에 관리 정보를 기록한다. Postgres 기록이 완료되면 생성된 것으로 판단하며 Workers KV 갱신은 이후에도 복구할 수 있는 작업으로 둔다. Durable Object는 30초에 데이터베이스별 임의 지연을 더한 간격으로 상태를 확인한다. 재시도 과정에서 남은 고아 객체, 삭제 상태와 KV 정보가 어긋난 경우를 이 heartbeat가 바로잡는다. 출처

저장 공간 사용량은 각 Durable Object가 보낸 변화를 큐로 모아 중앙 Postgres에 배치로 반영한다. 계정별 합계를 매번 전체 검색하는 대신 변화량을 별도 표에 쌓고 1초마다 계정 단위로 합쳐 쓰기 경합을 줄인다. 무료 등급의 일일 읽기·쓰기 행 사용량은 분석용 ClickHouse에서 집계하고, 제한 대상 계정 정보는 빠르게 복제되는 분산 키-값 저장소를 통해 엣지에 전달한다. 실시간 정확도가 꼭 필요하지 않은 계산을 쿼리 경로 밖으로 옮긴 방식이다. 출처

이번 발표의 범위는 내부 아키텍처와 공급자 집계 수치다. 새 요금제, 모든 계정의 한도 상향과 개별 쿼리의 응답시간 보장은 포함되지 않았다. 데이터베이스별 크기와 계정별 저장 공간, 요금과 사용량 한도는 실제 이용 등급과 최신 D1 문서에서 별도로 확인해야 한다. 출처

OYOPICK의 시선

D1 사례에서 가장 재사용할 만한 원칙은 중앙 데이터베이스를 더 크게 만드는 데 앞서 이용자가 기다리는 쿼리 경로와 관리·집계 경로를 분리한 점이다. 여러 고객이 각각 작은 데이터베이스를 갖는 서비스라면, 목록·결제·통계 작업의 지연이 실제 데이터 요청까지 막지 않도록 경계를 세우는 것이 확장성에 직접 연결된다.

대신 eventual consistency, 즉 일부 관리 정보가 잠시 늦게 맞춰질 수 있는 방식을 사용한다. 저장량이나 삭제 상태가 즉시 모든 곳에 반영돼야 하는 업무에는 같은 설계를 그대로 적용하기 어렵다. 어떤 값은 늦어도 되는지, 잘못된 중간 상태를 heartbeat나 재시도로 어떻게 회복할지를 먼저 정해야 이 장점이 살아난다.

초기 서비스가 D1의 모든 구성요소를 복제할 필요도 없다. 클라우드플레어 역시 Durable Object를 이름으로 찾는 단순한 방식부터 시작하고, 중앙 조회가 실제 병목일 때만 고유 ID와 별도 연결 정보를 쓰라고 설명한다. 현실적인 순서는 대표 부하를 측정하고 병목을 확인한 뒤, 쿼리 경로에서 중앙 의존성을 하나씩 걷어 내는 것이다.