Cloudflare Workers KV Storage vs D1 SQLite: Latency Benchmarks

Edge functions live or die by milliseconds. Pick the wrong storage layer and a 2ms computation becomes a 180ms round-trip — and that’s before your cold start tax hits.

Right now, two storage options dominate the Cloudflare Workers ecosystem: KV (a globally distributed key-value store) and D1 (a SQLite-based relational database running at the edge). Both ship natively on Cloudflare’s network. Both feel deceptively similar at first glance. But the KV vs D1 latency conversation keeps surfacing in engineering Slack channels because the performance profiles diverge dramatically depending on your access pattern.

This isn’t a close call if you understand the architecture. It’s a deliberate trade-off — eventual consistency and sub-10ms reads on one side, full SQL expressiveness with higher latency ceilings on the other.

Key Takeaways

• Cloudflare KV delivers globally cached read latencies under 10ms for hot keys, but write propagation can take up to 60 seconds across the full edge network.
• D1 SQLite queries typically run 10–40ms for simple selects, but complex joins or cold reads against a regional primary can push beyond 100ms.
• Cold start penalties differ structurally: KV reads bypass worker initialization latency almost entirely, while D1 sessions establish a fresh connection to a regional SQLite instance per request.
• The KV vs D1 decision maps cleanly to read:write ratio — KV wins above 80:20, D1 wins when you need relational integrity.
• As of May 2026, D1 has exited beta with 10GB per-database limits and global read replication, narrowing — but not eliminating — KV’s latency advantage for read-heavy paths.

Background & Context

Cloudflare launched Workers KV in 2018 as a way to give edge functions persistent state without round-tripping to an origin. The model was simple: write once, read many times, accept eventual consistency. For configuration data, feature flags, and session tokens, that trade-off made sense.

D1 came much later. Cloudflare announced the SQLite-based D1 in 2022, shipped a public beta through 2023–2024, and reached general availability in late 2025. The pitch was different — structured data, relational queries, ACID transactions — all at the edge. According to Cloudflare’s official Workers storage documentation, D1 now supports databases up to 10GB with automatic read replication to multiple regions.

The timing matters. Through most of 2023–2024, D1 carried meaningful beta caveats: query latency variability, limited replica coverage, smaller size limits. Engineers defaulted to KV even for use cases that wanted SQL, because D1 simply wasn’t production-ready. That calculus shifted in 2026. D1’s read replication landed in more regions, the query planner matured, and real production traffic started flowing through it at scale.

So the question became genuinely interesting again — not “which one works” but “which one is faster for my pattern.”

The core architectural difference: KV stores values in a globally replicated cache layer with a strong write origin. Reads pull from the nearest cache node. D1 stores data in a SQLite file on Cloudflare’s infrastructure, with the primary write region fixed and reads served from replicas. KV optimizes for read speed. D1 optimizes for query expressiveness.

Main Analysis

Read Latency: The KV Structural Advantage

For hot keys — values read frequently enough to stay cached at edge nodes — KV is genuinely fast. According to benchmarks documented by PropTechUSA.ai and corroborated by community testing on the Cloudflare Developer Discord (May 2026), cached KV reads clock in at 2–8ms from most major regions.

D1 read latency on simple SELECT queries against a replicated read instance runs 15–40ms in typical conditions. That’s not slow in absolute terms. But it’s 3–5x slower than KV for the same data retrieval operation.

The gap widens on complex queries. A D1 join across two tables with 50k rows each — the kind of query that’s trivial in PostgreSQL — can push 80–120ms depending on index coverage and replica freshness. KV simply doesn’t have this ceiling because it doesn’t do relational queries at all.

Write Latency and Consistency: Where D1 Wins

KV’s write path is its Achilles heel. Writes go to a central origin and propagate outward via cache invalidation. According to Cloudflare’s official documentation, KV write propagation can take up to 60 seconds globally. For most caching use cases, that’s fine. For anything needing immediate consistency — inventory counts, user permissions, payment state — it’s a real problem.

D1 writes are synchronous to the primary region. You get a confirmation when the data’s committed. No 60-second ambiguity. And with ACID transactions, you can batch multiple operations atomically — something KV can’t do at all.

Write latency for D1 primary-region commits runs 20–50ms for typical inserts. Not fast, but consistent and durable.

Cold Start Behavior at the Edge Function Layer

Cold starts affect both storage options, but differently.

A Cloudflare Worker cold start (when the isolate hasn’t been active recently) adds roughly 5–15ms to the total request time, according to Cloudflare’s own performance documentation. That’s independent of storage choice.

The storage layer adds its own initialization cost on top. KV reads don’t require establishing a session — the binding is resolved at the Workers runtime level. D1 connections require initializing a database session against the relevant SQLite instance. In testing documented by community benchmarks (eastondev.com, April 2026), this D1 session initialization adds an extra 10–25ms on the first query per Worker invocation.

For long-lived Worker instances handling sustained traffic, this penalty amortizes to near-zero. For low-traffic endpoints that spin up cold frequently, it compounds. A cold Worker combined with a first D1 query can easily hit 60–80ms before any business logic runs.

Comparison: KV vs D1 for Edge Function Workloads

The table tells a clear story. KV dominates when you’re reading cached or semi-static data from globally distributed edge nodes. D1 dominates when your data model needs structure, relationships, or write consistency that KV can’t provide.

The interesting gray zone: user session data. Sessions are read-heavy (good for KV) but also need atomic updates on login/logout (better for D1). The pragmatic answer most teams land on in 2026 is hybrid — KV for the hot session token lookup, D1 for the authoritative user record.

Practical Implications

The core challenge: Cloudflare Workers give you a fast edge runtime, but storage latency can negate that advantage entirely if you pick the wrong layer for your access pattern.

Scenario 1 — High-traffic API serving feature flags or rate limit counters

This is KV’s home turf. Values change infrequently, reads happen millions of times per day, and eventual consistency is acceptable (a stale feature flag for 30 seconds won’t break anything). The math heavily favors KV here. Use KV with a TTL of 60 seconds and push writes from a central control plane.

Scenario 2 — E-commerce cart or order management at the edge

Cart contents need relational structure (items, quantities, product references) and write consistency — you don’t want double-charges or lost updates. KV’s eventual consistency is genuinely dangerous here. D1’s ACID transactions and SQL query capability justify the higher read latency. D1 works as the primary store, with KV considered only for a fast-path cart count display (the “3 items” badge) that can tolerate a few seconds of staleness.

Scenario 3 — Auth token validation on every edge request

Every request hits a Worker that needs to validate a JWT and confirm the user’s role. Pure lookup, no relational join needed, called at enormous volume. D1’s 15–40ms latency per call adds up fast at scale. The pattern that works: KV with short TTLs (60–300 seconds), with D1 as the source of truth refreshed on cache miss. This cuts per-request auth overhead to under 5ms for cached tokens.

This approach can fail when token revocation needs to propagate immediately — a user whose access is revoked might still hit valid KV cache for up to 5 minutes. For high-security contexts, that tradeoff isn’t acceptable and D1 as the direct lookup source is the safer call, latency cost included.

What to watch: Cloudflare has signaled expanded D1 read replica coverage as a 2026 roadmap item. If regional replica latency drops to the 8–12ms range, the KV vs D1 decision for read-heavy workloads gets significantly closer.

Conclusion & Future Outlook

The KV vs D1 question doesn’t have a universal winner. It has a clear decision tree.

KV delivers 2–8ms cached reads. D1 delivers 15–40ms with SQL expressiveness. Cold D1 sessions add 10–25ms per Worker invocation — significant for low-traffic endpoints. KV’s 60-second write propagation makes it unsuitable for consistency-critical data. D1’s ACID guarantees and SQL capability justify its latency cost for relational workloads.

Looking ahead 6–12 months: Cloudflare’s expanded D1 read replication will chip away at KV’s latency lead. If D1 replica reads hit sub-10ms in most regions by Q4 2026, the hybrid pattern becomes less necessary and D1 can serve as a single storage layer for more use cases.

One open question worth tracking: whether Cloudflare introduces a strongly-consistent KV variant. That would collapse the distinction between these two products for many workloads.

Profile your read:write ratio and consistency requirements before committing to either. For anything above 80% reads with eventual consistency tolerance, KV is faster and cheaper. For everything else, D1 is the right foundation — latency included.

The hybrid pattern is worth a closer look if you haven’t stress-tested your D1 cold start behavior under real traffic.

References

1. Choosing a data or storage product. · Cloudflare Workers docs
2. Cloudflare Workers KV vs D1: Complete Performance Guide | PropTechUSA.ai
3. Cloudflare Workers KV in Practice: A Complete Guide to Distributed Key-Value Storage · BetterLink Bl

Photo by Conny Schneider on Unsplash