Other runtimes: the equivalent Postgres client for your language
When one is found, a database is provisioned before your first deployment
finishes, and its connection string is injected as DATABASE_URL.
Provisioning is idempotent per application. Redeploying reuses the existing
database rather than creating a second one; your data survives every deploy.
If your code already uses Supabase, Neon, Firebase or another hosted database,
Antideploy notices and does not create a second one. It carries your
existing credentials across instead.Set the connection string as an environment variable and it is injected at
release, taking precedence over anything Antideploy would have provisioned.
The dashboard includes a read-only browser for your application’s database
(tables, columns, and row counts), so you can confirm a migration landed
without connecting a client.This works both for databases Antideploy provisioned and for a Postgres URL
you supplied yourself.
If your project has a migration step, Antideploy runs it as part of the
deploy, before the new version starts serving. A failed migration fails the
deploy rather than releasing a version your schema cannot support.
The database belongs to the application. Deleting the application deletes the
database and everything in it.
Deletion is permanent. Antideploy does not expose backups, snapshots or
point-in-time restore; if you need a copy of your data, take one yourself
with pg_dump before deleting an application.
⌘I
Assistant
Responses are generated using AI and may contain mistakes.