Paused project shows an impossible pause date and the downloadable backup contains no user data

[vvaselin]

Hello,

I have a Supabase project that is currently shown as paused for more than 90 days, but the displayed pause date is inconsistent with the actual project history.

The project was created in 2025, and the most recent pause occurred in July 2026. However, the dashboard shows a pause date from 2024 and says that the project can no longer be restored through the dashboard.

I downloaded the database backup provided by the paused-project dashboard and inspected the decompressed SQL dump.

The backup contains:

• no tables in the public schema
• no custom schemas or custom tables
• 0 rows in auth.users
• 0 rows in auth.identities
• 0 rows in storage.buckets
• 0 rows in storage.objects

It only contains definitions for Supabase-managed schemas such as auth, realtime, and storage.

I verified the decompression by extracting the archive in two different ways and confirming that both files had the same SHA-256 hash.

I also attempted to restore the backup into a new Supabase project using PostgreSQL 17 and a Session pooler connection. The connection succeeded, but no application tables or data were restored.

This matters because some participant logs from a completed research experiment were not exported to CSV and may only exist in the original database.

Has anyone encountered:

1. an incorrect pause date shown for a project,
2. a project being treated as paused for more than 90 days incorrectly, or
3. a downloadable recovery backup that contains no user data?

I have already opened a private support ticket and can provide the project reference, backup file, screenshots, and restore logs privately if a Supabase team member needs them.

[vvaselin]

この質問を撤回します。無視してください。

[DishantBhere]

Wrong pause date usually means dashboard pulled snapshot metadata from earliest recorded pause event in project history, not the most recent one. If project got paused, unpaused, then paused again later, some backend jobs track only first pause timestamp for retention calc, which explains why it shows 2024 despite real activity through 2026.
Empty backup (no tables, 0 rows everywhere) strongly suggests backup was generated from a stale automatic snapshot taken near original creation time, before your data existed, not from most recent state. That happens when the 90 day archival process picks oldest retained snapshot instead of latest available one, especially if project sat paused across multiple cycles.
Since you already opened private ticket, keep pushing there, this needs backend team pulling from physical storage layer (WAL / PITR snapshots), not the downloadable dashboard export, which only reflects logical dump, and clearly picked wrong point in time here.
Ask support specifically for point in time recovery from raw storage rather than relying on dashboard backup download, chances are actual data still exists on disk, just not represented by that particular export.

[jg-noncelogic]

backups on serverless database providers like neon and supabase have been a problem for me, compound that with soc2 and it was such a tedious and repetitive thing that I tried to make a product for it. happy to share the code, solution or any technical details you might need but basically the solution is to keep a worker in fly.io constantly monitoring the database. i could use some feedback on the tool because it might actually solve this problem