Bolt.new Database: Connect a Real Postgres Backend

Bolt.new gives every project a built-in Bolt Database, and on Pro or Teams plans you can connect a Supabase project instead or claim your Bolt database into your own Supabase account. To run a Bolt app on another Postgres backend, you take the code out through Bolt's GitHub integration, move the data with a migration tool, and point the app's Supabase client at the new project's URL and key. This guide covers each of those options, what they cost, and the exact steps for a backend such as StitchDB that speaks the same APIs as Supabase.

Bolt facts come from Bolt's own help center and pricing page as of November 2026. Bolt changes quickly, so check the linked pages for the current menus.

#How databases work in Bolt today

Bolt's help center describes three ways a project can store data:

A few details worth knowing before you click anything:

• The agent decides. With the current agent, Bolt creates a database when the project needs one or when you ask for a database feature. Projects on the legacy v1 agent can inherit a Bolt database but cannot create new ones.
• Connecting replaces. Connecting a Supabase project to a project that already has a Bolt Database replaces that connection, and Bolt warns this can lose data. If you want to keep the data, claim the database instead.
• One Supabase organization per Bolt account. You can disconnect and reconnect, but not switch organizations without disconnecting first.
• Limits live in settings. Bolt does not list database limits on the help page; you find them under Settings › Cloud.

Pricing as of November 2026: Free is $0 with 1M tokens a month; Pro is $25 a month with 10M tokens to start and "expanded capacity" for databases; Teams is $30 per member per month. Supabase itself bills separately if you connect your own project (Free, or Pro from $25 a month).

#When the built-in database is enough

Keep the Bolt Database if the app is a prototype, a demo or an internal tool and you do not need to reach the data from anywhere but the app. It is included, needs no setup, and the agent wires up auth and tables for you.

Move to a backend you control when one of these becomes true:

• You need to query the data from another service, a BI tool or a script.
• You want backups and point-in-time recovery you configure yourself.
• You want to use Cursor, Claude Code or another agent on the same database with its own scoped access.
• You care about the region your data is stored in.
• You want the backend bill to be separate from your app builder's tokens.

#Export your Bolt data

There are two ways to get data out:

1. Per table. Bolt's Tables page lets you filter, query and export row data. That is fine for small tables or a one-off backup, but it does not carry auth users with their passwords.
2. The whole database, by claiming it. On Pro or Teams, claim the Bolt Database into your own Supabase account from the database panel's Advanced tab. You then have a normal Supabase project with a connection string, which any Postgres tool and migration wizard can read.

For a real move, use the claim. It keeps tables, auth users and files together.

#Get the code out

Bolt's GitHub integration commits every change that does not break the project, and checks GitHub every 30 seconds for changes made outside Bolt. Connect it from the GitHub icon in the top right of the editor. Note that disconnecting a project from GitHub is permanent in Bolt.

Once the code is in GitHub, you can run and deploy it anywhere. Find where the project creates its Supabase client:

grep -rn "createClient" src/

The call reads the project URL and key from environment variables. Note their names; you change only their values.

#Connect a Bolt app to StitchDB

StitchDB is a hosted backend with a dedicated Postgres database per project plus Auth, REST, Realtime, Storage and Deno Edge Functions. It speaks the same APIs as the open-source Supabase stack, so the supabase-js code Bolt wrote works after you change the URL and keys (compatibility). There is no official Bolt integration: you connect through the code and the environment variables.

#1. Copy the data

Claim the Bolt Database into Supabase (above). Then create an empty StitchDB project and open Database › Import from Postgres › Import from Supabase in Studio:

1. Paste a Supabase personal access token and choose Find projects.
2. Pick the claimed project and enter its database password.
3. Choose Check project, review what will be copied, fill in secret values, and start the copy.

The import copies tables and data, RLS policies, auth users with their password hashes, buckets and files, cron jobs, Auth settings and edge function code (import guide). With a live copy, your Bolt app keeps running on the old database until you switch over, which takes seconds.

#2. Change two values

Set the variables your client reads to the StitchDB project URL and anon key (both in Settings › API). For a Vite app that might look like this:

VITE_SUPABASE_URL=https://<project-ref>.p.stitchdb.com
VITE_SUPABASE_ANON_KEY=<anon key>

The client code stays as it is:

import { createClient } from '@supabase/supabase-js'

export const db = createClient(
  import.meta.env.VITE_SUPABASE_URL,
  import.meta.env.VITE_SUPABASE_ANON_KEY,
)

const { data, error } = await db.from('tasks').select('*').order('created_at')

Vite embeds these values at build time, so rebuild and redeploy after changing them.

#3. Check it in a minute

curl "https://<project-ref>.p.stitchdb.com/rest/v1/tasks?select=*&limit=1" \
  -H "apikey: <anon key>" -H "Authorization: Bearer <anon key>"

Then sign in as a real user in the app and check that each user still sees only their own rows.

#4. Things that do not move by themselves

• OAuth providers. Add https://<project-ref>.p.stitchdb.com/auth/v1/callback to each provider's console and enter the client secrets in Authentication › Sign-in methods.
• Secrets. Their values cannot be read from the old project. Set them under Edge Functions › Secrets or with stitchdb secrets set.
• Bolt's database panel. After the move, Bolt's own database tools no longer manage this backend. You change the schema with migrations instead.

#Keep building after the switch

You can keep using Bolt for the front end through GitHub sync, and make schema changes with tools that talk to the database directly:

npm install -g stitchdb-cli
stitchdb login
stitchdb init
stitchdb link --project-ref <project-ref>
stitchdb db pull                       # current schema as your first migration
stitchdb migration new add_due_date    # then write the SQL
stitchdb db push                       # review and apply

Or let your coding agent do it over MCP with a scoped key. With an agent key, statements such as DELETE without WHERE or DROP TABLE wait for your approval, and every session can be undone. Setup for Cursor is in give Cursor safe access to your database.

New project and no data yet? Skip the import. Create a StitchDB project, put its URL and key in the environment variables before you ask Bolt for database features, and apply schema changes with the CLI or MCP.

#Bolt Database vs your own Postgres

Bolt's built-in database wins on convenience. Supabase wins if you want to keep Bolt's native integration and a large ecosystem. StitchDB fits if you want the same client code on a lower, capped plan with point-in-time recovery included and EU hosting, and are fine managing the schema outside Bolt.

#FAQ

#What database does Bolt.new use?

New projects get a Bolt Database by default, with tables, auth, file storage and server functions managed in Bolt. On Pro or Teams you can connect a Supabase project instead.

#How do I export my database from Bolt.new?

Export single tables from the Tables page, or on Pro and Teams claim the whole Bolt Database into your own Supabase account, which gives you a standard Postgres connection.

#Can Bolt connect to my own Postgres database?

Bolt's built-in options are Bolt Database and Supabase. Any backend that implements the Supabase APIs, such as StitchDB, works through the app's code and environment variables, but Bolt's database panel will not manage it.

#Will my users need to sign up again?

No. A Supabase-compatible import copies auth users with their password hashes. Users sign in once more because sessions are not copied.

Move your Bolt app to Postgres you control: read the compatibility notes and the import guide, then create a free project.