Edge Databases Compared: Cloudflare D1/KV/Durable Objects vs DynamoDB vs Cosmos DB vs Firestore

Introduction

The database layer is where the architectural differences between Cloudflare and the hyperscalers become most stark. Cloudflare is building a fundamentally different kind of data platform — one designed for the edge, with data stores that live on the same network as the compute. The hyperscalers built their databases for regional data centers, then added global replication as an extension.

This difference matters because where your data lives determines the latency of every operation that touches it. If your compute runs at the edge (Cloudflare Workers) but your database is in us-east-1, every database query adds 50-200ms of network round-trip time. Cloudflare's edge data services — D1, KV, Durable Objects, R2 — eliminate this gap by running data on the same network as compute.

The trade-off is real: Cloudflare's data services are younger, simpler, and more constrained than DynamoDB, Cosmos DB, or Firestore. Understanding when edge-native simplicity wins over regional-database depth is the key decision this comparison helps you make.

Cloudflare's Data Platform: Purpose-Built for the Edge

Cloudflare does not offer a single database product. Instead, it provides four purpose-built data primitives, each optimized for a specific access pattern:

Workers KV: Global Key-Value for Read-Heavy Workloads

KV is a globally distributed key-value store with eventual consistency and extremely low-latency reads. Data written to KV propagates to all 310+ Cloudflare locations within seconds, and subsequent reads return from the nearest location.

Best for: Configuration data, feature flags, A/B test assignments, localization strings, cached API responses, URL shortener mappings — any data that is written infrequently and read very frequently from global locations.

Not suited for: Workloads requiring strong consistency, complex queries, transactions, or high write throughput.

D1: SQLite at the Edge

D1 brings the familiarity of SQL to the edge. Each D1 database is a SQLite instance accessible from Workers with zero-latency binding (same data center as the executing Worker).

D1's read replication is the key performance feature: read replicas are automatically distributed to Cloudflare locations near your users. Reads hit the nearest replica with sub-millisecond latency; writes route to the single primary. This makes D1 exceptional for read-heavy workloads (content sites, product catalogs, user profiles) but limited for write-heavy workloads.

Best for: Blog content, product catalogs, user preferences, metadata, configuration that benefits from SQL queries and JOINs.

Not suited for: High-throughput writes, datasets larger than 10GB, complex analytics, or workloads requiring cross-database transactions.

Durable Objects: Strongly Consistent Coordination

Durable Objects are the most novel data primitive in cloud computing — there is no direct equivalent on any other platform. Each Durable Object is a single-threaded JavaScript class instance with:

• Strongly consistent transactional storage (key-value, backed by SQLite)
• Single-location execution (one instance runs in one location)
• Unique addressing (each object has a unique ID)
• WebSocket support (objects can manage WebSocket connections)
• Automatic hibernation (objects sleep when idle, wake on request)

The conceptual model: imagine a tiny single-threaded server for each entity in your system. A chat room Durable Object manages all participants, messages, and WebSocket connections for that room. A rate-limiter Durable Object tracks request counts for a specific client. A collaborative document Durable Object manages operational transforms for that document.

Best for: Real-time collaboration, WebSocket coordination, rate limiting, distributed locking, atomic counters, session management, multiplayer game state.

Not suited for: General-purpose data storage, analytics queries, bulk data processing.

Hyperdrive: Bridge to Regional Databases

Rather than replacing existing databases, Hyperdrive accelerates access to them from Workers:

• Connection pooling: Maintains persistent connections to PostgreSQL/MySQL, eliminating per-request connection overhead (saves 50-100ms per query)
• Query caching: Caches read query results at the edge (configurable TTL)
• Smart routing: Routes queries over Cloudflare's optimized backbone

Hyperdrive is the pragmatic answer for teams that cannot migrate to D1: keep your existing PostgreSQL or MySQL database and make it accessible from Workers with acceptable latency.

AWS DynamoDB: The Hyperscaler NoSQL Standard

DynamoDB is AWS's flagship NoSQL database — a fully managed, serverless, key-value and document store designed for single-digit millisecond performance at any scale.

Architecture

DynamoDB stores data in tables with a partition key (required) and optional sort key. Data is automatically partitioned and replicated across three availability zones within a region.

Capacity Modes

On-demand: Pay per request, no capacity planning. $1.25/million write request units (WRU), $0.25/million read request units (RRU).

Provisioned: Pre-allocate capacity for predictable workloads. $0.00065/WCU/hour, $0.00013/RCU/hour. Can save 60-80% vs on-demand for steady workloads. Supports auto-scaling.

Reserved capacity: 1-year or 3-year commitments for additional savings.

DynamoDB Global Tables

For multi-region access, DynamoDB offers Global Tables — active-active replication across up to five AWS regions. Each region accepts writes, and conflicts are resolved with last-writer-wins semantics. Global Tables add approximately 50% to the cost (replicated WCUs).

Global Tables provide strongly consistent reads within each region and eventually consistent reads across regions (replication latency typically under 1 second).

DynamoDB Strengths

• Unlimited scale: No table size limits, no throughput ceilings (with on-demand mode)
• Predictable performance: Single-digit millisecond latency regardless of table size
• Rich querying: GSIs, LSIs, filter expressions, and PartiQL provide flexible data access
• DynamoDB Streams: Change data capture for event-driven architectures, ETL pipelines, and cross-service synchronization
• DAX (DynamoDB Accelerator): In-memory caching layer for microsecond read latency
• Deep AWS integration: Lambda triggers, AppSync resolvers, Kinesis Data Streams, Step Functions

Azure Cosmos DB: Multi-Model with Tunable Consistency

Cosmos DB is Azure's globally distributed, multi-model database — and the most feature-rich database in this comparison.

Architecture

Cosmos DB provides a single database engine with five API interfaces:

Five Consistency Levels

Cosmos DB's most distinctive feature is five tunable consistency levels, from strongest to weakest:

This granularity is unmatched. DynamoDB offers two (eventual or strong). KV offers one (eventual). D1 offers one (strong for primary, eventual for replicas). Cosmos DB lets you choose per-request.

Cosmos DB Strengths

• Global distribution: Active-active writes across any number of Azure regions
• Multi-model: Document, graph, key-value, wide-column from one engine
• Tunable consistency: Five levels for precision trade-offs
• Automatic indexing: All fields indexed by default, no schema management
• Change feed: Built-in change data capture for event-driven architectures
• Serverless mode: Pay-per-request pricing with automatic scaling to zero
• 99.999% SLA: Five-nines availability with multi-region deployment

Cosmos DB Pricing

Cosmos DB uses Request Units (RUs) as a unified currency for reads, writes, and queries:

• Serverless: $0.25/million RUs (pay per request)
• Provisioned: From $0.008/hour per 100 RUs ($5.84/month per 100 RUs)
• Storage: $0.25/GB/month

A single point-read (1KB item by ID) costs 1 RU. A write costs ~5 RUs. Complex queries cost proportionally more RUs. This model is flexible but can be expensive for write-heavy workloads — and unpredictable if query complexity varies.

Google Cloud Firestore: Real-Time Serverless Documents

Firestore is Google's serverless document database, evolved from Firebase Realtime Database. It is the most developer-friendly option in this comparison for web and mobile applications.

Architecture

Firestore stores data as documents organized in collections. Documents contain typed fields (strings, numbers, booleans, arrays, maps, geopoints, timestamps, references). Collections can contain subcollections for hierarchical data modeling.

Firestore Strengths

• Real-time listeners: Clients subscribe to queries and receive live updates when data changes — no polling, no WebSocket management. This is Firestore's killer feature for mobile and web apps.
• Offline support: Client SDKs cache data locally and synchronize when connectivity resumes. Essential for mobile apps with intermittent connectivity.
• Strong consistency everywhere: Unlike DynamoDB (eventual default) or KV (eventual only), Firestore reads are always strongly consistent — you always see the latest write.
• Firebase integration: Authentication, Cloud Functions triggers, hosting, and analytics form a cohesive mobile/web development platform.
• Multi-region replication: Named multi-region locations (nam5, eur3) provide automatic data replication with strong consistency.

Firestore Pricing

• Document reads: $0.036/100K documents
• Document writes: $0.108/100K documents
• Document deletes: $0.012/100K documents
• Storage: $0.108/GB/month (first 1GB free)
• Free tier: 50K reads, 20K writes, 20K deletes per day

Firestore's pricing is simpler than Cosmos DB's RU model but can be expensive at scale for write-heavy workloads ($1.08/million writes vs DynamoDB on-demand's $1.25/million with more flexibility).

Comparison Tables

Core Capabilities

Pricing Comparison

Prices as of February 2026. All in USD.

Scenario: 10 million reads/month, 1 million writes/month, 5GB storage

At this moderate scale, pricing is comparable across providers. The differences emerge at scale:

Scenario: 1 billion reads/month, 100 million writes/month, 500GB storage

Firestore becomes expensive at high write volumes. DynamoDB provisioned mode rewards capacity planning with significant savings. D1 is the cheapest for read-heavy SQL workloads. Cosmos DB's cost depends heavily on query complexity (simple point reads are cheap; complex cross-partition queries consume many RUs).

Edge Latency: The Cloudflare Advantage

This is the dimension where Cloudflare's architecture provides a structural advantage:

For users far from the database region, the total round-trip difference is dramatic. A user in Singapore accessing a D1 database (replicated to Singapore) gets a ~20ms total response time. The same user accessing DynamoDB in us-east-1 gets ~250ms. This gap is the entire value proposition of edge data.

The caveat: D1 write latency depends on the primary's location. If the D1 primary is in the US and a user in Singapore writes, the write must travel to the US primary (~150ms). Read-heavy workloads benefit most from edge data; write-heavy workloads still face regional latency constraints.

Calculate Your Costs

Use the calculator below to estimate costs for your specific workload:

Unique Capabilities

Durable Objects: No Equivalent Elsewhere

Durable Objects solve a class of problems that are genuinely difficult on other platforms: strongly consistent state coordination at the edge without a central database.

Examples:

Rate limiter: A Durable Object per client maintains an atomic request counter. Because the object is single-threaded, there is no race condition — no distributed locking, no optimistic concurrency, no retry loops. The counter is always accurate.

Collaborative document: A Durable Object per document manages operational transforms from multiple editors. All edits are serialized through the single-threaded object, ensuring consistency without conflict resolution.

WebSocket room: A Durable Object per chat room maintains all WebSocket connections for that room. Broadcasting a message is a loop over the object's connection list — no external pub/sub system required.

On AWS, these problems require combining multiple services: DynamoDB for state + SQS/SNS for messaging + Lambda for logic + API Gateway for WebSockets. On Cloudflare, a single Durable Object replaces the entire stack.

DynamoDB Streams + Lambda: Event-Driven Data Pipelines

DynamoDB Streams capture every change to a table and trigger Lambda functions. This enables:

• Derived views: Maintain a search index (OpenSearch) updated in real-time from DynamoDB changes
• Cross-region sync: Replicate data to non-AWS systems via Lambda
• Audit logging: Every write is captured as an immutable stream event
• Materialized views: Compute aggregations or denormalized views on every change

This event-driven data pipeline pattern is mature and well-documented on AWS. Cloudflare's equivalent (D1 + Queues) is less mature.

Cosmos DB Change Feed: Universal Event Source

Cosmos DB's Change Feed provides a persistent, ordered log of all changes to a container. It powers:

• Azure Functions triggers: React to data changes in real-time
• Azure Synapse Link: No-ETL analytics on operational data
• Cross-region materialized views: Build read-optimized views in different regions

The Change Feed combined with Cosmos DB's five consistency levels enables architectures where you read from eventual-consistency replicas for speed but process changes through a strongly consistent pipeline for correctness.

Firestore Real-Time Listeners: Live Queries

Firestore's real-time listeners are architecturally unique among the four providers. Client SDKs can subscribe to a query, and Firestore pushes updates to all subscribed clients whenever matching documents change:

// Firestore real-time listener
db.collection("messages")
  .where("room", "==", "general")
  .orderBy("timestamp")
  .onSnapshot((snapshot) => {
    snapshot.docChanges().forEach((change) => {
      if (change.type === "added") {
        displayMessage(change.doc.data());
      }
    });
  });

No polling. No WebSocket management. No event infrastructure. Firestore handles the pub/sub mechanics automatically. This makes Firestore the fastest path to real-time features for mobile and web developers.

Cloudflare achieves similar real-time capability through Durable Objects + WebSockets, but it requires more custom code. DynamoDB + AppSync provides GraphQL subscriptions, but with more configuration. Cosmos DB + SignalR provides real-time updates, but it is less integrated.

Decision Framework

Choose Cloudflare Data Services When:

• Edge latency is critical — your users are global and every millisecond matters for read-heavy workloads
• Your compute is on Workers — D1, KV, and Durable Objects are accessed with zero network latency from Workers
• Coordination problems — Durable Objects solve rate limiting, real-time collaboration, WebSocket management without external services
• Simple data models — key-value (KV), basic SQL (D1), or per-entity state (DO)
• You want integrated edge stack — compute + data + storage on the same network with no egress

Choose DynamoDB When:

• Unlimited scale — no storage limits, no throughput ceiling, predictable single-digit millisecond latency at any size
• Event-driven architecture — DynamoDB Streams + Lambda for data pipelines, CDC, and materialized views
• AWS ecosystem — deep integration with Lambda, AppSync, Step Functions, Kinesis, and 200+ other services
• Flexible consistency — choose eventual or strong per-read based on requirements
• Global Tables for multi-region active-active with managed conflict resolution

Choose Cosmos DB When:

• Multi-model requirements — you need document, graph, key-value, or wide-column access from one database
• Tunable consistency — the five consistency levels provide precision that no other provider matches
• Global distribution — active-active writes across any number of Azure regions
• Azure ecosystem — Synapse Link for no-ETL analytics, Azure Functions triggers, Azure AI integration
• Enterprise governance — Azure RBAC, Azure Policy, Microsoft Purview integration

Choose Firestore When:

• Real-time applications — live queries with automatic push updates are unmatched
• Mobile/web development — Firebase SDK provides offline support, authentication, and hosting as a cohesive platform
• Strong consistency required — every read always returns the latest write, no configuration needed
• Rapid prototyping — the simplest serverless database to set up and start using
• GCP ecosystem — BigQuery integration for analytics on operational data

The Strategic Picture

Cloudflare's data platform represents a bet that most web-facing workloads do not need the full power of DynamoDB, Cosmos DB, or Firestore. A content site needs a read-heavy SQL database (D1). A real-time feature needs state coordination (Durable Objects). A feature flag system needs fast global key-value reads (KV). These use cases do not need unlimited storage, tunable consistency, or graph queries — they need low latency from anywhere in the world.

The hyperscaler databases are more powerful, more mature, and more flexible. But they are also more complex, more expensive at scale, and fundamentally limited by their regional architecture — compute in us-east-1 is fast to DynamoDB in us-east-1, but slow to users in Tokyo.

The honest assessment: use Cloudflare's data services when edge latency is the primary requirement and the data model fits (read-heavy, moderate scale, simple queries). Use hyperscaler databases when data complexity, scale, or ecosystem integration are the primary requirements. Many production architectures combine both: Cloudflare KV or D1 for edge-served data, with DynamoDB or Firestore as the system of record synced via Workers.