Why Your AI-Built App Needs a Database (and Which to Use)

There's a moment almost everyone hits when building their first app with AI. You add a few items, it all looks great, you refresh the page, and everything is gone.

That's not a bug in the usual sense. It's your app telling you it needs a database. Here's what that means in plain language, how to tell when you need one, and which database I'd start with.

Where your data lives without a database

When an AI assistant builds a quick prototype, it usually keeps data in one of a few temporary places:

• In memory. The data exists only while the page is open. Refresh, and it's gone.
• In the browser's storage (often localStorage). It survives a refresh, but it lives only in that one browser on that one device. Open the app on your phone and it's empty. Clear your browsing data and it's gone.
• In a file in your project. This can work on your own computer, but most modern hosting, Vercel included, doesn't let a running app permanently save files. Your data won't stick around in production.

Those are fine for trying out an idea. They're not fine for an app anyone relies on, including you.

What a database actually does

A database is a place on a server that stores your app's data permanently and lets your app read and change it. If you've used a spreadsheet, you already understand the basic idea:

• A table is like one sheet, for example expenses.
• Each column is a kind of information: amount, category, date.
• Each row is one record: "$12.50, lunch, October 3".

Your app asks the database questions ("give me this user's expenses from this week") and sends it changes ("add this new expense"). Because the data lives on a server, not in your browser, it's there on every device and survives refreshes, crashes and new deployments.

Signs your app needs a database

If any of these are true, it's time:

• Data needs to still be there tomorrow
• You want to use the app on more than one device
• More than one person uses it, or people need to see each other's data
• People need to log in, so each person sees only their own data
• You want to search, sort or total your data in ways that get slow in a browser

That fourth point matters. Databases and logins (often called auth, short for authentication) usually go together. Once you know who someone is, the database can store their data and keep it separate from everyone else's.

Which database to start with

There are a lot of databases out there, and developers love arguing about them. For a first app built with AI, here's how I'd think about the main options:

• Postgres (via a hosted service like Supabase or Neon). Postgres is a popular, mature database that stores data in tables. It's a safe default for almost any app, and AI assistants know it extremely well.
• Firebase (Firestore). Google's option stores data as documents instead of tables. It's beginner-friendly, but its way of structuring data is different from the table-based databases most tutorials use.
• SQLite. A lightweight database stored in a single file. It's great for learning and local tools, but on serverless hosting you'd need a hosted version of it.

My pick for most people is Supabase. It gives you a Postgres database, user logins and file storage in one place, with a dashboard where you can see your tables like a spreadsheet. It also has a free tier to start on (check their pricing page for the current limits). It's what I use for this site and for LimitKeep.

The more important point: pick something popular and well documented, and don't overthink it. The best database for your first app is the one you can get working this week.

Let the AI help design it, but stay in the loop

Your AI assistant is good at designing database tables. Give it your project brief and try a prompt like:

Based on this brief, design the database tables I need. For each table,
list the columns, what each one stores, and how the tables connect.
Explain it in plain English before writing any SQL.

You'll get something like this for a simple expense tracker (Postgres syntax, as used by Supabase):

create table expenses (
  id bigint generated always as identity primary key,
  user_id uuid not null references auth.users (id),
  amount numeric(10, 2) not null,
  category text not null,
  spent_on date not null default current_date,
  created_at timestamptz not null default now()
);

Read it like a sentence: each expense has an ID, belongs to a user, has an amount with two decimal places, a category, and the date it was spent. If something's missing, like a note field you wanted, now is the cheapest time to add it.

One thing to insist on: security rules. When you connect a database to an app that runs in the browser, you need rules that stop people from reading each other's data. In Supabase, that's called Row Level Security, and you should turn it on for every table. The Supabase guide walks through setting up a table with those rules and email login in a Next.js app.

You don't need to be a database expert

You don't need to learn SQL before you start. You need to know that your data needs a permanent home, roughly what's in your tables and who's allowed to see what. The AI can handle the syntax. You handle the decisions.

— Spencer