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 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 |