Cloudflare Workers KV vs D1 SQLite Read Latency Cold Start Test

KV clocked sub-5ms reads in warm-cache scenarios. D1 SQLite hit 12โ25ms on the first query after a cold start. The gap sounds small until you’re running 50,000 requests per hour and every millisecond compounds.
This is the breakdown engineers actually need before picking a storage layer โ not the marketing copy.
Key Takeaways
- Cloudflare Workers KV delivers sub-5ms read latency under warm-cache conditions, making it the faster option for simple key-value lookups at high request volume.
- D1 SQLite cold start latency ranges from 12โ25ms on the first query, but subsequent warm reads drop to 6โ10ms โ a 40โ60% improvement within the same worker lifecycle.
- KV’s eventual consistency model means writes can take up to 60 seconds to propagate globally, while D1 offers strong consistency within a single region by default.
- For read-heavy workloads with predictable key access patterns, KV wins on raw speed. For relational queries or transactional logic, D1’s latency tradeoff is worth it.
- Cold start behavior is the deciding factor: if your worker idles between requests, D1’s initialization overhead accumulates at measurable scale.
Why This Comparison Actually Matters in 2026
Cloudflare’s edge compute platform has grown dramatically. As of Q1 2026, Cloudflare Workers runs on over 310 points of presence globally, per Cloudflare’s network status page. The storage options have matured alongside it โ but they’ve diverged architecturally in ways that aren’t obvious from the docs alone.
Workers KV launched in 2018 as a distributed key-value store. Built for eventual consistency, global read speed, and simple get/put operations. D1, Cloudflare’s SQLite-at-the-edge product, entered general availability in late 2023 and has been iterating steadily since. D1 runs SQLite databases colocated near your workers, giving you full SQL query capability with relational structure.
The tension is real: KV was designed for speed at scale, D1 was designed for structure at the edge. They’re solving different problems. But developers frequently hit a genuine decision point โ do you store config data, session state, or user records in KV or D1? The answer depends heavily on real-world latency behavior, not theoretical architecture.
Cloudflare’s own storage options documentation acknowledges this overlap, describing KV as optimal for “high-read, low-write” scenarios and D1 as suited for “relational data and SQL queries.” What the docs don’t give you is a side-by-side latency breakdown under real conditions. That’s what this covers.
The Latency Numbers: What Real Testing Shows
KV Read Performance
Workers KV performance splits into two distinct buckets: cache-hit reads and cache-miss reads.
When a key has been recently accessed from a given PoP (point of presence), KV reads come in at 2โ5ms consistently. That’s the in-memory cache layer at the edge doing its job. Cloudflare’s own benchmark documentation and third-party testing published on EastonDev’s KV guide (April 2026) both confirm this range.
Cache misses are a different story. If a key hasn’t been accessed recently at that PoP, KV fetches from the nearest storage cluster โ pushing latency to 20โ40ms. This is the number most tutorials skip. At low traffic volumes, cache miss rates can be surprisingly high, especially for long-tail keys.
Write latency for KV sits at 150โ200ms for the acknowledgment, with global propagation taking up to 60 seconds per Cloudflare’s official documentation. For read-heavy use cases, that’s workable. For anything requiring immediate consistency, it’s a hard constraint.
D1 SQLite Performance
D1’s latency profile looks different. Cold starts โ where the worker has been idle and needs to initialize the database connection โ add 12โ25ms of overhead before the first query executes. This is the critical number in any honest KV vs D1 comparison.
After initialization, warm reads on simple SELECT queries run at 6โ10ms. Complex joins or queries without proper indexes push into 20โ50ms territory, depending on table size and query structure. D1 databases currently support up to 10GB per database (per Cloudflare’s D1 limits page), so index design matters at scale โ and this is an area where teams frequently underinvest until performance degrades in production.
D1 offers strong consistency within a read-write session. No propagation delay. What you write is what you immediately read back โ a material advantage over KV for transactional patterns.
Head-to-Head Comparison
| Metric | Workers KV | D1 SQLite |
|---|---|---|
| Warm read latency | 2โ5ms | 6โ10ms |
| Cold start overhead | ~5ms (cache miss: 20โ40ms) | 12โ25ms |
| Write latency | 150โ200ms | 5โ15ms |
| Global consistency | Eventual (up to 60s) | Strong (single region) |
| Query capability | Key-value only | Full SQL |
| Max data per namespace/DB | Unlimited keys, 25MB/value | 10GB per database |
| Best for | Config, sessions, feature flags | User records, relational data |
The table makes the tradeoffs concrete. KV wins on raw read speed when warm. D1 wins on write latency, consistency guarantees, and query flexibility โ but you’re paying 3โ5x the read latency cost on cold starts.
What Cold Starts Actually Cost at Scale
This is where the comparison gets practically important.
Workers on Cloudflare’s platform can be evicted from memory after periods of inactivity. The exact idle threshold isn’t published, but community testing and PropTechUSA’s performance guide (2026) consistently show cold starts occurring after roughly 30 seconds of inactivity on both free and paid plans.
Scenario A โ High-frequency API (10k+ req/min): Workers stay warm continuously. D1’s cold start cost is essentially irrelevant. The 6โ10ms warm read latency is acceptable for most API patterns. KV’s advantage shrinks to 2โ4ms, which only matters at extreme scale.
Scenario B โ Low-frequency background jobs or admin APIs: Workers idle frequently. Every D1 request after an idle period pays the 12โ25ms cold start tax. KV, with its distributed cache architecture, doesn’t have this problem โ even cache misses recover faster than D1 cold starts. This is the scenario where teams most often regret choosing D1 without accounting for traffic patterns upfront.
Scenario C โ Edge-rendered pages with dynamic data: The decision branches hardest here. If the data involves simple lookups โ user preferences, feature flags, A/B test config โ KV’s warm cache speed wins. If the page needs joins across user records and content tables, D1’s SQL capability outweighs its latency penalty.
PropTechUSA’s performance comparison (2026) recommends a hybrid pattern for production apps: store frequently-read, rarely-written data (session tokens, config values) in KV, and keep relational or transactional data in D1. That architecture gets you sub-5ms reads on the hot path with full SQL capability when you need it. It’s not a complex setup โ Cloudflare’s platform supports both storage layers within the same worker, and the binding configuration is straightforward.
This approach can fail when teams treat it as a default rather than a deliberate choice. If your relational data starts getting mirrored into KV for speed, you’ve created a consistency problem that’s hard to debug at 3am.
Making the Decision
The data points toward a clear decision tree:
Use KV when your access pattern is key-based, your worker handles steady traffic, and eventual consistency is acceptable. Feature flags, rate limiting counters, session caches โ KV is the right tool here.
Use D1 when you need relational structure, strong consistency, or complex queries. Accept the cold start cost, mitigate it with warming strategies or consistent traffic, and design your indexes carefully before you hit scale.
Use both for production apps with mixed data requirements. It’s not an either/or choice.
One thing worth watching: Cloudflare’s D1 roadmap includes multi-region read replicas, announced as of 2026. If D1 gets regional read replicas with sub-10ms warm reads globally, the KV vs D1 calculus shifts meaningfully toward D1 for most use cases. That’s not a reason to wait, but it’s a reason to avoid over-engineering your KV layer if your data is inherently relational.
KV is faster today for simple reads. D1 is more capable. Pick based on your actual access pattern โ not the benchmark headline, and not which one has a cleaner API.
What’s your current Workers storage setup โ KV, D1, or both? The hybrid approach is worth testing if you haven’t.
References
- Cloudflare Workers KV in Practice: A Complete Guide to Distributed Key-Value Storage ยท BetterLink Bl
- Cloudflare Workers KV vs D1: Complete Performance Guide | PropTechUSA.ai
- Choosing a data or storage product. ยท Cloudflare Workers docs


