Database Problems in AI-Built Apps: What Goes Wrong and How to Fix It

The database is the foundation of your app. Every user account, every transaction, every piece of content lives there. When the database structure is wrong, everything built on top of it is fragile. And AI tools get database design wrong in predictable, fixable ways.

1. No indexes on columns you query frequently

Your app has 50 users and everything feels fine. It grows to 500 and pages start loading slowly. At 5,000 users, the app becomes unusable during peak hours. The problem is almost always missing indexes.

AI tools create tables and write queries but almost never add indexes. Every time your app filters, sorts, or joins on a column that is not indexed, the database scans every row in the table. That is fine for 50 rows. It is a disaster for 50,000.

The fix: Look at your most common queries. Any column used in a WHERE clause, ORDER BY, or JOIN should have an index. For Supabase/PostgreSQL, you can check which queries are slow using the pg_stat_statements extension. Add indexes to the columns that show up most often.

2. Data leaking between users

This is the scariest one. User A can see user B's data. It happens because there are no row-level security policies, no user_id filtering on queries, or the API returns all records regardless of who is asking.

In Supabase apps built with Lovable, this is extremely common. The tables are created without RLS enabled. The frontend queries directly from the client, and since there are no policies, every authenticated user can read every row in every table.

The fix: For Supabase, enable RLS on every table that contains user data. Write policies that restrict SELECT, INSERT, UPDATE, and DELETE to rows where the user_id matches the authenticated user. Test by logging in as two different users and verifying that each can only see their own data.

3. No foreign key relationships

AI tools often create flat tables that repeat data instead of using relationships. You might have a "projects" table with a user_name column instead of a user_id that references the users table. Or an "orders" table with the product name and price copied in instead of referencing the products table.

This leads to data inconsistency. A user changes their name and it updates in one table but not the others. A product price changes but old orders still show the new price.

The fix: Identify repeated data across tables. Replace it with foreign key references. Use IDs to link tables instead of copying values. This is a schema migration that can be done without losing data.

4. No migration tracking

You made changes to your database schema directly in the Supabase dashboard. Your production database has one structure. Your development database has a different one. There is no record of what changed, when, or why. Deploying to a new environment means manually recreating the schema from memory.

The fix: Start using database migrations. Supabase has built-in migration support with the Supabase CLI. Prisma has migration files. Even a simple folder of numbered SQL files is better than nothing. The goal is that any developer can spin up an identical database from scratch by running the migration files in order.

5. N+1 queries killing performance

Your page loads a list of 20 projects. For each project, it makes a separate query to get the owner's name. And another query to get the comment count. That is 41 database queries for a single page load. This pattern is called N+1, and it is one of the most common performance killers in AI-generated code.

The fix: Use joins or batch queries instead of loops. Instead of querying each project's owner separately, join the projects and users tables in a single query. For Supabase, use the select syntax with embedded relations: supabase.from("projects").select("*, users(name)").

6. Storing data in the wrong format

Dates stored as strings. Prices stored as floating point numbers (which causes rounding errors with currency). Boolean values stored as "yes" and "no" strings. Email addresses with no uniqueness constraint. Phone numbers in inconsistent formats.

These seem minor until they cause bugs. A date comparison fails because "04/15/2026" does not sort correctly as a string. A price calculation is off by a penny because floating point math is inherently imprecise. Duplicate accounts are created because two rows have the same email.

The fix: Use the right data types. Dates should be timestamp or timestamptz columns. Prices should use integer cents (store 2999 for $29.99) or the decimal type. Booleans should be boolean columns. Add unique constraints on email addresses and any other column that should not have duplicates.

7. No backups configured

Your app is live. Users are creating data. And there is no backup. If the database gets corrupted, if you run a bad migration, if someone accidentally deletes a table, all of that data is gone permanently.

The fix: Most managed database providers (Supabase, PlanetScale, Neon) have automatic backups on paid plans. Verify that yours is enabled. For critical data, set up a daily export to cloud storage as an additional safety net. Test your restore process at least once. A backup you have never tested is not a backup.

Database health checklist

• RLS is enabled on every table with user data
• Indexes exist on frequently queried columns
• Foreign keys link related tables instead of duplicating data
• Migrations are tracked in version control
• No N+1 queries on list pages
• Data types match what they store (dates, currency, booleans)
• Unique constraints prevent duplicate records where needed
• Backups are enabled and tested

Your database is fixable

Database issues feel intimidating because the data is already there and you are afraid of breaking it. But schema changes, index additions, and RLS policies can all be applied to existing databases without losing data. These are migrations, not rewrites.

If your app is slow, your data structure does not make sense, or you are worried about user data leaking between accounts, we can review your database and give you a specific plan to fix it.