「エッジで速い」はずの Cloudflare D1 が、日本から測ると東京の Turso に負けた。無料枠サーバレス DB 3 種の cold / warm 実測

前提

• 誰向け: 無料枠のサーバレス DB を「カタログの数値」と「エッジだから速い」で選ぼうとしている人。
• 対象: Cloudflare D1（SQLite・REST API 直叩き・read replication / Sessions API は未使用）、Turso（libSQL・東京）、Neon（PostgreSQL・シンガポール・5 分で scale-to-zero）。
• 環境: 日本（西日本の自宅回線）の実機 1 台・単一セッション（2026-07）。ベンチマークではなく「配線の可視化」。絶対値の順位より、体感速度を決める要素の腑分けが目的。
• 各社は無料枠と挙動を頻繁に変える。賞味期限が長いのは数値でなく測り方。

手順

1. curl -w で DNS→TCP→TLS→TTFB を工程ごとに記録する（壁時計 1 本に丸めない）。
2. cold と warm を別に測る。cold＝毎回別プロセスで新規接続からの初回。warm＝確立済み接続で同一クエリを 200 回。
3. Neon は各サンプルで 5 分超（7 分）アイドルしてから別プロセスで復帰を測る。さらに compute 起床中に新規接続だけを繰り返し、pg 接続確立のコスト（wake 抜き）を測って純 wake を差分で出す。
4. warm は複数クエリ種（select 1 / count / insert）で測り、いずれも p50 が同水準だったので select 1 を代表にする。
5. p50 中心。p99 は無負荷・逐次の下限としてだけ読む。

うまくいかなかったこと

1. Neon の cold を「初回クエリ時間」で測って「cold start ほぼ無し」と結論しかけた。 wake は接続確立に乗る。接続ごと測り直すと復帰は約 1157ms。
2. その 1157ms を丸ごと「wake」と表示しかけた。 起床中の新規接続を測ったら約 540ms は距離 × pg ハンドシェイク。純 wake は約 620ms。
3. DB 作成直後の初回 1 発が 1 秒近い外れ値で「約 15 倍」と速断しかけた。 定常 n=30 で D1 の cold は約 152ms。単発を一般化しない。
4. 短いアイドル（5.5 分）の Neon に 570ms が混じり分散が大きかった。 suspend 未達だった。アイドルを 7 分にし別プロセスにしたら 1084〜1606ms（n=15）に収まった。
5. 「rows_read で D1 の無料枠は溶ける」と一般化しかけた。 溶けるのは index 無しのフルスキャン固有。index があれば別。

数値

指標（ms）	Turso（東京）	D1（APAC）	Neon（シンガポール）
cold 初回 E2E（新規接続の最初の 1 クエリ）	約 121（n=30）	約 152（n=30）	約 1245（n=15）
うち wake 込み接続確立	≒E2E	≒E2E	約 1157（幅 1084〜1606）
うち pg 接続確立（起床中・n=11）	—	—	約 540
うち純 wake	—	—	約 620
warm p50（n=200）	22	60	87
参考 serverMs	取得不可	0.13	—

まとめ

D1 の serverMs は 0.13ms。遅いのは DB ではなく、どこから・どの経路で叩いたかです。国内ユーザー中心なら Turso（東京）、Postgres の機能が要るなら Neon（初回の約 1.2 秒だけ注意）、Workers の資産があるなら D1。数字そのものより、外れ値・suspend 未達・非対称な比較・wake の過大表示をどう見つけて潰したかを残しました。本番投入前に効くのは「初回だけ固まる」「深夜に止まる」というカタログに載らない挙動で、それは自分で叩かないと分かりません。