D1 が遠いリージョンにできていないか確かめ、日本の近くに作り直す
D1 の応答が毎回 200〜300ms かかるときは、まず DB のプライマリが日本以外（シンガポールなど）にできていないかを見る。
どんなときに使うか
- 日本向けの Workers + D1 なのに、単純なクエリでも応答が遅い
- DB を CI や IaC、海外にいるメンバーの環境から作った覚えがある
確かめ方
D1 のクエリ結果のメタ情報には、どこで処理されたかが入る。@zaru は Cloudflare の CLI でこう確認していた。
sh
cf d1 query <DB_ID> --sql 'SELECT 1'wrangler d1 execute <DB名> --remote --command 'SELECT 1' --json でもメタ情報を見られる。処理したリージョンが日本から遠い（APAC でもシンガポールなど）なら、日本からの往復はそのぶん遅い。
作り直し方
- 新しい DB を作る。@zaru の試した範囲では、ヒントなしで日本から作ると東京か大阪になり、
apacを付けるとかえって日本以外（シンガポールなど）を引きやすかった。
sh
npx wrangler d1 create my-db-jp # 日本から実行。ヒントなし
# npx wrangler d1 create my-db --location=apac # 日本以外になることがある- 旧 DB を
wrangler d1 export <旧DB> --remote --output dump.sqlで書き出し、wrangler d1 execute <新DB> --remote --file dump.sqlで入れる。 wrangler.toml/wrangler.jsoncのdatabase_idを新しい ID に変えてデプロイする。- 上の
SELECT 1で新 DB の処理リージョンを確かめる。
注意
- 公式ドキュメントでは、ロケーションヒントは「希望地に最も近い場所に作る」だけで保証はない。ヒントなしの自動配置は「作成リクエストを出した場所の近く」なので、CI やリモートの作業環境から作ると想定外の場所になりうる。
- 場所は作成時に決まり、後から動かせない（jurisdiction も同じく作成時のみ）。
- 読み取りが多いなら、作り直しの代わりに Read Replication（Sessions API）で各地のレプリカから読ませる手もある。書き込みはプライマリまで往復する。
- Worker をプライマリ近くで動かす（Smart Placement など）と DB との往復は減るが、ユーザーから Worker までは遠くなる。返信で「Worker をシンガポールに置いて 200ms は切ったが 100ms は切れない」という声もあった。
- 「
apacで日本以外になりやすい」は個人の試行結果。
出典
- @zaru · 2026-11-09 （@supermomonga の「D1 だと普通に 300ms くらいかかる」への引用）
- Cloudflare D1 Docs: Data location