Edge Databases: Data Storage at CDN Points of Presence

Edge databases store and serve data at or near CDN Points of Presence, reducing read latency from the 50 to 200 milliseconds typical of centralized databases to single-digit milliseconds. As edge functions take on more application logic, the need for co-located data has become a critical infrastructure challenge. The problem is not simply replicating data to more locations — it is managing consistency, conflict resolution, and write coordination across a network of hundreds of globally distributed nodes.

Why Is Data at the Edge So Difficult?

Traditional databases assume a single authoritative copy of data with clients connecting to a central server. This model delivers strong consistency (every read reflects the latest write) and straightforward transaction management (ACID guarantees within a single instance). Moving data to the edge breaks both assumptions. For foundational context, read Edge Computing on CDN: Moving Logic to the Edge — FlyFish NWA.

At the edge, data must exist in dozens or hundreds of copies across different geographic locations. When a user in Tokyo and a user in London both update the same record simultaneously, the system must decide which write wins, how to merge conflicting changes, and how quickly other copies learn about the update. These are fundamental distributed systems challenges governed by the CAP theorem: in a network-partitioned system, you can have consistency or availability, but not both. Every edge database makes a deliberate choice on this spectrum, and understanding that choice is essential for selecting the right solution.

How Do Read Replicas at the Edge Reduce Latency?

The simplest edge data pattern is read replicas: copies of a centralized database distributed to edge PoPs for fast reads, with all writes routing to a primary region. This pattern preserves strong consistency for writes while delivering low-latency reads from the nearest replica. The trade-off is replication lag — the time between a write at the primary and its availability at edge replicas.

Read replicas work well for data with high read-to-write ratios: product catalogs, configuration settings, user profiles (read often, updated rarely), and content metadata. For a typical e-commerce site where reads outnumber writes 100-to-1, edge read replicas eliminate 99% of database round-trip latency without introducing consistency complexity. The key architectural decision is the acceptable staleness window — whether your application can tolerate data that is 100 milliseconds, 1 second, or 5 seconds behind the primary.

What Edge Database Platforms Are Available Today?

Cloudflare D1

D1 is a serverless SQLite database integrated directly into the Cloudflare Workers platform. Each D1 database is a single SQLite file with a primary writer location and read replicas distributed to edge PoPs near requesting users. Queries use standard SQL, and the Workers binding API provides a familiar interface. D1 excels for applications that need relational queries at the edge without managing database infrastructure. Its limitations include single-region writes, a maximum database size of 10 GB, and eventual consistency for reads at non-primary locations.

Cloudflare Durable Objects

Unlike D1's relational model, Durable Objects provide strongly consistent, single-instance storage with co-located compute. Each Durable Object runs on exactly one server at any time, guaranteeing that all reads and writes to that object are serialized. This makes them ideal for coordination primitives: rate limiters, real-time counters, WebSocket rooms, and distributed locks. The trade-off is that all requests for a specific object route to its single location, adding latency for geographically distant users.

Turso (libSQL)

Turso runs libSQL — an open-source fork of SQLite — as a distributed database service with replicas in 30+ locations. The primary difference from D1 is Turso's embedded replicas feature, which allows edge applications to bundle a full SQLite replica within the function runtime. Reads resolve locally without any network call. Writes replicate asynchronously to the primary and then fan out to other replicas. Turso's architecture targets applications that prioritize read performance above all else and can tolerate eventual consistency.

PlanetScale Serverless Driver

PlanetScale takes a different approach: rather than distributing the database itself, it provides a serverless HTTP-based driver that allows edge functions to query a centralized Vitess-based MySQL database without persistent TCP connections. Reads and writes go to PlanetScale's infrastructure, but the connection overhead is eliminated. This is not true edge data — query latency still depends on the distance to the nearest PlanetScale region — but it solves the critical problem of database connectivity from edge serverless environments.

DynamoDB Global Tables

AWS DynamoDB Global Tables provide multi-region, multi-active replication for DynamoDB. Each region can accept both reads and writes, with changes replicating asynchronously across regions (typically under one second). Conflict resolution uses last-writer-wins based on timestamps. Global Tables integrate naturally with Lambda@Edge and CloudFront, making them the default choice for AWS-native edge architectures. The cost is higher per-request pricing compared to single-region DynamoDB and the operational complexity of managing global secondary indexes across regions.

How Do Edge Databases Compare on Key Dimensions?

How Do CRDTs Solve Conflict Resolution at the Edge?

Conflict-free Replicated Data Types (CRDTs) are mathematical data structures designed to be updated independently on multiple nodes and merged deterministically without coordination. They address the fundamental challenge of edge databases: when two users modify the same data at different PoPs simultaneously, how does the system converge to a consistent state?

The most common CRDT types for edge applications include:

• G-Counter (Grow-only Counter): Each node maintains its own counter. The merged value is the sum of all node counters. Ideal for page view counts, like counts, and analytics where decrements are not needed.
• PN-Counter (Positive-Negative Counter): Extends G-Counter with a separate decrement counter, enabling both increments and decrements. Useful for inventory counts and resource pools.
• LWW-Register (Last-Writer-Wins Register): Stores a single value with a timestamp. Merging selects the value with the latest timestamp. Simple but can lose concurrent updates silently. DynamoDB Global Tables use this strategy.
• OR-Set (Observed-Remove Set): A set that supports both add and remove operations with conflict-free merging. Each element carries a unique tag on addition; removal marks specific tags rather than the element itself, preventing the add-remove paradox.

CRDTs do not solve all consistency problems. They work for specific data structures with well-defined merge semantics. Complex relational operations, multi-row transactions, and arbitrary business logic require stronger consistency models that CRDTs cannot provide.

How Does the CAP Theorem Constrain Edge Database Design?

The CAP theorem, formulated by Eric Brewer in 2000, proves that a distributed data store can provide at most two of three guarantees: Consistency (every read returns the latest write), Availability (every request receives a response), and Partition tolerance (the system operates despite network failures between nodes).

Edge databases must tolerate partitions — network links between PoPs fail regularly — so they choose between consistency and availability. Most edge databases choose availability (AP systems), returning potentially stale data during partitions rather than refusing requests. This is the right trade-off for most web applications where a slightly outdated product price is better than an error page. Applications requiring strict consistency for financial transactions, inventory management, or coordination should keep those operations at a centralized database with strong consistency guarantees.

What Architecture Patterns Work Best for Edge Data?

Three patterns cover the majority of edge data use cases:

Read-through cache: The edge function checks a local KV store or embedded database first. On cache miss, it queries the centralized database, stores the result at the edge, and returns it. Subsequent requests from the same region read from the edge cache. This pattern works for all read-heavy workloads and pairs well with cache invalidation strategies triggered by write events.

Write-behind queue: The edge function accepts writes immediately and stores them in an edge-local queue. A background process asynchronously replicates queued writes to the centralized database. This provides fast write acknowledgment to the user but risks data loss if the edge node fails before replication completes. Use this pattern for non-critical writes like analytics events, user preferences, and activity logs.

CQRS at the edge: Command Query Responsibility Segregation separates read and write models. Reads serve from edge-optimized read replicas. Writes route to a centralized command handler that processes the write, updates the primary database, and publishes events that update edge read replicas. This pattern provides the best combination of read performance and write consistency but adds significant architectural complexity.

The choice between patterns depends on your application's read-to-write ratio, consistency requirements, and tolerance for complexity. Start with read-through caching — it delivers the highest impact with the lowest implementation cost — and evolve toward CQRS only when your application's scale and consistency requirements demand it. For most edge personalization and content delivery use cases, read-through caching with TTL-based expiration provides sufficient freshness without the overhead of real-time replication.