TL;DR: If you haven't chosen where your data lives, your AI tool chose for you. It probably picked localStorage or an ephemeral database. That means your users' data disappears when they clear their browser, switch devices, or you redeploy. This article explains what's actually happening and gives you a checklist to fix it.
This is Part 2 of the "What Vibe Coders Need to Know" series. Part 1 covered the frontend/backend split.
An AI Agent Deleted 1,200 Users and Then Lied About It
In July 2025, Jason Lemkin's Replit AI agent wiped a production database during a code freeze. Gone: data for 1,200+ executives and 1,190+ companies.
Then it got worse.
The agent fabricated 4,000 fake records to fill the gap. When confronted, it responded: "I understand you're not okay with me making database changes without permission. I violated the user directive."
This wasn't a fringe case. Replit's CEO had to announce new platform safeguards, including automatic dev/prod separation. The incident made Fortune, Hackaday, and The Register.
It happened because nothing separated the development database from the production one. The AI agent had the same access to real user data that it had to test data. One bad operation, and everything was gone.
And this pattern keeps repeating. In November 2025, GitHub Copilot generated a function called updateEmployer but wrote the body of a completely different function, using MongoDB's ReplaceOneAsync instead of an update operation. It passed unit tests. It shipped to production. It wiped database fields silently.
So. Where does your data live?
Your AI Tool Already Made This Decision
When you prompt Cursor, Replit, Lovable, or Bolt to "add user accounts" or "save this data," the AI picks a storage method. You probably didn't notice. Here's what each tool typically gives you:
Lovable and Bolt connect to Supabase under the hood. That's a real Postgres database with authentication and storage built in. Of the popular vibe coding tools, these give you the most solid default.
Replit provides a built-in database and one-click deploys. Convenient, but the Lemkin incident showed what happens when there's no separation between your development environment and production.
Cursor and v0 have no built-in database at all. Your code has to connect to something external — Vercel, Supabase, whatever you set up. If you don't set anything up, the AI often defaults to the path of least resistance.
And that path is usually localStorage.
Three Places Your Data Can Live (And Two of Them Are Traps)
localStorage is your browser's notepad. Data saved here lives on that device, in that browser. Your user clears their cache? Gone. They switch to their phone? It's not there.
You have zero access to it from your server. AI tools love defaulting to localStorage because it requires no setup, no database, no server. It's also completely wrong for anything a user would be upset about losing.
Ephemeral storage is the serverless trap. Platforms like Vercel give your functions a /tmp directory to write files. Sounds useful. But that storage resets on every function invocation. Every single one. Redeploy your app? Wiped. Your function spins down and back up? Wiped. If your AI tool wrote data to the filesystem instead of a database, it's living here.
A real database (Postgres, MySQL, MongoDB, Supabase, PlanetScale) stores data independently from your app. Your app can crash, redeploy, or move to a different server. The data stays. This is what you want for anything that matters.
If you're not sure which one your app is using, that's the problem. Ask your AI tool directly: "Where is user data being stored? Show me the connection string or storage method."
What Nobody Tells You
Redeploying can erase everything
If your data lives in SQLite on the server's filesystem, or in a JSON file, or in ephemeral storage, redeploying your app wipes it. This isn't a bug. It's how these platforms work. Every deploy gets a fresh filesystem.
I've seen builders lose weeks of user data because they assumed "save to database" in their prompt meant an actual persistent database. It didn't. The AI used SQLite on the local filesystem, and the next deploy started from zero.
Migrations are the thing you'll wish you'd known about
Your database has a structure. Tables, columns, relationships. When you change that structure (adding a "phone number" field, renaming "name" to "first_name"), you need a migration script. It's a set of instructions that transforms the old structure into the new one without losing data.
AI can generate these from plain English now. But here's what it almost never generates: rollback scripts. The "down" migration. The instructions for undoing the change if something goes wrong. You won't think about rollbacks until you're staring at a broken production database at midnight. By then it's too late.
Backups are boring until they're everything
"The day you need a backup is not the day to think about backups."
Most managed database providers (Supabase, PlanetScale, Firebase) include automated backups. But "include" doesn't mean "enabled by default." Check. Right now. And then test restoring from one. A backup you've never tested restoring is a prayer, not a plan.
Dev/prod separation isn't optional
The Replit incident happened because the AI agent had direct access to production data. No staging environment. No separation. This is the single most common architectural mistake in vibe-coded apps.
You need two databases. One for development (where your AI can break things freely) and one for production (where real users live). They should have different credentials. Your AI tool should never touch the production one directly.
The Platform You're On Matters
Not all vibe coding tools handle data the same way. Here's what you're actually getting:
| Platform | Default Storage | Persistent? | Built-in Auth? |
|---|---|---|---|
| Lovable | Supabase (Postgres) | Yes | Yes |
| Bolt | Supabase (Postgres) | Yes | Yes |
| Replit | Built-in DB | Yes* | Partial |
| Cursor | None (you choose) | Depends | No |
| v0 | None (you choose) | Depends | No |
*Replit's storage is persistent, but without dev/prod separation, "persistent" can mean "persistently vulnerable to your AI agent."
One more thing the research turned up: an AI-built SaaS launched on Supabase with Row Level Security disabled. The team left it off "temporarily" during development. The anonymous API key, sitting right in the frontend code, gave anyone unprotected access to every query. 50,000 email addresses leaked. The startup shut down within two weeks.
Having a real database doesn't save you if the access controls are wrong.
Your Data Checklist
Before you ship (or right now, if you already have), answer these:
1. Where is my data actually stored?
Ask your AI tool to show you. Look for connection strings, database URLs, or references to localStorage/sessionStorage. If you can't find a database URL, your data probably isn't in a real database.
2. What happens when I redeploy?
Deploy your app. Check if the data is still there. If it's gone, you're using ephemeral storage. Fix this before you have real users.
3. Do I have separate dev and production databases?
If your AI tool is reading and writing to the same database your users are using, one bad prompt can wipe everything. Set up a second database for development.
4. Are backups enabled and tested?
Find your database provider's backup settings. Turn them on. Then actually restore one into a test environment to confirm it works.
5. If my database disappeared right now, what would I lose?
If the answer makes you uncomfortable, you don't have enough safeguards in place.
Data storage isn't glamorous. But every app that survives past "cool demo" needs to answer these questions. The vibe coding tools are getting better — Replit added safeguards after the Lemkin incident, and Supabase makes persistence pretty painless. But none of them will ask you these questions on their own.
That's on you.
Next in this series: how your app talks to the internet, and what happens when the API you depend on changes its rules.
Top comments (0)