My test app and my live app share a database. What do I do?
If your test copy and your live app share a database, every experiment you or your coding agent runs is changing your customers' data. Until you have proved otherwise, treat the test copy as live: no schema changes, no seed scripts, no 'just try it' prompts.
The proof is simple. Add a record in the test copy and look for it in the live app. If it shows up, they share a database. The fix is to give the test copy its own database, loaded with a copy of the live data with personal details removed, after taking a backup of the live database and restoring it once so you know the backup works.
This happens more than people expect because the tools copy the database connection along with the code. Replit's older forks did exactly that, and Replit shut those shared databases down on June 8, 2026. A project that was remixed or duplicated before then may still be wired this way, and a second Lovable or Bolt project pointed at the same Supabase project is the same situation.
In founders’ words
“I have an original Replit project and a remix/test copy and read only checks show the same PostgreSQL system identifier and database OID for both.”
How to tell, in each tool
Start with the behavior test above; it works everywhere. Then confirm in the settings.
- Replit: open each app's secrets and compare DATABASE_URL. The same value means the same database. Replit's docs say that under its old Neon setup 'forking an app copied the original app's DATABASE_URL, so both apps and their published versions connected to the same database'. A connection string containing neon.tech is the legacy kind. New apps get a development database and a separate production one when you publish.
- Lovable or Bolt with Supabase: compare the Supabase project URL in each project's settings. One Supabase project is one database, so the same URL means shared. A Bolt version restore never touches the database, so a rollback does not undo a shared write.
- Base44: check whether the Test Data toggle in App settings is on. When it is, Base44 creates a separate empty database. Your published app always uses production data, so prompts run with the toggle off change live records.
- Any tool: ask your coding agent to print which database the test copy connects to, without changing anything, and compare.
Why it matters before anything has broken
A shared database fails quietly for a while and then all at once. Test users appear in your customer list and get your marketing emails. An agent renames a column to try an idea and the live app errors for everyone. A seed script that 'resets the data' resets the data. A test of the cancellation flow cancels a real customer.
The test copy is also usually the less protected one. It often has the same data behind looser rules, a public address nobody remembers, and a copy of the service key that bypasses the database's row rules. Separating the databases is a security fix as much as a safety one.
Separate them without losing anything
In this order. Each step is reversible until the last one.
- Back up the live database now, and restore that backup into a fresh, separate database once. An untested backup is a hope.
- Stop running the agent, migrations or seed scripts in the test copy until it has its own database.
- Create the new database: in Replit, publish or republish with 'Create production database' so the live app gets its own; in Supabase, make a second project with an obvious name such as myapp-test; in Base44, turn on the Test Data toggle.
- Copy the structure, then load the test database with a copy of live data with names, emails and payment details replaced. Real shapes, fake people.
- Point the test copy at the new database by changing its connection setting, never the live app's.
- Re-run the behavior test: add a record in the test copy and confirm it does not appear in the live app.
- Put the environment name somewhere visible in the test copy, a coloured banner or a title prefix, so nobody mistakes one for the other again.
The rule that keeps it safe
Supabase's own guide for people building with AI tools says it in four words: 'never work directly on production'. From now on, every structural change (a new table, a renamed column, a migration) is tried in the test copy first, and reaches the live database only after it has worked there, with a fresh backup taken right before.
Keep connection strings and keys in each environment's own settings, never in the code, so a copied project cannot carry the live connection with it. Give the two databases names you cannot confuse. And tell your coding agent, in its instructions file, which environment it works in and that it never touches the other one.
When one database is fine
Before any real customer, when the only data in the app is yours and a few testers', one database is fine and a staging copy is a chore you do not need yet. Keep building.
The moment to separate is the first record that belongs to someone who did not agree to be an experiment. From then on the test copy needs its own database, and a backup you have restored once is the cheapest insurance you will ever buy. If you have already found that the two are shared and customers are on the app, the steps above are an afternoon's work, and that afternoon is today.
| Tool | Where to look | Does a copy get its own database? |
|---|---|---|
| Replit | DATABASE_URL in each app's secrets; development and production databases in the Database panel | Yes for apps made or remixed now. Forks from before January 9, 2026 on the old Neon setup could share; those shared databases were shut down June 8, 2026 |
| Lovable or Bolt with Supabase | The Supabase project URL in each project's settings | Only if you make a second Supabase project and point the copy at it |
| Bolt database | Database panel in each project | A new project gets its own; a version restore never changes the database |
| Base44 | App settings, Test Data toggle; the Data tab shows which set you are in | Yes once the toggle is on; the published app always uses production data |
Questions
How do I know which database my Replit app uses?
Open the app's secrets and read DATABASE_URL. If it contains neon.tech it is the older kind and worth checking against any app it was forked from. Since publishing creates a separate production database, the live app should use that one and the editor the development one; Replit's Database panel shows both.
Can my coding agent delete live data?
Yes, if it is connected to the live database, and it will not always tell you. That is the whole reason for a separate test database and a tested backup. Give the agent the test environment and keep the live connection out of its reach.
Do I need a staging copy at all?
Not before real customers. Once their data is in the app, you need somewhere to try changes that is not their data. It does not have to be elaborate: a second project, its own database, a copy of the data with personal details replaced.
Can I copy live data into the test database?
Yes, and you should, because test data that looks nothing like real data hides bugs. Replace names, emails, phone numbers and anything about payments before you load it, so a leak from the less-protected test copy exposes nobody.
What about Supabase branching?
Supabase can also create a temporary branch of a database for trying changes. For a founder managing one app, a second project with an obvious name is easier to reason about and harder to confuse with the live one. Either way the live database gets a fresh backup before a change lands.
First look, $750. After a free call, we read your whole product and tell you what is finished, what is not, and what to do first.
Setup, $3,000 fixed. We make it ready for real customers, in accounts you own.
Partner, $2,500 a month. We review what your coding agent writes and keep the checks and tests current. Month to month.