I spent two hours debugging an empty production list. The data was in the test database the whole time.
If you're building with Lovable and Supabase, there's a gotcha that will bite you eventually — and when it does, you'll wonder why nobody warned you. Consider this your warning.
The setup nobody explains
When you spin up a Supabase project through Lovable, you get two database environments: test and live. This makes sense in theory — you don't want your AI-assisted edits touching production data while you're experimenting.
The problem? The boundary between these two is almost invisible.
When you use the AI chat in Lovable to insert data — say, seed some blog posts, add sample users, or populate a lookup table — that data goes into the test database. Your production app, the one your users actually visit, reads from the live database.
You insert ten records. You check the app. Zero records. You start debugging.
Where the confusion hits
Here's the typical debugging spiral:
- You ask the AI to insert data. It confirms success.
- You open your app. The list is empty.
- You check your query. It looks correct.
- You add console logs. The query runs fine, returns nothing.
- You start questioning your RLS policies, your auth setup, your entire understanding of PostgreSQL.
The data is there. It's just in the wrong database.
The fix is one toggle
In Lovable's Supabase integration, there's a SQL Editor with a toggle to switch between test and live environments. When you need data in production, you switch to Live and run your inserts there.
Simple — once you know about it. Brutal when you don't.
My pre-deploy checklist
After getting burned on this across multiple projects at Inithouse (we run about a dozen MVPs built on Lovable + Supabase), I started using a quick checklist before every deploy:
1. Check which database you're targeting. Before any insert, look at the SQL Editor toggle. If it says "test" and you need production data, switch it.
2. Don't trust AI chat inserts for production. The AI chat is great for prototyping, but treat its database writes as test-only by default. For production data, use the SQL Editor switched to Live.
3. Verify after insert. After running your production inserts, open your deployed app and confirm the data shows up. Don't assume — check.
4. Document your seed data. Keep your production seed SQL in a file. When you inevitably need to re-run it (new environment, data reset, migration), you want it ready.
Why this matters for real products
This isn't just a development inconvenience. I've shipped Živá Fotka and HereWeAsk on the Lovable + Supabase stack. Both had moments where content was "missing" in production because someone inserted it through the AI chat.
For an MVP you're validating with real users, showing an empty page when there should be content is a conversion killer. Users don't debug — they leave.
The broader lesson
AI-assisted builders are incredible for speed. But they abstract away infrastructure in ways that create new categories of bugs. The test-vs-live database split is Supabase doing the right thing by protecting your production data. The gap is in making that split visible enough.
If you're building on Lovable + Supabase, bookmark this. You'll need it at 11 PM on a Sunday when your production page is empty and you can't figure out why.
I'm Jakub, building a portfolio of micro-products at Inithouse. Follow along for more war stories from the AI-assisted building trenches.