Cloudflare D1 무료 한도: 쿼리가 멈추는 시점

Cloudflare D1 무료 한도는 2026년 9월 1일부터 단순한 사용량 기준이 아니라 프로덕션 가용성을 좌우하는 조건이 됐습니다. 계정에서 하루에 행 읽기 500만 건 또는 행 쓰기 100,000건 중 하나라도 소진하면 UTC 자정까지 D1 쿼리가 멈출 수 있습니다.

Cloudflare D1 무료 한도는 그대로지만 초과 시 동작이 달라졌습니다

무료 제공량 자체는 전에도 있었습니다. 달라진 것은 한도에 닿았을 때 벌어지는 일입니다.

Workers Free에서는 두 가지 일일 한도 중 하나라도 넘으면 이제 Workers Binding API와 REST API 모두에서 D1이 쿼리를 거부합니다. Cloudflare는 읽기 한도와 쓰기 한도에 각각 다른 메시지가 표시되며, 허용량이 00:00 UTC에 초기화되면 쿼리가 재개된다고 설명합니다. 저장된 데이터는 그대로 보존되지만 애플리케이션에서 이를 읽거나 변경하지 못할 수 있습니다.

이 차이가 이번 변경의 핵심입니다. 참고용 사용량 수치가 서비스 가용성을 끊는 명확한 경계선으로 바뀌었습니다.

Cloudflare는 일일 한도에 도달하면 이메일을 보냅니다. 장애 원인을 알려 주기는 하지만, 그때는 이미 데이터베이스를 사용할 수 없는 상태입니다. 프로덕션 팀에 필요한 것은 장애가 난 뒤의 설명만이 아니라 사전에 정한 예산과 조기 경보입니다. 9월 1일 D1 변경 로그에서 정확한 실패 동작과 오류 문구를 확인할 수 있습니다.

Workers Paid에는 이 일일 중단 규칙이 적용되지 않습니다. 두 한도보다 사용량이 충분히 낮은 프로토타입이라면 당장 옮길 필요는 없습니다. 하지만 D1에 의존하는 실제 서비스라면 이제 Free도 중단 지점이 있는 다른 자원과 똑같이 관리해야 합니다.

Cloudflare D1 사용량 제한은 스캔한 행을 기준으로 합니다

읽기 허용량은 API 호출 500만 회나 반환된 레코드 500만 건을 뜻하지 않습니다. 데이터베이스가 쿼리에 응답하는 과정에서 스캔한 행이 500만 건까지라는 의미입니다.

필터 결과는 고객 1명뿐이지만 쓸 만한 인덱스가 없다고 가정해 보겠습니다. D1은 그 레코드를 찾으려고 5,000행짜리 테이블 전체를 스캔할 수 있습니다. 이 쿼리를 1,000번 실행하면 일일 행 읽기 500만 건을 모두 소진합니다. 결과는 작아 보여도 내부 작업량은 작지 않습니다.

쓰기는 계산이 더 단순합니다. INSERT, UPDATE, DELETE는 변경된 행 수만큼 집계됩니다. 10개 행을 삽입하면 행 쓰기 10건으로 계산됩니다. CREATE, ALTER, DROP 같은 스키마 작업도 읽기와 쓰기를 함께 소비할 수 있습니다.

행 크기는 이 측정값을 바꾸지 않습니다. 1 KB 행과 100 KB 행 모두 각각 1개 행으로 계산됩니다. 읽기 수치를 좌우하는 것은 쿼리 형태입니다.

인덱스가 있으면 D1은 테이블 전체를 훑는 대신 관련 레코드로 바로 이동할 수 있습니다. 대개 쓰기 작업이 조금 늘어나는 대신 읽기 작업은 훨씬 크게 줄어듭니다. 인덱스에 포함된 열에 값을 쓰면 D1은 테이블 행과 최소 1개의 인덱스 행을 함께 기록합니다. 모든 열에 무작정 인덱스를 거는 것이 아니라, 자주 사용하는 필터와 조인 열을 골라 인덱싱해야 하는 이유입니다.

Cloudflare의 인덱스 가이드는 간단한 확인법을 제시합니다. 비용이 큰 쿼리 앞에 EXPLAIN QUERY PLAN을 붙이십시오. 실행 계획에 SCAN이 나오면 테이블을 읽고 있는 것이고, SEARCH ... USING INDEX가 나오면 인덱스를 사용하고 있는 것입니다. 인덱스를 추가한 뒤에는 쿼리 플래너가 최신 통계를 쓰도록 PRAGMA optimize를 실행합니다.

Cloudflare D1 요금보다 먼저 가용성 계산이 달라졌습니다

Workers Free의 가격은 여전히 $0입니다. 달라진 것은 손실 가능성입니다. 데이터베이스 요금의 최댓값은 계속 0이지만, UTC 기준으로 그날이 끝날 때까지 데이터베이스가 애플리케이션 요청 처리를 멈출 수 있습니다.

Workers Paid는 계정당 월 $5부터 시작합니다. 일일 강제 중단 대신 월간 기본 제공량과 초과 사용 요금이 적용됩니다.

Free에서 Paid로 옮길 때 늘어나는 여유는 예상보다 큽니다. Free 읽기 한도를 30일 내내 채워도 총 1억 5,000만 행으로, Paid 플랜에 포함된 250억 행의 0.6%에 불과합니다. Free 쓰기 한도를 30일간 모두 사용하면 300만 행이며, 기본 제공되는 5,000만 행의 6%입니다.

따라서 소규모 애플리케이션 상당수에서 첫 유료 전환은 초과 요금이 아니라 월 $5로 가용성을 확보할지의 결정입니다. Workers 요청, CPU, 5 GB를 넘는 D1 스토리지, 그 밖의 Cloudflare 제품에는 각각 별도 측정 기준이 있으므로 $5는 최저 비용일 뿐 계정 전체 요금이 정확히 $5라는 보장은 아닙니다. 더 넓은 범위의 Cloudflare 요금 검토에서 계정과 제품별 과금 경계를 확인할 수 있습니다.

D1에는 데이터 전송 또는 처리량 요금이 없습니다. 그렇다고 Free의 실패 위험이 줄어드는 것은 아닙니다. 다만 이 결정을 내릴 때 egress는 계산할 항목이 아니라는 뜻입니다.

팀 유형별로 달라지는 4가지 대응

실제 SaaS를 운영하는 1인 창업자

로그인, 결제 상태, 고객 대시보드가 D1을 읽는다면 Free 플랜은 이제 프로덕션 중단 위험을 안고 있습니다. 먼저 평상시 가장 바쁜 날을 찾고 전체 스캔을 모두 바로잡으십시오. 그래도 한도에 근접한다면, 데이터베이스에 접속하지 못하는 시간이 몇 시간일지 모르는 상황에 맞춰 운영하는 것보다 최소 $5를 내는 편이 저렴합니다.

실질적인 이점은 막연히 데이터베이스 용량이 늘어나는 데 있지 않습니다. 장애 복구 계획에서 UTC 자정을 기다리는 절차를 없애는 데 있습니다.

한 계정에서 여러 데이터베이스를 관리하는 에이전시

한도는 계정 단위로 적용됩니다. 에이전시 운영자는 고객사 한 곳만 살펴보고 계정이 안전하다고 판단해서는 안 되며, 해당 Cloudflare 계정의 모든 D1 데이터베이스를 목록으로 정리해야 합니다.

데이터베이스별 지표로 사용량이 유독 큰 프로젝트를 찾은 다음, 계정 예산을 정하기 전에 전체 수치를 합산하십시오. 운영팀이 책임지고 관리할 수 있는 공통 기준을 만드는 것이 핵심입니다. 한 프로젝트의 비효율적인 스캔 때문에 같은 계정의 다른 서비스에서 원인을 알 수 없는 장애가 발생해서는 안 됩니다.

비싼 읽기 작업을 추적하는 백엔드 엔지니어

해야 할 일은 데이터를 무작정 지우는 것이 아니라 비용이 큰 쿼리 형태를 찾아내는 것입니다. D1은 각 쿼리의 rows_read와 rows_written을 meta 객체 안에 반환합니다. 이 값으로 쿼리 1회 실행에 든 정확한 비용을 알 수 있습니다.

Cloudflare는 Wrangler와 GraphQL Analytics API를 통해 쿼리 인사이트도 제공합니다. 읽기 수를 기준으로 정렬해 반복되는 스캔을 찾고, 실행 계획을 확인한 뒤 필요한 범위에만 인덱스를 추가하고 다시 측정하십시오. 같은 수정으로 할당량 사용량과 지연 시간을 함께 줄일 수 있습니다.

가져오기 또는 동기화 작업을 담당하는 운영 책임자

대량 동기화 작업이 쓰기 100,000건을 먼저 소진하면 고객 트래픽은 데이터베이스를 사용할 기회조차 얻지 못할 수 있습니다. 긴급하지 않은 작업은 초기화 구간에 걸쳐 속도를 조절하거나, 프로덕션 가져오기 작업 전에 계정을 Paid로 전환하십시오.

쓰기 한도에 도달한 뒤 정리하면 된다고 계획해서는 안 됩니다. DELETE 자체도 쓰기 작업이므로 같은 허용량이 이미 소진됐다면 초기화 전까지 정리 쿼리마저 차단될 수 있습니다. 배치 작업이 실행되는 동안 실제 서비스의 쓰기 여유를 지키는 것이 중요합니다.

경보가 오기 전에 Cloudflare D1 무료 한도 예산부터 세우십시오

처음 적용하기 좋은 운영 기준은 다음과 같습니다. Cloudflare의 요구사항이 아니라 운영자를 위한 규칙으로, 프로덕션 예산을 공개된 Free 허용량의 80%로 잡습니다. 그러면 일일 운영 상한은 읽기 400만 건과 쓰기 80,000건이 되고, 트래픽 급증과 측정 지연에 대비해 읽기 100만 건과 쓰기 20,000건을 남겨 둘 수 있습니다.

1. 1

   실제 하루 사용량을 측정합니다

   Cloudflare에서 D1으로 이동해 각 데이터베이스를 선택한 다음 Metrics를 여십시오. 기본 화면에는 최근 24시간이 표시됩니다. 평일의 일반적인 사용량뿐 아니라 출시, 가져오기 작업, 트래픽 급증까지 파악할 수 있도록 충분한 기간의 기록을 확인하십시오. D1은 이 지표를 31일 동안 보관합니다.

2. 2

   행을 가장 많이 소비하는 쿼리를 찾습니다

   중요한 경로를 테스트할 때 쿼리별 meta.rows_read와 meta.rows_written 값을 확인하십시오. 쿼리 인사이트로 실행 빈도가 높거나 비용이 큰 구문부터 정렬합니다. 읽기 비용이 가장 큰 쿼리에 EXPLAIN QUERY PLAN을 실행하고, 플랜 업그레이드만 답으로 보기 전에 전체 스캔부터 해결하십시오.

3. 3

   강제 중단 전에 경보를 보냅니다

   대시보드와 같은 데이터 세트를 읽는 GraphQL Analytics API로 계정 단위의 예약 점검을 구성하십시오. 읽기 400만 건 또는 쓰기 80,000건에 도달하면 담당자에게 알립니다. 한도에 꽉 찼을 때 오는 Cloudflare 이메일도 장애 확인에는 유용하지만, 프로덕션의 첫 신호가 되어서는 안 됩니다.

4. 4

   실패 시 동작을 미리 정합니다

   D1이 한도 오류를 반환할 때 Worker가 무엇을 응답할지 결정하십시오. D1 쿼리를 추가로 실행하지 않는다면 캐시된 읽기 결과는 계속 유용할 수 있습니다. 쓰기 경로에는 명확한 이용 불가 응답이나 별도로 설계한 큐가 필요합니다. UTC 자정 또는 업그레이드 전에는 회복될 수 없는 할당량을 상대로 재시도를 반복하지 마십시오.

D1 지표 문서는 GraphQL 필드 이름이 rowsRead와 rowsWritten이라고 명시하고, 대시보드도 같은 분석 데이터를 사용한다고 설명합니다. 따라서 소규모 팀은 지금 바로 쓸 수 있는 수동 확인 경로와, 데이터베이스가 호출 담당자를 둘 만큼 중요해졌을 때 자동화할 경로를 모두 확보할 수 있습니다.

해결책에도 분명한 한계가 있습니다

인덱스도 공짜가 아닙니다. 스토리지를 사용하며 인덱싱된 값이 바뀔 때 쓰기 작업을 추가합니다. 비용이 큰 스캔을 없애는 인덱스만 추가한 뒤 읽기와 쓰기의 새 균형을 측정하십시오. 이미 쓰기 100,000건 한도에 가까운 계정이라면 무분별한 인덱싱이 잘못된 선택이 될 수 있습니다.

Paid 역시 무제한은 아닙니다. 월 읽기 250억 건과 쓰기 5,000만 건이 포함되며, 이를 넘으면 공개된 요율로 초과 요금이 청구됩니다. 업그레이드하면 대개 몇 분 안에 Free의 일일 중단은 해제되지만, 비효율적인 쿼리를 감시하거나 나머지 Workers 비용을 예측할 필요까지 사라지는 것은 아닙니다. 운영 문서에는 Cloudflare의 현재 D1 요금 페이지를 수치 기준표로 남겨 두는 편이 좋습니다.

출처의 시간 순서에는 알아 둘 만한 변수가 하나 있습니다. 2025년 1월 D1 릴리스 노트에는 2025년 2월 10일부터 한도 적용을 시작한다고 적혀 있었습니다. 그러나 더 최근의 해당 이벤트 전용 변경 로그는 시작일을 2026년 9월 1일로 명시합니다. 여기서는 현재 적용 일정을 직접 지목한 최신 페이지를 기준으로 삼았습니다. 오래된 검색 결과에 다른 날짜가 나올 수 있는 이유입니다.

마지막으로 “저장된 데이터에는 영향이 없다”는 말의 범위는 “제품에 아무 문제가 없다”보다 훨씬 좁습니다. 데이터가 안전하게 남아 있어도 그 데이터를 필요로 하는 모든 경로에서 오류가 날 수 있습니다. 비즈니스에 직접 영향을 주는 것은 가용성입니다.

Cloudflare D1 쿼리 제한에 대비해 월요일에 할 일

고객이 사용하는 애플리케이션이 Workers Free에서 실행되고 요청 경로에 D1이 있다면 이번 주에 조치하십시오. 먼저 측정하고, 명백한 전체 스캔을 해결하고, 읽기 400만 건과 쓰기 80,000건 경보를 설정한 뒤 월 $5의 Paid 전환을 사전 승인해 두십시오.

폐기해도 되는 프로토타입이고, 31일 기록이 운영 예산보다 충분히 낮으며, 하루 동안 쿼리가 실패해도 고객이나 매출에 영향이 없다면 기다려도 됩니다. 다만 트래픽과 테이블 크기가 모두 읽기 계산을 바꾸므로 경보는 그대로 유지하십시오.

계정이 이미 Workers Paid를 사용 중이거나 애플리케이션이 D1을 조회하지 않는다면 이번 일일 중단 규칙의 영향을 받지 않습니다.

월요일의 실행 항목은 간단합니다. 모든 데이터베이스에서 D1 Metrics 탭을 열고, 계정의 일일 읽기·쓰기 최고치를 기록하고, 가장 큰 스캔을 일으킨 쿼리를 찾고, 한 사람에게 업그레이드 권한을 부여하십시오. 쿼리를 수정한 뒤에도 평상시 최고치가 읽기 400만 건 또는 쓰기 80,000건을 넘는다면 그날 바로 계정을 Workers Paid로 전환합니다.

다음 플랫폼 변경도 운영 관점의 판단으로 정리해 받아보려면 뉴스레터를 구독하십시오.