Regions

Choosing a region

The region is picked once, when you create the project - in the dashboard's create-project flow, or via the API by listing the available regions and passing the chosen one:

curl -s -H "X-API-Key: $CAPYDB_API_KEY" \
  https://capydb.dev/api/capydb/v1/regions | jq '.regions'

POST /v1/projects takes an optional region; omit it to let CapyDB pick a region with capacity. Point-in-time recovery and other capabilities are documented under Backups & restores.

EU data residency

All capacity today is on dedicated single-tenant EU infrastructure. Your database, its preview databases, and its compute live in the region you picked. If your data-residency requirement is "EU", CapyDB satisfies it by construction rather than by configuration. If your requirement is a specific non-EU jurisdiction, we do not have a region for you today - see Security for the broader posture.

What is co-located with the project

• Preview databases are created on the same node as their project - clones stay in-region.
• Compute and storage are the same machine; there is no cross-region split to reason about.
• Backup artifacts are written to object storage off the database node (see Disaster recovery for the mechanics).

Region is fixed after creation

There is no API to move a project between regions, and the region field cannot be edited. This is deliberate honesty rather than a missing button: a "move region" toggle would really be a full data migration wearing a trench coat.

If you do need a project in a different region, the supported path is the same migration you would run between providers:

1. Create a new project in the target region.
2. Import from the old project's direct connection URL (run the preflight first).
3. Update consumers with the new project's connection strings - they differ, since it is a new database with new credentials.
4. Delete the old project when you are confident.

Latency, practically

Your database answers from its region; physics does the rest. Put latency-sensitive app servers near the region, and use the pooled endpoint so connection setup cost is paid rarely instead of per-request.

This is usually the single largest number in a slow page, and it is the cheapest one to fix. Serverless platforms default to a US function region. Against an EU database that is roughly 80-100ms per round trip, before your query does any work at all - so a page that issues four queries in sequence spends a third of a second waiting on the Atlantic while the database itself is busy for under a millisecond. Moving the functions is a config line; optimizing the queries is not.

Pin your functions to an EU region:

export const preferredRegion = 'arn1' // or 'fra1'

{ "regions": ["arn1"] }

arn1 (Stockholm) is closest to EU North, fra1 (Frankfurt) to EU Central; either is fine for either, and both are far better than a US default. On Netlify, set the function region in the UI or netlify.toml; on Cloudflare Workers, enable Smart Placement so the worker runs near the origin it talks to rather than near the visitor. Anywhere you control the machine (a container, a VM), pick the EU location the provider offers.

Then reduce the round trips themselves: prefer one query with a join over several sequential ones, and be aware that a client pool with max: 1 makes even Promise.all serialize - see client pool size in serverless functions.