D1 비용 계산, 조회 결과보다 스캔한 행을 봐야 하는 이유

D1은 조회 결과로 돌려준 행만 세어 비용을 판단하지 않습니다. 읽기 사용량은 쿼리가 스캔한 행을 기준으로 측정합니다. 따라서 화면에 표시된 결과 개수와 요청 수만으로는 운영비를 계산하기 어렵습니다. 읽은 행·쓴 행·저장량을 따로 기록하고, Workers 실행 비용까지 별도로 확인하는 입력표가 필요합니다.

결과 목록은 비용 영수증이 아니었어요

화면에 결과가 적게 나오면 데이터베이스도 적게 일했을 것 같습니다. 하지만 결과를 찾는 과정에서 얼마나 많은 행을 살폈는지는 화면만으로 알 수 없습니다.

저는 이 차이를 비용표의 출발점으로 잡았습니다. 사용자에게 보인 결과와 데이터베이스가 처리한 작업을 다른 칸에 적는 방식입니다. 결과 개수는 서비스 동작을 설명하지만, 그 값이 곧 D1 읽기 사용량은 아닙니다.

공식 요금표 확인일은 2026-09-09입니다. Cloudflare 공식 D1 요금 문서에 따르면 과금 판단 항목은 읽은 행, 쓴 행, 저장량입니다. 이 글은 해당 문서에 근거한 구매 판단 자료이며, 운영 환경에서 수행한 비용 실험은 아닙니다.

현재 D1 무료 한도와 요금

아래는 2026-09-09에 확인한 D1 요금과 한도입니다. D1에 해당하는 수치만 정리한 것이며, Workers 실행 비용과 기본 플랜은 별도로 봐야 합니다.

플랜	읽기	쓰기	저장량
Free	하루 5,000,000행	하루 100,000행	총 5 GB
Workers Paid D1	월 25,000,000,000행 포함, 이후 1,000,000행당 초과분 $0.001	월 50,000,000행 포함, 이후 1,000,000행당 초과분 $1.00	5 GB 포함, 이후 GB-month당 초과분 $0.75

읽기 초과분은 1,000,000행당 $0.001이고, 쓰기 초과분은 1,000,000행당 $1.00입니다. Free의 하루 D1 한도를 소진하면 쿼리 오류가 반환됩니다. Workers Paid 사용량은 별도의 D1 한도와 요금으로 청구되며, Workers 실행 비용과 기본 플랜은 별도입니다.

요약은 다음과 같습니다.

• 읽기 사용량은 반환된 결과 개수가 아니라 스캔한 행을 기준으로 봅니다.
• 요청 수, 읽은 행, 쓴 행, 저장량은 서로 다른 입력값입니다.
• D1 사용량과 Workers 실행 비용을 분리해야 운영비 판단이 가능합니다.

화면에 적게 나왔다는 사실만으로 적게 읽었다고 판단할 수는 없습니다.

요청이 있었다는 사실과 읽은 양은 달랐어요

요청 수는 기능이 얼마나 호출됐는지 살펴볼 때 유용합니다. 하지만 요청 횟수를 그대로 읽은 행으로 옮기면 단위부터 맞지 않습니다. 쿼리 실행 횟수 역시 스캔한 행의 개수와는 다른 값입니다.

D1 측정 문서에서는 쿼리 메타데이터의 rows_read와 rows_written을 확인할 수 있습니다. 각각 읽기와 쓰기 사용량을 파악하는 근거이며, 요청 수나 쿼리 수를 대신 부르는 이름이 아닙니다.

이 구분 덕분에 “호출은 확인됐지만 처리량은 아직 모른다”는 상태를 그대로 남길 수 있습니다. 모르는 값을 예상치로 채우는 순간 표는 깔끔해집니다. 다만 구매 판단의 근거는 오히려 흐려집니다.

복사할 비용표에는 빈칸도 필요했어요

아래 표는 계산 결과가 아니라 실제 사용량을 모으기 위한 입력 양식입니다. 관측 기간과 환경이 다른 값을 섞지 않도록 기록 조건도 함께 둡니다.

입력 항목	기록할 값	확인 근거와 주의점
관측 조건	날짜·기간·실행 환경·프로젝트 설정: 미확인	어떤 조건의 기록인지 보존
요청 수	기능별 요청 횟수: 미확인	읽은 행으로 환산하지 않음
쿼리 수	기능별 실행 횟수: 미확인	요청 수와도 구분
읽은 행	rows_read 합계: 미확인	반환 결과 개수로 대체하지 않음
쓴 행	rows_written 합계: 미확인	인덱스가 미치는 영향도 확인
저장량	실제 저장량과 측정 시점: 미확인	요청 횟수에서 추정하지 않음
Workers 실행	실행 사용량·적용 요금: 미확인	D1 사용량과 별도로 산정
적용 요금 조건	공식 요금표 확인일·플랜·단위: 미확인	해당 조건을 사용량에 적용

금액을 계산할 때는 실제 플랜과 사용량을 위 요금 단위에 대입해야 합니다. 이 글은 특정 프로젝트의 실제 사용량이나 예상 청구액을 제시하지 않습니다.

무료 여부도 이 표만으로 확정되지 않습니다. 무료라고 보장할 수 없다는 말과 반드시 유료라는 말은 다릅니다. 현재 조건에 실제 사용량을 대입하기 전까지 판단을 유보한다는 뜻입니다.

인덱스는 읽기 칸에서만 끝나지 않았어요

가상의 사용 시나리오로, 행사 목록을 조회하는 앱을 생각해 봅니다. 조건에 맞는 결과만 화면에 표시돼도 그 결과를 찾기 위해 스캔한 양은 따로 확인해야 합니다. 이는 설명용 예시이며 실제 앱의 측정 기록이 아닙니다.

인덱스는 읽기와 쓰기 사용량에 영향을 줄 수 있습니다. 따라서 인덱스를 추가했다는 사실만으로 전체 비용이 줄었다고 결론 내리기는 어렵습니다. 같은 조회 조건에서 읽은 행을 비교하고, 데이터를 기록하거나 변경하는 동작의 쓴 행도 함께 봐야 판단 근거가 생깁니다.

[비교 도식 캡션: 요청 → 쿼리 실행 → 스캔한 행 → 반환 결과의 관계. 쓰기 사용량·저장량·Workers 실행은 별도 비용 입력으로 표시.]

읽기 사용량의 변화와 전체 운영비의 변화는 따로 확인할 대상입니다.

확인한 기준과 아직 확인하지 못한 금액

검증 과정은 공식 요금 문서에서 과금 항목을 확인하고, 측정 문서에서 대응하는 메타데이터를 찾은 뒤, 실행 비용과 구분하는 순서로 정리했습니다.

여기까지 확인된 것은 무엇을 세어야 하는가입니다. 특정 프로젝트에서 얼마가 청구되는지, 인덱스로 얼마나 절약되는지, 어떤 설정이 가장 저렴한지는 확인되지 않았습니다. 테스트 날짜 대신 문서 근거 확인일을 적은 이유도 여기에 있습니다.

재사용할 점검 항목은 짧게 남겼습니다.

• 관측 기간과 실제 런타임·프로젝트 설정이 기록돼 있다.
• 요청 수와 쿼리 수를 행 사용량으로 대체하지 않았다.
• 읽은 행·쓴 행·저장량의 근거가 각각 있다.
• Workers 실행과 현재 공식 요금 조건을 별도로 확인했다.

소스 구매 판단에도 같은 빈칸이 남아요

선택적 사례인 사주 웹앱 소스 라이선스는 개발자가 단일 프로젝트에 사용하는 소스 상품입니다. 현재 가격·제공물·설치 조건의 근거는 제품 페이지입니다.

다만 상품 설명만으로 구매자의 운영비나 설치 성공을 알 수는 없습니다. 모든 런타임과의 호환성도 추론할 수 없습니다. 소스 구매 조건을 확인하는 일과 내 환경의 실행 비용을 계산하는 일은 별개로 남습니다.

제 판단은 단순합니다. 조회 결과 개수만 있는 상태라면 비용 판단의 입력이 부족합니다. 구매 전 별도 지출 없이 시작할 수 있는 행동은 위 표를 복사해, 보유한 사용량 근거와 미확인 칸을 나누는 것입니다.

이어지는 기록

• Next.js 환경변수 공개 검사표: 접두사와 빌드 시점을 함께 보는 이유

재사용 체크리스트.

• 입력과 기대 결과를 적어요.
• 출처·불확실성·사람 검토 항목을 표시해요.
• 수동 대안과 중단 기준을 남겨요.