Regions

When you create a database, PerSQL passes a Cloudflare DO location hint that tells Cloudflare where to home the SQLite state. The default — Auto (smart placement) — lets Cloudflare put the database where the traffic is. Pick a specific region if you have a regulatory or latency reason.

Available regions

Code	Region
auto	Smart placement (default)
wnam	Western North America
enam	Eastern North America
sam	South America
weur	Western Europe
eeur	Eastern Europe
apac	Asia-Pacific
oc	Oceania
afr	Africa
me	Middle East

These map directly to Cloudflare DO location hints — see Durable Objects docs for the underlying behavior.

Behavior

• The hint applies once, on first DO startup. After that, the DO’s home is fixed unless the database is destroyed and recreated.
• Reachability is global. A database homed in weur is still callable from anywhere — clients in Asia just pay a higher round-trip on each request.
• Cloudflare may relocate databases over time even when a hint was set; the hint is a strong preference, not a guarantee.

Where it shows

• The Create database dialog has a Region dropdown.
• The Fork dialog also offers Region — useful for putting a staging fork close to a different team.
• The database header shows the friendly region label (hover-title shows the raw code).

REST

curl --cookie cookies.txt \
  -X POST https://api.persql.com/api/namespaces/acme/databases \
  -d '{"name":"Orders EU","slug":"orders-eu","region":"weur"}'

Same field on POST /databases/:db/fork. Unknown values fall back to auto.

Tips

• For latency-sensitive workloads, pick the region closest to the bulk of your writes. The DO is single-instance; reads from far away pay the same RTT as writes.
• If you serve users globally and writes are evenly spread, leave it on auto — Cloudflare’s smart placement handles it.
• Regions don’t affect:
  • PITR / snapshots (per-DO, regardless of home).
  • R2 archives (use a separate bucket location).
  • BLOB storage (shared R2 bucket).