For PostgreSQL
Postgres on Edge,
without the RDS markup
Self-hosted PostgreSQL on dedicated NVMe, with WAL archiving to S3-compatible storage and replication over private networking. Real performance, predictable bills, no managed-service guard rails.
# Provision a Postgres VM with NVMe
$ edge compute create \
--image ubuntu-24-04 --plan db-medium \
--script ./bootstrap-postgres.sh
# pgbackrest.conf — WAL → Edge Storage
[global]
repo1-type=s3
repo1-s3-endpoint=storage.edge.run
repo1-s3-bucket=postgres-wal
repo1-s3-region=eu-west
# Backup + verify
$ pgbackrest --stanza=main backup
✓ archive-push, basebackup complete
Why Postgres teams pick Edge
All the Postgres features, none of the managed-service "you can't do that" answers.
NVMe storage that doesn't throttle
Real local NVMe on every Edge VM — no per-IOPS billing, no burst credits to track. Postgres is happy when its disk is happy.
WAL archiving to S3
Pipe WAL segments to Edge Storage with `wal-g` or `pgbackrest` for point-in-time recovery — without the per-GB-month bills RDS charges for snapshots.
Replication on private networking
Run a primary + replicas on separate Edge VMs over private networking. No cross-AZ data transfer fees, no public-internet exposure.
Any version, any extension
Pin to whatever Postgres version you want. Install PostGIS, TimescaleDB, pgvector, pg_cron — anything that compiles, anything you compile yourself.
Pgbouncer / PgCat included
Run a connection pooler on the same VM (free) or a dedicated tiny one (cheap). No managed-service connection-limit panics.
No per-instance-hour markup
A db.r6g.large RDS instance is ~$220/month before storage. The same workload on an Edge VM with bigger NVMe is a small fraction of that — no licence fee.
Reference architecture
How Postgres maps to Edge
Primary on a sized-to-fit VM, optional streaming replica, WAL archived to object storage. Standard Postgres ops, modern infrastructure.
Postgres + Pgbouncer on a VM, with NVMe for the data directory
WAL archive bucket + nightly basebackups for PITR
Anycast DNS for `db.example.com` — point it at the primary
Optional second VM as a streaming replica via private networking
Indicative cost
Mid-sized production DB
~4 vCPU, 16GB RAM, 500GB storage, daily backups, 100GB WAL/day
Indicative figures. Add a second VM for HA replication.
Common questions
How does this compare to RDS / Aurora?
Cheaper (no per-instance-hour, no per-GB snapshot fees, no per-IOPS bills) and faster on like-for-like hardware (real NVMe). Trade-off: you handle backups, upgrades and HA — or our Expert Services team can.
How do I do high availability?
Streaming replication to a hot standby on a second VM, plus automated failover with Patroni or repmgr. Both work cleanly on Edge VMs over private networking.
What about backups?
Use `pgbackrest` or `wal-g` to ship WAL segments and basebackups to an Edge Storage bucket. Point-in-time recovery without paying RDS' premium for the privilege.
Can I use it from other Edge resources?
Yes — connect over private networking from your app VMs (Laravel, Django, Rails, Node.js, etc.). Latency is sub-millisecond, no egress fees between Edge resources.
By Stack
Other stacks on Edge
Run Postgres on your terms
30-day trial. Migrate from RDS or stand up a fresh cluster — Expert Services can plan the cutover.