Pricing
Start free. Pay when migrations are business as usual.
Every plan gets every rule, every PostgreSQL version and the same isolated sandbox. Plans differ in how many runs you need and how long you keep their history.
Draft · Plans and limits may change before launch. Paid prices aren't set yet.
Free
For side projects and small teams trying ShadowDB on a few repositories.
$0
forever
Get early access- 100 runs a month
- 10 runner hours a month
- 1 run at a time
- 30 days of run history
- All 32 rules
Team
Most teamsFor teams shipping PostgreSQL migrations to production every week.
Contact us
pricing coming soon
Get early access- 2,000 runs a month
- 200 runner hours a month
- 5 runs at a time
- 90 days of run history
- Usage warnings at 80%
Enterprise
For organisations with many repositories, compliance reviews and their own retention needs.
Custom
annual agreement
Talk to us- No monthly run limit
- 20 runs at a time
- 1 year of run history
- Custom audit log retention
- Runner in your own cloud, with your own keys (planned)
How usage works
Two numbers per organisation, reset every calendar month. You only hit them if your team ships a lot of migrations.
Runs
One rehearsal of a pull request's migrations. Runs that fail on our side are free.
Runner hours
Time spent in the sandbox seeding rows and replaying statements.
Soft warning
Owners hear from us at 80% of either limit, by email and in the dashboard.
Never a false pass
At the limit, pull requests get a neutral check with an upgrade link, not a green tick.
Compare plans
| Feature | Free | Team | Enterprise |
|---|---|---|---|
| Usage | |||
| Runs per month | 100 | 2,000 | Unlimited |
| Runner hours per month | 10 | 200 | Unlimited |
| Concurrent runs | 1 | 5 | 20 |
| Run history | 30 days | 90 days | 1 year |
| Usage warning before the limit | |||
| Checks | |||
| All 32 rules | |||
| PostgreSQL 14, 15, 16 and 17 | |||
| Rehearsal on seeded rows in an isolated sandbox | |||
| GitHub check on every pull request | |||
| Per-project severity and blocking policy | |||
| Inline suppressions with a required reason | |||
| Team and security | |||
| Organisation members | Unlimited | Unlimited | Unlimited |
| Audit log | 1 year | 1 year | Custom |
| Dedicated runner hosts | Planned | ||
| Self-hosted runner with your own sandbox keys | Planned | ||
| Audit log forwarding | Planned | ||
| Data Processing Agreement | |||
| Support | Community | Dedicated contact | |
Questions
What counts as a run?
One rehearsal of the migrations in a pull request: each push that changes migration files starts one. Runs that fail for a reason on our side, not your migration, aren't counted.
What are runner hours?
The time your runs spend in the sandbox, from seeding the database to the last statement. Most runs take seconds; large seeds and slow statements take longer.
What happens when we reach a limit?
Owners get a warning at 80%. At the limit, new pull requests get a neutral check that links to the upgrade page, never a false pass. A run that already started always finishes, and upgrading lifts the limit straight away.
When do limits reset?
On the first day of each calendar month, UTC.
Is our code safe on the Free plan?
Every plan gets the same isolation: each run happens in a fresh sandbox with no network, raw migration files are deleted when the run finishes, and deleting an organisation purges its data after 30 days.
Can we run it in our own cloud, with our own keys?
On Enterprise, yes (planned). You run the ShadowDB runner in your own account and point it at your own sandbox provider, such as Vercel Sandbox or your own Firecracker hosts. Your keys and your migration files stay with you; ShadowDB never stores them, and the runner only pulls jobs from us.
How much will the Team plan cost?
We're setting prices with our early access teams. Join early access and we'll share them with you before anything is billed.
Stop finding out in production.
Install the GitHub App, pick a repository, and your next migration PR gets a rehearsal.