Available today
Self-serve backups
The dashboard lists daily backups, generates download links, and lets you queue a clean-slate restore yourself. Starter and Builder keep 7 days. Pro keeps 30 days.
MVP DB is designed to feel fast and simple for makers, but the docs should still answer the questions you ask when a side project starts becoming a real product. This page documents what exists today, what is self-serve, and what is not yet in the product.
Current scope
Engine
PostgreSQL 17
Restore model
Dashboard-triggered clean-slate restore
Visibility
Storage, schema, backups. Not query analytics.
Access model
Normal PostgreSQL drivers. No proprietary database SDK.
Available today
The dashboard lists daily backups, generates download links, and lets you queue a clean-slate restore yourself. Starter and Builder keep 7 days. Pro keeps 30 days.
Available today
You can see storage for the current database plus the shared subscription footprint, including how much each database is using inside that subscription.
Available today
The dashboard exposes a read-only schema browser with tables, columns, indexes, and a downloadable SQL snapshot of your current schema.
Available today
MVP DB does not require a proprietary database SDK. Use pg, Prisma, Drizzle, Npgsql, Dapper, EF Core, psycopg, psql, or your normal SQL tooling.
Provision a database
Create a database from the dashboard and label it by project or environment.
Copy the connection string
Use the dashboard connection card to copy the full DATABASE_URL.
Store it as a secret
Add it to your app platform's environment-variable or secret-store settings, not to source control.
Connect with standard tooling
Use your normal Postgres driver, ORM, migration framework, and admin client.
MVP DB supports dashboard-triggered restore from retained daily backups. This is a replace-the-current-data workflow, not point-in-time recovery.
01
In the database detail view, open the Backups tab to see retained daily backups for that database.
02
You can download a backup directly or trigger Restore from a specific retained backup.
03
The restore request is queued and processed by the control plane. You do not have to open a support ticket for the standard restore path.
04
Active connections are terminated, current data is replaced with the selected backup, and the database comes back on the same connection endpoint.
Important boundaries
In product now
Not yet exposed in the dashboard
That distinction matters if you are evaluating MVP DB as a low-friction PostgreSQL host rather than as a full observability platform.
The direct pipe works well for small apps. For anything important, rehearse on staging first and use a deliberate cutover.
Safer production cutover
pg_dump --format=custom --no-owner --no-privileges "$OLD_DB" > app.dump pg_restore --clean --if-exists --no-owner --no-privileges --dbname="$MVP_DB_URL" app.dump DATABASE_URL and redeploy.
Test this against staging first. The --clean path intentionally replaces objects in the target database.
Use a disposable database for local work and experimental migrations. Label it clearly in the dashboard so it never gets confused with customer data.
Mirror schema changes, test restores, and rehearse cutovers here first. This is the right place to validate pg_restore behavior before touching production.
Keep production isolated from test traffic. If you want separate billing or storage envelopes, use a separate subscription instead of sharing one big bucket.
Secrets hygiene
DATABASE_URL in your platform secret store or environment configuration.MVP DB is standard PostgreSQL. Use any client or ORM that speaks Postgres.
Need help validating a migration or understanding a restore outcome? Reach out at admin@rashtan-soft.com.