# Upstash read replicas and regional setup
## The model
One primary region, zero or more read regions. Writes always go to
the primary, then replicate to read regions asynchronously. Reads
are served from the nearest region. A database with no read regions
behaves like a single-region database.
## Setup order
1. Create the database in the region where most writes originate.
That choice dominates your write latency.
2. Add read regions where your readers are: edge functions, app
servers, mobile API backends.
3. You can add or remove regions on a running database. No
downtime, no re-import.
## Routing
With the REST API and the SDKs, routing is automatic: clients hit
the nearest region. You do not configure replica endpoints by
hand. Writes still travel to the primary under the hood, so a write
from a read region pays the cross-region trip.
## Consistency note
Replication is asynchronous. A read in a read region right after a
write can return the previous value. Build read-your-writes paths
for flows where that matters (just-wrote-then-display).
## Cost
Each read region adds to the bill: fixed plans charge per read
region per month, and pay-as-you-go counts replicated writes as
commands. Size the region list to where readers actually are, not
where they might be.
## Verify
Write a key, read it from each region, and confirm convergence.
Measure read latency per region: it should track distance to the
nearest region, not to the primary.