01 - Overview
The short version.
A target project consists of more than a PostgreSQL database. It also includes Storage, Authentication, roles, permissions, and platform-managed schemas. Recovering only the database is often insufficient to restore a working application.
Your provider gives you a database, file storage, and user accounts. It doesn't give you an easy way back if any of that disappears - a paused project past the recovery window, a bad migration, a dropped table, an accidental delete. SuperBaser automates scheduled backups, verification, and restoration of supported target project components.
You connect a project once. From then on, SuperBaser backs up your database and your Storage files on a schedule determined by your plan tier, checks every backup to make sure it's actually restorable, and rebuilds the whole thing into a fresh project in a few clicks when you need it.
The remainder of this document explains how these processes work and what is included in each stage.
02 - How It Works
Four steps, start to finish.
Connect your project
Sign in, then link your target project from inside your dashboard - never on a public page. We check compatibility before anything else runs.
Inspect the project
SuperBaser inspects the project's database schemas, Storage buckets, and supported authentication resources to determine what should be included in future backups.
Backups run on schedule
Your database and your files are captured automatically based on your plan tier - daily on Free, hourly on Pro, or every 15 minutes on Premium - and every backup is checked before it's marked trustworthy.
Restore whenever you need to
Point SuperBaser at a new project and let it rebuild - database, files, and users, all reconciled into one working project. No manual cleanup after.
03 - What Gets Backed Up
Not just your tables.
A lot of "backup" tools only mean your database rows. That's not enough to actually bring a project back - you'd have your data with no logins that work and no uploaded files. SuperBaser treats a target project as three things that all have to come back together:
Your Database
Every table, every row, every role and permission -
captured as a complete, portable SQL snapshot via pg_dumpall.
Your Storage Files
Every file in every bucket, public or private, captured separately from the database because Postgres never actually holds the file bytes.
Your Users
Accounts, sessions, and login credentials - so people can sign back in after a restore without resetting a single password.
Why files need a separate step: Postgres is a database - it stores rows, not file bytes. When you upload a photo or a PDF to Storage, the actual file lives in a separate object-storage system. Postgres only keeps a record describing it: which bucket, what path, what size, what type. A backup that only touches Postgres will faithfully record that a file should exist, without ever containing it. SuperBaser exports the files themselves as their own archive, alongside the database snapshot, so both halves are always accounted for.
04 - Backup Format
What's actually inside a backup.
Every database backup SuperBaser produces is a full cluster dump - not just your
application's tables, but every role your platform provisions (anon, authenticated, service_role, and the rest) and every
schema maintained internally, alongside your own.
| Schema | What it holds |
|---|---|
| auth | Users, sessions, identities, login credentials |
| storage | Bucket rules and per-file metadata - not the file bytes themselves |
| realtime | Realtime subscription infrastructure |
| public | Your application's own tables and data |
| everything else | Extensions, GraphQL layer, migration history, and other internal schemas |
The format is plain, readable SQL text - produced by pg_dumpall,
not a proprietary binary blob. There's a reason for that: a
plain-text backup can be inspected, verified, and restored with standard, well-understood database tooling,
with nothing locked to us. If SuperBaser disappeared tomorrow, your backups would still be usable.
Role passwords are never included in the backup file itself - role structure is preserved (who can do what), but credential secrets stay encrypted separately, never sitting in a plain-text dump.
05 - Verification
A backup you haven't tested isn't a backup.
The worst time to discover a backup is corrupt, incomplete, or silently failed is the day you actually need it. So every backup SuperBaser produces goes through an integrity check before it's ever marked as restorable:
- -The archive is checked for corruption without needing to fully unpack it.
- -The file header is validated to confirm it's a genuine, complete database dump - not a partial or malformed one.
- -Row and file counts are compared against what was actually in your project at backup time, so nothing silently drops.
If a backup fails verification, it's flagged immediately in your dashboard - not discovered three months later during an actual emergency.
06 - Restoring a Project
What actually happens when you hit restore.
Restoring rebuilds your project in two coordinated passes, because your database snapshot and your Storage files are two separate archives that have to land back in sync.
Pass one - the database
Your SQL snapshot is loaded into the new project via psql.
A brand-new target project already comes with its own
default roles and internal schemas set up - SuperBaser expects that, and works around it automatically
rather than failing or duplicating anything. Your actual data lands cleanly into the tables that matter.
Pass two - the files
Once the database pass has recreated the record of what buckets and files should exist, SuperBaser uploads
the actual file bytes from your Storage archive to match. Each file lands exactly on the record that's
expecting it - nothing duplicated, nothing orphaned. The restore tool uses the
service_role key to write files back
into private buckets that normal access rules would block.
Verification, again
After both passes, SuperBaser compares what's now in the new project against what the original backup recorded - table by table, bucket by bucket - so you're not left guessing whether the restore actually worked.
07 - Security & Access
What we ask for, and why.
We only ever collect what a given feature strictly needs, and never on a public page. Everything below happens inside an authenticated session, after you've already signed in.
| What we ask for | Why |
|---|---|
| Direct connection string | The credential that lets the backup engine connect to your Postgres database and run
pg_dumpall. Used exclusively at
backup time. |
| Project URL | Identifies your project for status checks and dashboard display. |
| Service Role Key | Needed for Storage file discovery and restore operations. The service role key bypasses RLS policies so files can be read from and written to private buckets. Stored securely by the SuperBaser Backend - never in plaintext, never in the frontend. |
Encrypted before it's stored
Credentials are encrypted the moment they leave your browser, before they're written anywhere - never sitting in plaintext, never logged.
Decrypted only at the moment of use
Your connection details are only ever decrypted for the seconds a backup or restore is actually running, then discarded.
Nothing on a public page
You sign up with just your name, email, and organization. Credentials are only ever collected after authentication, inside your dashboard.
Row Level Security enforced
Every table is protected by RLS policies. Anonymous users can preview the dashboard but cannot create organizations, connect projects, or trigger backups.
08 - Architecture
Why backups cost almost nothing and run almost instantly.
SuperBaser runs on infrastructure that wakes up exactly when a backup job needs to happen, does the work, and shuts back down - which is both faster and dramatically cheaper than the traditional always-on approach most backup tools use. Three core services work together:
SuperBaser Backend
The entry point. Receives events when a job is queued, routes them to the backup engine, and runs a scheduler every 15 minutes to check intervals.
SuperBaser Backup Engine
An isolated backup environment. Wakes up on demand, captures your database and files, streams the output to storage, then shuts back down.
SuperBaser Storage
Secure object storage for backup archives. We pass the savings of zero egress fees directly into generous limits on our lower tiers.
Because the whole engine only runs for the seconds a job actually takes, we're not paying for - or charging you for - hours of idle compute. That's the entire reason SuperBaser can afford generous limits on lower tiers without cutting corners on reliability.
Automated retention cleanup: The same scheduler that triggers backups also runs a retention pruner every 15 minutes. Backups older than your tier's retention window (7 days on Free, 30 days on Pro, 90 days on Premium) are automatically deleted from SuperBaser Storage and marked as purged. You never accumulate stale storage costs.
09 - Pricing
Plans built around how often you actually need protection.
Free
$0/mo
- 1 Connected Project
- Daily automated backups
- 7-day retention history
- Manual restore
- Community support
Pro
$15/mo
- Up to 5 Connected Projects
- Hourly automated snapshots
- 30-day retention history
- One-click verified restore
- Secure Storage Sync
- Priority email support
Premium
$49/mo
- Unlimited Projects & Organizations
- 15-minute backup frequency
- 90-day retention history
- One-click verified restore
- Secure Storage Sync
- 1-hour response SLA
How tiers are enforced: Your organization's plan is checked by the SuperBaser Backend every 15 minutes. The scheduler compares the time since your last backup against your tier's interval - 24 hours for Free, 1 hour for Pro, 15 minutes for Premium - and only enqueues a new backup job when enough time has passed. Retention cleanup runs on the same schedule, deleting archives that exceed your tier's window from SuperBaser Storage.
10 - FAQ
Questions people actually ask.
Will this slow down my live database? +
No. pg_dumpall
reads from your database the same way any client connection does - it doesn't lock tables or block normal
application traffic.
What if my project is already paused? +
If you already have backups running through SuperBaser, restoring works the same whether the original project is paused, deleted, or still live. If a project paused before you connected it, we can only work from whatever backup files your provider still lets you download.
Can I restore into the same project instead of a new one? +
Restore is designed to rebuild into a fresh project, which avoids any risk of a partial restore colliding with data that's still live in the original. If you specifically need an in-place restore, reach out - it's handled case by case.
How is this different from built-in provider backups? +
Built-in backups depend on your plan tier and stop being restorable through the dashboard once a project's been paused too long. SuperBaser runs independently of your project's own state - including Storage files, which database-only backups don't cover at all.
Do you ever see my actual data? +
Backups are handled by automated processes running on SuperBaser infrastructure, not viewed by anyone. Access credentials are encrypted at rest and only decrypted transiently, for the seconds a job is actually running.
What's the difference between snapshot backups and continuous WAL streaming? +
SuperBaser uses pg_dumpall
to take complete point-in-time snapshots of your database. Premium tier runs these every 15 minutes,
giving you near-continuous recovery points. Continuous WAL (Write-Ahead Log) streaming - which captures
every single transaction in real time - is on the roadmap but not yet implemented.
Can I download my backups directly? +
Yes. Every completed backup has a download button in
the dashboard. The download request goes through the SuperBaser Backend, which streams the file directly
from SuperBaser Storage to your browser. The backup is plain SQL text, so you can inspect it, grep it, or restore it
manually with psql if you ever need
to.
What happens to old backups? +
The retention pruner runs every 15 minutes as part of the scheduler. Backups older than your tier's retention window - 7 days (Free), 30 days (Pro), or 90 days (Premium) - are automatically deleted from SuperBaser Storage and marked as purged. You're never charged for stale storage.
11 - Glossary
Plain-language terms.
- Cluster dump
- A complete backup of everything in your database - not just your
own tables, but every internal role and schema managed behind the scenes too. Produced by
pg_dumpall. - Verification
- The check every backup goes through to confirm it's complete and restorable, run automatically before it's ever marked trustworthy.
- Restore
- Rebuilding a working project - database, files, and users together - from a backup.
- Service Role Key
- A credential that bypasses Row Level Security policies. Used by SuperBaser for Storage file discovery and restore operations so files can be read from and written to private buckets. Stored securely by the SuperBaser Backend.
- Retention window
- How long backups are kept before automatic deletion. Determined by your plan tier: 7 days (Free), 30 days (Pro), 90 days (Premium).
- Least privilege
- A security principle meaning: only ever ask for the exact access a task needs, and nothing more.
- SuperBaser Storage
- Secure object storage where SuperBaser saves your backup archives safely.