> ## Documentation Index
> Fetch the complete documentation index at: https://gcore.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# How it works

Edge Storage is a globally replicated key-value store for FastEdge applications. A local replica is available at every edge location where the application runs, allowing reads to be served directly from the edge node handling the request.

Unlike CDN solutions that place data stores at regional POP locations, Edge Storage deploys a replica at every FastEdge location.

## Architecture

Edge Storage is deployed next to FastEdge applications at every edge location. When an application reads from a store, it reads from the local replica on the same edge node — no network call to a regional or central database is needed.

Writes follow a different path. They are sent through the REST API, persisted in a central SQL database, and then replicated to all edge locations globally. Replication typically completes within 1–2 seconds. This makes Edge Storage well-suited for data that is read frequently but written infrequently: configuration, feature flags, lookup tables, blocklists, and similar reference data.

## Edge Storage vs Cache

Edge Storage and [Cache](/fastedge/cache) address different requirements. Edge Storage is the right choice for durable, globally consistent data created and managed ahead of time. Cache is the right choice for fast, POP-local state at runtime — for example, counters or memoized values that do not need to be shared between POPs.

|                     | Edge Storage (KV)                                                                   | Cache                                                                          |
| ------------------- | ----------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ |
| Scope               | Globally replicated to all POPs                                                     | Single POP                                                                     |
| Consistency         | Eventual (1–2 seconds globally)                                                     | Strong (within a POP)                                                          |
| Durability          | Durable, backed by a central database                                               | Transient, evictable                                                           |
| Provisioning        | Created in the portal and linked to the application                                 | None — available at runtime on paid plans                                      |
| Writes from the API | Yes                                                                                 | No (runtime only)                                                              |
| Atomic counters     | No                                                                                  | Yes (`incr`; `decr` JS only)                                                   |
| Typical workloads   | Configuration, feature flags, lookup tables, blocklists, sorted sets, Bloom filters | Rate limits, response memoization, idempotency keys, per-request deduplication |

The two can be used together: store the source of truth in Edge Storage and use Cache to memoize derived results or enforce per-POP rate limits.