page:migrate:heroku postgres:multi tenant relational data

Migrate Heroku Postgres: Multi-tenant relational data

Move PostgreSQL data from Heroku Postgres to Ample, one component at a time. Destination verified on Ample: a tenant column on every row and query, with a cross-tenant read returning nothing (tenant_isolation=ok).

Source procedure

Take a logical backup with heroku pg:backups:capture and download it, or pg_dump -Fc against the credentials from heroku pg:credentials:url.

Not migrated automatically: Heroku Postgres followers, forks, rollback (PITR) and dataclips have no equivalent on the managed database.

Cutover

Put the app in maintenance mode with the user's go-ahead, take the final backup, restore, validate, redeploy with the managed DATABASE_URL, keep the Heroku database until confirmed.

Rollback

Keep the source untouched until you confirm; nothing at the source is changed or deleted by this guide.

Workflow Steps

Inventory the source
List what Heroku Postgres provides beyond the component you are moving. Out of scope here: Heroku Postgres followers, forks, rollback (PITR) and dataclips have no equivalent on the managed database.
Source step 1
Take a logical backup with heroku pg:backups:capture and download it, or pg_dump -Fc against the credentials from heroku pg:credentials:url
Source step 2
Check the Postgres major version and extensions against the managed engine (PostgreSQL 16)
Source step 3
Restore into a scratch managed database first and compare row counts
Provision and restore
Deploy the app once so a managed PostgreSQL 16 database exists (or create one with ample database create --engine postgres), then restore the dump with pg_restore using its connection string; keep migrations idempotent.
```
ample database create --name  --engine postgres
```
Validate before cutover
Run the app's own checks and, for data, compare counts and checksums; the example checks are the pattern self-tests (/p/multi-tenant-relational-data).
Cut over
Put the app in maintenance mode with the user's go-ahead, take the final backup, restore, validate, redeploy with the managed DATABASE_URL, keep the Heroku database until confirmed.
Rollback
Point DNS or configuration back to the source. The source was never modified; deletion is a separate, user-executed step after validation.

Limitations

Documentation only: nothing is executed automatically and no execution binding is offered.
The source-side procedure is documented from Heroku Postgres's standard tooling and was not executed in this catalog's evidence; the destination side was verified with the pattern fixture.
No full source-product parity is claimed: Heroku Postgres followers, forks, rollback (PITR) and dataclips have no equivalent on the managed database.
Verified on the node-22 template at s-1vcpu-1gb; region, compliance and request-duration limits are unknown.
Managed PostgreSQL 16 only; extensions, connection limits and backup or restore procedures on the managed side are not verified beyond the pattern checks.

Cost Estimate

Currency: USD
Monthly Amount: 10.0
Basis: size prices from pricing.toml (loaded by the API) at build revision 1ac5595375130d45290090e82ed0f554ccd45405-dirty
- Components:
  - App server (s-1vcpu-1gb): $5.0
  - Managed PostgreSQL database (s-1vcpu-1gb): $5.0
Note: Destination always-on monthly price of the tested sizes; apps auto-pause when idle. Source costs are unknown to Ample.

Success Checks

Destination app responds on its public URL: Expected: ample canary express patterns
Multi-tenant-relational-data check from the destination example: Expected: see the pattern fixture checks
Data or object counts and checksums match the source: Expected: operator comparison before cutover.

Examples

Express pattern fixture (destination): Verified destination basis: multi-tenant relational data.
- Source Reference: tests/deploy-canaries/express-patterns

Last Verified At

Date: 2026-09-21T02:34:39Z