릴리스 노트 (Release notes)
출처: 문서
본문
2025-11-05
D1에서 데이터 지역화를 위한 관할 구역을 설정할 수 있어요. 이제 D1 데이터베이스를 생성할 때 관할 구역을 설정해서 데이터베이스가 실행되고 데이터를 저장하는 위치를 보장할 수 있어요.
2025-09-11
D1이 읽기 전용 쿼리를 자동으로 재시도해요. 이제 D1은 읽기 전용 쿼리를 감지해서, 재시도 가능한 오류로 실패하는 경우 해당 쿼리를 최대 두 번까지 자동으로 실행하려 시도해요. 반환되는 응답 메타데이터의 total_attempts 속성에서 실행 시도 횟수를 확인할 수 있어요.
현재는 읽기 전용 쿼리, 즉 다음 SQLite 키워드만 포함하는 쿼리만 재시도돼요: SELECT, EXPLAIN, WITH. 데이터베이스 쓰기를 유발하는 SQLite 키워드를 포함하는 쿼리는 재시도되지 않아요.
읽기 전용 재시도 가능 오류의 재시도 성공 비율은 기반 오류와 그 지속 시간(네트워크 오류나 기타 내부 오류 등)에 따라 5%에서 최대 95%까지 달라져요.
모든 재시도 가능 오류 중 재시도 성공 비율은 더 낮은데, 이는 재시도될 수 있는 쓰기 쿼리가 있음을 나타내요. 따라서 D1 사용자에게는 읽기 전용이 아니지만 애플리케이션의 비즈니스 로직상 멱등(idempotent)한 쿼리에 대해 자신의 코드에서 재시도를 계속 적용할 것을 권장해요.
D1은 어떤 재시도 시도도 데이터베이스 쓰기를 일으키지 않도록 보장해요. 이 덕분에 자동 재시도는 부작용으로부터 안전해요. 설령 변경을 일으키는 쿼리가 읽기 전용 감지를 통과한다 해도 말이죠. D1은 매 쿼리 실행 후 수정 여부를 확인하고, 재시도 시도로 인해 쓰기가 발생했으면 해당 쿼리를 롤백해요.
지금은 읽기 전용 쿼리 감지 휴리스틱이 단순하며, 재시도 가능한 쿼리의 더 많은 사례를 포착하도록 개선할 여지가 있어요. 그래서 이건 시작에 불과해요.
2025-07-01
Workers 유료 플랜의 계정당 최대 D1 저장 용량이 이제 1 TB예요. Workers 유료 플랜 사용자의 계정당 최대 D1 저장 용량이 250 GB에서 1 TB로 늘어났어요.
2025-07-01
D1 알파 데이터베이스 백업 접근이 제거됐어요. 2024-08-23에 D1 알파 데이터베이스에 대한 쿼리 접근이 제거된 데 이어, D1 알파 데이터베이스 백업은 더 이상 wrangler d1 backup(wrangler v3에서 사용 가능)으로 접근하거나 만들 수 없어요.
D1 알파 데이터베이스의 백업을 유지하려면 2025-07-01 이전에 wrangler d1 backup을 사용하세요. D1 알파 백업은 일반 공급(GA) 상태의 새로 만든 D1 데이터베이스로 마이그레이션하는 데 사용할 수 있어요.
2025-05-30
D1 REST API 요청이 50-500ms 빨라져요. Cloudflare REST API로 D1 데이터베이스를 쿼리하는 사용자는 이제 종단 간 요청 지연 시간이 줄어들어요. D1 인증이 요청을 받은 가장 가까운 Cloudflare 네트워크 데이터 센터에서 수행되기 때문이에요. 이전에는 인증을 위해 D1 REST API 요청이 Cloudflare의 핵심 중앙 데이터 센터로 프록시되어 네트워크 왕복과 지연 시간이 추가됐어요.
지연 시간 개선은 요청 위치와 데이터베이스 위치에 따라 50-500ms 범위이며 REST API에만 적용돼요. Cloudflare의 주요 핵심 데이터 센터가 미국에 있기 때문에 미국 밖의 REST API 요청과 데이터베이스가 더 큰 이점을 보게 돼요.
/query와 /raw 같은 D1 쿼리 엔드포인트는 더 이상 Cloudflare 핵심 데이터 센터에 접근하지 않으므로 가장 눈에 띄는 개선이 있어요. 데이터베이스 생성·삭제 같은 D1 제어 플레인 엔드포인트는 다른 제어 플레인 메타데이터를 위해 여전히 Cloudflare 핵심 데이터 센터에 접근해야 하므로 개선 폭이 더 작아요.
2025-05-02
D1 HTTP API 권한 버그 수정. D1:Read 권한과 다른 Cloudflare 제품에 대한 Edit 권한을 가진 Cloudflare 계정 및 사용자 API 토큰이 D1 데이터베이스 쓰기를 수행할 수 있게 했던 권한 버그가 수정됐어요. HTTP API를 통한 모든 데이터베이스 쓰기에는 D1:Edit 권한이 필요해요.
D1:Edit 권한 없이 기존 API 토큰으로 HTTP API를 통해 D1 데이터베이스를 수정하고 있었다면, API 토큰을 만들거나 편집해 D1:Edit 권한을 명시적으로 포함시켜야 해요.
2025-04-10
D1 읽기 복제 공개 베타. D1 읽기 복제가 공개 베타로 제공돼요. 이커머스 웹사이트나 콘텐츠 관리 도구 같은 읽기 중심 애플리케이션의 평균 지연 시간을 낮추고 전반적인 처리량을 높이는 데 도움이 돼요.
Workers는 D1 Sessions API를 사용해 읽기 복제본(read replica)이라고 하는 읽기 전용 데이터베이스 복사본을 활용할 수 있어요. 세션(session)은 애플리케이션의 하나의 논리적 세션에서 오는 모든 쿼리를 캡슐화해요. 예를 들어 세션은 특정 웹 브라우저 세션에서 오는 모든 쿼리에 해당할 수 있어요. Sessions API를 사용하면 세션 안의 D1 쿼리는 데이터 일관성 함정을 피하기 위해 순차적 일관성(sequentially consistent)을 보장받아요. 이전 세션의 D1 북마크를 사용하면 세션 간 논리적 일관성을 보장할 수 있어요.
// retrieve bookmark from previous session stored in HTTP header
const bookmark = request.headers.get("x-d1-bookmark") ?? "first-unconstrained";
const session = env.DB.withSession(bookmark);
const result = await session
.prepare(`SELECT * FROM Customers WHERE CompanyName = 'Bs Beverages'`)
.run();
// store bookmark for a future session
response.headers.set("x-d1-bookmark", session.getBookmark() ?? "");
읽기 복제본은 Cloudflare가 자동으로 만들고(현재 지원되는 각 D1 지역에 하나씩), 쿼리 트래픽에 따라 활성/비활성 상태가 되며, 추가 비용 없이 Cloudflare가 투명하게 라우팅해요.
D1 읽기 복제를 체험하려면 Sessions API를 사용하는 다음 Worker 코드를 배포하세요. 그러면 D1 데이터베이스를 만들고 해당 데이터베이스에서 읽기 복제를 활성화하라는 안내가 나와요.
읽기 복제가 어떻게 구현됐는지 자세히 알아보려면 블로그 포스트를 참고하세요.
2025-02-19
D1이 PRAGMA optimize를 지원해요. D1은 이제 데이터베이스 쿼리 성능을 개선할 수 있는 PRAGMA optimize 명령을 지원해요. 스키마 변경 후(예: 인덱스 생성 후) 이 명령을 실행하는 것을 권장해요. 자세한 내용은 PRAGMA optimize 문서를 참고하세요.
2025-02-04
D1의 UI 및 /query REST API를 통한 읽기 전용 접근 버그를 수정했어요. UI에서 읽기 전용 역할을 가진 사용자와 /query REST API에서 읽기 전용 API 토큰을 가진 사용자가 데이터베이스를 수정하는 쿼리를 실행할 수 있게 했던 D1 권한 버그를 수정했어요. Tables 탭을 통한 UI 작업(테이블 생성·삭제 등)은 읽기 전용 접근으로 잘못 허용됐어요. 그러나 Console 탭을 통한 UI 작업은 이 버그의 영향을 받지 않았고 쓰기 접근을 올바르게 요구했어요.
이제 읽기 전용 접근으로 쓰기 쿼리를 실행하면 실패해요. 이전의 잘못된 동작에 의존하고 있었다면, D1 쓰기 쿼리를 수행하도록 사용자에게 올바른 역할을 할당하거나 API 토큰에 올바른 권한을 부여하세요.
2025-01-13
D1이 2025년 2월 10일부터 무료 티어 한도를 적용하기 시작해요. D1은 2025-02-10부터 일일 무료 티어 한도를 적용하기 시작할 거예요. 이 한도는 Workers Free 플랜의 계정에만 적용돼요.
2025-02-10부터 어떤 조치도 취하지 않고 일일 무료 티어 한도를 초과하면, Workers API 및/또는 REST API를 통한 D1 데이터베이스 쿼리는 매일 00:00 UTC에 한도가 초기화될 때까지 오류를 반환해요.
중단 없는 서비스를 보장하려면 플랜 페이지에서 계정을 Workers Paid 플랜으로 업그레이드하세요. 월 최소 청구 금액은 $5예요. Workers Paid 플랜과 D1 한도 문서를 참고하세요.
현재 사용량을 더 잘 파악하려면 D1 대시보드나 GraphQL API에서 찾을 수 있는 읽은 행과 쓴 행에 대한 청구 지표를 참고하세요.
2025-01-07
D1 Worker API 요청 지연 시간이 40-60% 줄어들어요. D1은 각 요청에 대한 중복 네트워크 왕복을 제거해 종단 간 Worker API 요청 지연 시간을 40-60% 낮췄어요.
p50, p90, p95 요청 지연 시간은 전체 D1 서비스에 걸쳐 집계된 값이에요. 이 지연 시간은 참고 지점이며 여러분의 정확한 워크로드 개선으로 보지 말아야 해요.
D1 데이터베이스에 대한 각 요청에서 최소 두 번의 네트워크 왕복이 제거됐어요. 한 번의 왕복은 지금은 수정된 버그 때문이었어요. 나머지 제거된 왕복은 데이터베이스를 호스팅하는 데이터 센터에 도달할 때 각 요청마다 새 TCP 연결을 만드는 것을 피했기 때문이에요.
중복 네트워크 왕복 제거는 D1의 REST API에도 적용돼요. 그러나 REST API는 여전히 인증을 위해 Cloudflare의 중앙 데이터 센터에 의존하므로 상대적인 성능 개선 폭이 줄어들어요.
2024-08-23
D1 알파 데이터베이스가 SQL 쿼리 수용을 중단했어요. 2024-04-30의 지원 중단 경고에 따라, D1 알파 데이터베이스는 쿼리 수용을 중단했어요(백업은 여전히 만들고 검색할 수 있어요).
D1 알파 데이터베이스에 대한 요청은 이제 다음 텍스트를 포함한 HTTP 400 오류로 응답해요:
You can no longer query a D1 alpha database. Please follow https://developers.cloudflare.com/d1/platform/alpha-migration/ to migrate your alpha database and resume querying.
알파 데이터베이스 마이그레이션 가이드를 따라 새롭고 일반 공급되는 버전의 D1로 업그레이드할 수 있어요.
2024-07-26
run() API의 TypeScript 타입 정의 버그를 수정했어요. D1 Client API의 run() 메서드는 잘못된(오래된) 타입 정의를 갖고 있었는데, @cloudflare/workers-types 버전 4.20240725.0부터 해결됐어요.
올바른 타입 정의는 stmt.run<T>(): D1Result이에요. run()은 쿼리의 결과 행을 반환하기 때문이에요. 이전의 잘못된 타입 정의는 stmt.run(): D1Response였는데, 쿼리 메타데이터만 반환하고 결과는 없었어요.
2024-06-17
과부하된 D1 데이터베이스에 대해 HTTP API가 이제 HTTP 429 오류를 반환해요. 이전에 D1의 HTTP API는 데이터베이스가 과부하된 동안 들어온 쿼리에 대해 HTTP 500 Internal Server 오류를 반환했어요. 이제 이러한 요청은 올바르게 HTTP 429 Too Many Requests 오류를 반환해요.
D1의 Workers API는 이 변경의 영향을 받지 않아요.
2024-04-30
D1 알파 데이터베이스가 2024년 8월 15일에 실시간 SQL 쿼리 수용을 중단해요. 이전에 지원 중단된 알파 D1 데이터베이스는 새 쿼리를 수용하려면 2024년 8월 15일까지 마이그레이션해야 해요.
새롭고 일반 공급되는 데이터베이스 아키텍처로 마이그레이션하려면 알파 데이터베이스 마이그레이션 가이드를 참고하세요.
2024-04-12
잘못된 쿼리에 대해 HTTP API가 이제 HTTP 400 오류를 반환해요. 이전에 D1의 HTTP API는 잘못된 쿼리에 대해 HTTP 500 Internal Server 오류를 반환했어요. 이제 잘못된 SQL 쿼리는 올바르게 HTTP 400 Bad Request 오류를 반환해요.
D1의 Workers API는 이 변경의 영향을 받지 않아요.
2024-04-05
D1 알파 데이터베이스가 지원 중단됐어요. D1이 일반 공급되고 프로덕션 준비가 되었으므로, 알파 D1 데이터베이스는 지원 중단되고 더 나은 성능, 신뢰성, 지속적인 지원을 위해 마이그레이션해야 해요.
새롭고 일반 공급되는 데이터베이스 아키텍처로 마이그레이션하려면 알파 데이터베이스 마이그레이션 가이드를 참고하세요.
2024-04-01
D1이 일반 공급(GA)됐어요. D1은 이제 일반 공급되고 프로덕션 준비가 됐어요. GA의 새 기능에 대한 자세한 내용과 다가오는 D1 읽기 복제 API에 대해 알아보려면 블로그 포스트를 읽어 보세요.
-
Workers Paid 플랜 개발자는 이제 데이터베이스당 10GB 한도(2GB에서 증가)를 가지며, 기존의 계정당 50,000개 데이터베이스 한도와 결합할 수 있어요.
-
Workers Free 플랜 개발자는 데이터베이스당 500 MB 한도를 유지하고 계정당 최대 10개 데이터베이스를 만들 수 있어요.
-
D1 데이터베이스는 SQL 파일로 내보낼 수 있어요.
2024-03-12
wrangler d1 execute 기본값 변경. wrangler@3.33.0부터 wrangler d1 execute와 wrangler d1 migrations apply는 이제 wrangler dev의 기본 동작에 맞춰 기본적으로 로컬 데이터베이스를 사용해요.
이제 --local 또는 --remote 중 하나를 지정해 wrangler에 어떤 환경에 대해 명령을 실행할지 명시적으로 알릴 수도 있어요.
2024-03-05
D1 사용량 청구. 2024-03-05부터 D1 사용량이 집계되기 시작하며 계정의 향후 청구 주기에 비용이 발생할 수 있어요.
포함 한도를 초과하는 D1 사용량이 있는 Workers Paid 플랜 개발자는 D1 요금에 따라 비용이 발생해요.
Workers Free 플랜 개발자는 포함 한도까지 사용할 수 있어요. 아래 한도를 초과하는 사용량은 $5/월 Workers Paid 플랜에 가입해야 해요.
계정 청구 가능 지표는 Cloudflare Dashboard와 GraphQL API에서 확인할 수 있어요.
2024-02-16
run()의 API 변경. 2024-02-13에 이루어진 run() 쿼리 문 메서드에 대한 이전 변경이 되돌려졌어요.
run()은 이제 결과 행을 포함한 D1Result를 반환하며, 2024-02-13 변경 이전의 원래 동작과 일치해요.
원래 의도되고 문서화된 것처럼 run()이 D1ExecResult를 반환하도록 하는 향후 변경은, 현재 run()이 작동하는 방식에 의존하는 기존 Workers를 깨지 않도록 호환성 날짜 뒤에 게이트될 거예요.
2024-02-13
raw(), all(), run()의 API 변경. D1의 raw(), all(), run() 쿼리 문 메서드가 의도된 동작을 반영하고 ORM 라이브러리와의 호환성을 개선하도록 업데이트됐어요.
raw()는 이제 배열의 배열(array of arrays)로 결과를 올바르게 반환해요. 이렇게 하면 (테이블 조인 시와 같은) 중복 열 이름을 올바르게 처리할 수 있어요. 반면 all()은 변경 없이 객체 배열을 반환해요. raw()를 사용할 때 결과에 열 이름 배열을 포함하려면 raw({columnNames: true})를 사용하세요.
run()은 더 이상 잘못된 D1Result를 반환하지 않고, 원래 의도되고 문서화된 대로 D1ExecResult를 반환해요.
이는 raw()가 객체 배열을 반환할 것으로 기대했던 일부 애플리케이션에는 호환성이 깨지는 변경일 수 있어요.
D1의 쿼리 메서드, 반환 타입, TypeScript 지원에 대한 자세한 내용은 D1 client API 문서를 참고하세요.
2024-01-18
UPDATE 및 DELETE 문에 대한 LIMIT 지원. D1은 이제 UPDATE와 DELETE 문에 LIMIT 절을 추가하는 것을 지원해요. 이를 통해 잠재적으로 위험한 작업의 영향을 제한할 수 있어요.
2023-12-18
레거시 알파 자동 백업 비활성화. D1의 레거시 알파 백엔드를 사용하는 데이터베이스는 더 이상 자동 시간별 백업을 실행하지 않아요. 이 데이터베이스의 수동 백업은 여전히 만들 수 있어요.
D1 팀은 D1의 새로운 프로덕션 백엔드로 이동할 것을 권장해요. 이렇게 하려면 기존 데이터를 내보내고 가져와야 해요. D1의 프로덕션 백엔드는 원래 알파 백엔드보다 빠르며, 새 백엔드는 시간별 또는 수동 스냅샷에 의존하지 않고 지난 30일의 어느 순간으로든 데이터베이스를 복원할 수 있는 Time Travel을 지원해요.
2023-10-03
최대 50,000개의 D1 데이터베이스 생성. Workers Paid 플랜에서 D1을 사용하는 개발자는 이제 D1의 한도에 대한 지속적인 증가의 일환으로 최대 50,000개의 데이터베이스를 만들 수 있어요.
-
이는 사용자당 데이터베이스(user-per-database) 사용 사례를 더욱 가능하게 하고 고객 간 데이터를 격리할 수 있게 해 줘요.
-
계정당 총 저장 용량은 이제 50 GB예요.
-
D1의 분석 및 지표는 데이터베이스별 사용량 데이터를 제공해요.
50,000개 이상의 데이터베이스를 만들어야 하거나 계정당 저장 용량이 더 필요하다면 D1 팀에 문의하세요.
2023-09-28
D1 공개 베타가 시작됐어요. D1이 공개 베타로 전환됐고 저장 한도가 늘어났어요:
-
Workers Paid 플랜 개발자는 이제 데이터베이스당 2 GB 한도(500 MB에서 증가)를 가지며 계정당 25개 데이터베이스를 만들 수 있어요(10개에서 증가). 이러한 한도는 공개 베타 기간 동안 자동으로 계속 늘어날 거예요.
-
Workers Free 플랜 개발자는 데이터베이스당 500 MB 한도를 유지하고 계정당 최대 10개 데이터베이스를 만들 수 있어요.
늘어난 데이터베이스 한도의 이점을 얻으려면 데이터베이스가 D1의 새 스토리지 하위 시스템을 사용해야 해요.
베타의 새로운 기능과 D1의 미래에 대한 자세한 내용은 공지 블로그를 읽어 보세요.
2023-08-19
이제 쿼리별로 행 수가 반환돼요. D1은 이제 실행되는 모든 쿼리에 대해 rows_written과 rows_read의 수를 반환하며, 이를 통해 요금과 인덱스 최적화 목적 모두에서 쿼리 비용을 평가할 수 있어요.
D1 Client API에서 반환되는 meta 객체에는 해당 쿼리가 읽은(rows_read) 행과 쓴(rows_written) 행의 총 수가 포함돼요. 예를 들어 5,000개의 행이 있는 테이블에서 전체 테이블 스캔(예: SELECT * FROM users)을 수행하는 쿼리는 rows_read 값 5000을 반환해요:
"meta": {
"duration": 0.20472300052642825,
"size_after": 45137920,
"rows_read": 5000,
"rows_written": 0
}
읽기와 쓰기가 어떻게 측정되는지 이해하려면 D1 요금 문서를 참고하세요. D1은 알파 기간 동안 계속 무료로 사용할 수 있어요.
2023-08-09
Cloudflare 대시보드에서 D1 바인딩. 이제 Cloudflare 대시보드에서 직접 D1 데이터베이스를 Workers에 바인딩할 수 있어요. Cloudflare 대시보드에서 D1을 바인딩하려면 Worker 프로젝트를 선택하고 -> Settings -> Variables -> D1 Database Bindings를 선택하세요.
참고: 이전에 3.5.0 이전 버전의 wrangler로 D1 데이터베이스 바인딩이 있는 Worker를 배포했다면, Cloudflare 대시보드에서 D1 데이터베이스 바인딩을 편집하기 전에 먼저 wrangler v3.5.0으로 업그레이드해야 해요. 새 Workers 프로젝트에는 이 제한이 없어요.
이전에 데이터베이스 바인딩을 수동으로 __D1_BETA__ 접두사로 시작한 레거시 D1 알파 사용자는 이 업그레이드의 일환으로 이를 제거해야 해요. Worker 스크립트는 env.BINDING_NAME으로만 D1 데이터베이스를 호출해야 해요. 모범 사례는 최신 D1 시작하기 가이드를 참고하세요.
개선된 TypeScript 타입과 향후 D1 API 개선의 이점을 누리기 위해 모든 D1 알파 사용자가 wrangler 3.5.0(이상)을 사용하기 시작할 것을 권장해요.
2023-08-01
데이터베이스당 한도가 이제 500 MB예요. D1의 새 스토리지 하위 시스템을 사용하는 데이터베이스는 이제 각각 기존 100 MB 한도에서 500 MB까지 커질 수 있어요. 이는 기존 데이터베이스와 새로 만든 데이터베이스 모두에 적용돼요.
D1의 한도에 대해 알아보려면 Limits 문서를 참고하세요.
2023-07-27
새 기본 스토리지 하위 시스템. Cloudflare 대시보드와 Wrangler(v3.4.0부터)를 통해 만든 데이터베이스는 이제 기본적으로 D1의 새 스토리지 하위 시스템을 사용해요. 새 백엔드는 D1의 원래 알파 백엔드보다 6-20배 빠를 수 있어요.
데이터베이스가 어떤 스토리지 하위 시스템을 사용하는지 이해하려면 wrangler d1 info YOUR_DATABASE를 실행하고 출력의 version 필드를 확인하세요.
version: beta인 데이터베이스는 새 스토리지 백엔드를 사용하고 Time Travel API를 지원해요. version: alpha인 데이터베이스는 D1의 오래된 레거시 백엔드만 사용해요.
2023-07-27
Time Travel. Time Travel이 이제 사용 가능해요. Time Travel을 사용하면 D1 데이터베이스를 지난 30일(Workers Paid 플랜) 또는 7일(Workers Free 플랜) 내의 어느 순간으로든 복원할 수 있어요. 저장이나 복원 작업에 추가 비용이 없어요.
시간을 거슬러 이동하는 방법을 배우려면 Time Travel 문서를 참고하세요.
D1의 새 스토리지 하위 시스템을 사용하는 데이터베이스는 Time Travel을 사용할 수 있어요. Time Travel은 레거시 알파 데이터베이스에 사용되던 스냅샷 기반 백업을 대체해요.
2023-06-28
지표 및 분석. 이제 Cloudflare 대시보드와 GraphQL Analytics API를 통해 데이터베이스별 지표를 확인할 수 있어요.
D1은 현재 초당 읽기/쓰기, 쿼리 응답 크기, 쿼리 지연 시간 백분위수를 노출해요.
2023-06-16
생성 열(generated columns) 문서. 쓰기(또는 읽기) 시 동적으로 생성되는 열을 정의하기 위해 D1의 생성 열 지원을 사용하는 방법에 대한 새 문서가 게시됐어요. 생성 열을 사용하면 JSON 객체에서 데이터를 추출하거나 다른 SQL 함수의 출력을 사용할 수 있어요.
2023-06-12
Error.cause 지원 중단. wrangler v3.1.1부터 D1 client API는 이제 최상위 Error.message 속성 안에 상세한 오류 메시지를 반환하며, 개발자가 Error.cause.message 속성을 검사할 필요가 없어요.
이전 Error.cause 동작에서의 전환을 돕기 위해, 상세 오류 메시지는 약 2023년 7월 14일까지 Error.cause와 최상위 Error 객체 양쪽에 계속 채워져요. 이 날짜 이후의 wrangler와 D1 client API의 향후 버전은 더 이상 Error.cause를 채우지 않아요.
2023-05-19
새 실험적 백엔드. D1은 쿼리 처리량, 지연 시간, 신뢰성을 극적으로 개선하는 새 실험적 스토리지 백엔드를 갖고 있어요. 실험적 백엔드는 가까운 미래에 기본 백엔드가 될 거예요. 실험적 백엔드로 데이터베이스를 만들려면 wrangler를 사용해 데이터베이스를 만들 때 --experimental-backend 플래그를 설정하세요:
$ wrangler d1 create your-database --experimental-backend
실험적 백엔드에 대해 자세히 알아보려면 공지 블로그를 읽어 보세요.
2023-05-19
위치 힌트. 이제 D1 데이터베이스를 만들 때 위치 힌트를 제공할 수 있어요. 이는 리더(쓰기자)가 위치할 곳에 영향을 줘요. 기본적으로 D1은 데이터베이스를 만들라는 요청을 보낸 위치와 가까운 곳에 데이터베이스를 자동으로 만들어요. 대부분의 경우 D1이 여러분을 대신해 데이터베이스에 가장 적합한 위치를 선택하게 해 줘요.
2023-05-17
JSON 쿼리. D1의 광범위한 JSON 함수 지원을 다루는 새 문서가 게시됐어요. JSON 함수를 사용하면 SQL 쿼리에서 직접 JSON을 파싱, 쿼리, 수정할 수 있어 데이터베이스에 대한 왕복 횟수나 쿼리되는 데이터를 줄여 줘요.