Bolt database issues: permission errors, paused databases and missing data

Bolt Database is Postgres, set up and run for you by Bolt Cloud. Its security checks are the same ones Supabase's Security Advisor runs, and its settings all live behind the database icon at the top centre of your project. Because Bolt manages so much of it, most database problems in a Bolt app are about Bolt Cloud's own behaviour: pausing, permissions defaults, version restores and duplicates. Those are worth ruling out before you start rewriting queries.

Symptom

Match what you see to the list:

• A table Bolt created recently returns a permissions error, while older tables work.
• The app loads with no data, or errors, after you restored an earlier version.
• A duplicated project has your tables but none of your users or records.
• The Tables page shows rows you can't edit or delete.
• Bolt reports the database is unresponsive or timing out.
• After a few days away, opening the project shows this message:

Why it happens

New tables are private by default. From 30 October 2026, Bolt Database keeps new tables private, and your app needs explicit permission to read or write them. Existing databases aren't affected. Bolt should set permissions when it creates tables, but if it misses one you get a permissions error on that table only.

Unpublished projects pause. If an unpublished project's database has low use for six days or more, Bolt may pause it. Published projects aren't paused. A staging copy you rarely open will keep hitting this.

Version history doesn't touch the database. Bolt's docs are explicit: restoring an earlier version doesn't change your current Bolt or Supabase database. Roll the code back past a migration and the code expects columns that no longer match.

Duplicates get a fresh, mostly empty database. A duplicate gets the same tables and any starter data, but not user accounts, data your users created, uploaded files, secrets or sign-in settings. Server function code is copied as files but not deployed.

Tables without a primary key are read-only in the UI. Bolt's Tables page can't add, edit or delete rows on a table with no primary key.

Connecting Supabase over a Bolt database replaces it. On Pro and Teams plans you can connect a Supabase database, but Bolt warns this replaces the existing connection and may cause data loss.

The fix

1. Find the real error first

Open the database icon, then Logs, and pick PostgreSQL or PostgREST from the dropdown. The Logs page only shows the past hour, so reproduce the problem and check straight away. In the browser, open DevTools and read the failing request in the Network tab. If the console mentions a Supabase URL while you're on a Bolt database, Bolt's docs say to contact support.

2. Fix permissions on a private table

Bolt's own advice is to ask Bolt to fix the table permissions. Be specific about who should do what:

The bookings table returns a permissions error. Give signed-in users permission to read, add and update only their own bookings, where user_id matches their account. Don't give anonymous visitors access.

When it's done, open the table and click View Policies. You want something close to this:

-- Example: public.bookings with a user_id column.
-- Tables created since 30 October 2026 have no API access until a role is granted it,
-- so without this line the policies below never come into play.
grant select, insert, update on public.bookings to authenticated;
 
alter table public.bookings enable row level security;
 
create policy "Users read own bookings" on public.bookings
  for select to authenticated using ((select auth.uid()) = user_id);
 
create policy "Users add own bookings" on public.bookings
  for insert to authenticated with check ((select auth.uid()) = user_id);
 
create policy "Users update own bookings" on public.bookings
  for update to authenticated
  using ((select auth.uid()) = user_id)
  with check ((select auth.uid()) = user_id);

Then open Security in the database settings. If it lists RLS Policy Always True, a policy lets anyone in, which is the opposite problem.

If policies are tangled, Bolt's troubleshooting docs suggest asking Bolt to remove all the policies on the affected table, then add back the one rule you want, stated precisely.

3. Restart an unresponsive database

Open the database icon, then Advanced, then Restart. It's unavailable for a few minutes while it restarts. If it's still unresponsive after that, check the Bolt status page and then contact support.

4. Realign code and schema after a restore

Check what the database actually has, using Query on any table in Tables:

select table_name, column_name, data_type, is_nullable
from information_schema.columns
where table_schema = 'public'
order by table_name, ordinal_position;

Paste the result into the chat and ask Bolt to make the code match the current schema, or to add back the columns the code expects. Don't restore further back hoping the database follows. It won't.

5. Bring a duplicate to life

In the new project, set up sign-in again under Authentication, re-add every secret under Secrets, and ask Bolt to add a comment at the top of each server function file. Bolt's docs describe this as the way to make it treat the files as changed and deploy them to the new database. Users and their data don't come across, so a duplicate is a fresh start, not a copy.

6. Add a missing primary key

alter table public.notes
  add column if not exists id uuid primary key default gen_random_uuid();

Only run this if the table has no primary key at all. If it has a natural key, ask Bolt to make that the primary key instead.

How to prevent it

• Export a backup before risky changes. In Tables, open a table, tick the header checkbox to select all rows, then Export as CSV or JSON. Do it for every table you care about.
• Publish the projects you rely on, so their databases don't pause.
• Make schema changes through Bolt, one at a time, and test after each.
• Before connecting a Supabase database, read the warning. If you want your data in Supabase, claim it from Advanced on a Pro or Teams plan instead.
• Treat the Query tool with care. It runs any SQL, including deletes.

When to get help

If the schema itself is the problem, such as records with no clear owner or data copied into several tables, prompting tends to make it worse. Read fixing the database schema in an AI-built app and, if access rules are involved, Bolt auth not working. The fix guide for vibe-coded apps shows how database problems connect to the rest, and taking a Bolt app to production covers the full launch checklist.

Run the free vibe-code health check first. If the data model needs real work, a Rescue Sprint is an audit plus fixes, priced after the health check and usually done in about a week.