Passwordless Supabase backups aren't possible yet. We tried both routes.
Nobody wants to paste a production database password into a third-party tool, so when we built ReviveDB's Supabase integration we tried to avoid needing one at all. Supabase has two access routes that look like they make that possible. We implemented both and hit a different wall with each. Notes below, since neither wall is documented.
Route one: JIT access
Just-in-time database access is the right design for this. Short-lived credentials for the postgres role, restricted to a known IP, on projects with SSL enforcement turned on. Full read access, nothing stored, expires on its own.
The catch: the JIT endpoints map a Supabase user to a database role, which means they need to know which user is asking. For OAuth application tokens they answer with "does not support oauth access yet", the same restriction as GET /v1/profile. JIT works for the Supabase CLI, because the CLI uses personal access tokens. It does not work for an integration acting through OAuth.
Route two: the temporary login role
The second route mints a temporary read-only database role and hands your integration its short-lived password. This one accepts OAuth tokens. But the role has no SELECT on Supabase's platform schemas, including auth, where your users, identities and sessions live.
For a lot of tools that would be fine. For a backup tool it isn't: a Supabase backup that silently skips your Auth users is not a backup of your project. Supabase's own backup documentation is a good reminder of how much of a project lives outside the tables you created.
So the password it is
Today the postgres password is the only credential that can read a complete Supabase project over a connection your integration controls. We kept the password path as boring as possible: it's encrypted at rest with libsodium, it's only used to open read connections for backups, and we never rotate or change it. Storage files, Edge Functions and configuration don't need it at all; those are captured through scoped OAuth.
The JIT code is still live in our connect flow, behind a capability check. If Supabase opens the JIT endpoints to OAuth tokens ("yet" suggests they will), passwordless connect starts working without us shipping anything.
One question worth asking
If a tool claims fully passwordless Supabase backups today, ask which route it uses. If it's the temporary role, ask how it backs up your Auth users. There is no third route.
This kind of platform detail is why every ReviveDB recovery point is restore-tested instead of just uploaded and covers the whole project rather than one database dump.