The database talk your builders actually need.
Three questions come up in every AI-builder community: "when should I use Supabase?", "why can't Claude Code just make structured data for me?", and "Postgres vs NoSQL, and why should I care?" This page answers all three in plain language, and each answer runs live so a non-technical founder can see the reasoning, not just take my word for it.
Every explanation here is framed around how AI changes the workflow, because that is how people actually build now.
"When should I use Supabase?"
The honest first move is not to answer. It is to ask four questions, because "Supabase" is rarely the real question. The real question is "what kind of database do I even need?" Answer below and the engine recommends one, tells you why in plain words, and hands you the exact thing to tell your AI assistant.
"Why can't Claude Code just make structured data for me?"
Because "structured" is a decision, not a default. Below is one messy spreadsheet of orders. Watch it get normalized step by step, recomputed in your browser from that same data. The point a founder feels at the end: the shape is what stops your app from telling two different truths about the same customer.
Summary tables: the difference between "instant" and "timed out"
Same question, two ways to answer it: "total revenue per product." One scans every raw sale. The other reads a small pre-aggregated table. The rows-scanned number is exact and computed below; the timing is measured in your browser right now. This is the optimization AI will not add unless you know to ask for it.
SELECT product, SUM(amount) FROM sales GROUP BY product; // reads all rows, every time
SELECT product, SUM(total) FROM product_daily_totals GROUP BY product; // reads the small rollup
The three questions, answered like a person
The short versions, in the plain language I would use on a call. Each ends with the one sentence to hand your AI assistant, because framing the ask correctly is half of getting good structured output.
When you need a real relational database with an easy on-ramp: rows and columns, relationships between things, and you would rather not run servers. Supabase is Postgres with the annoying parts handled. Reach for it when a spreadsheet has started to hurt and you have real users. Do not reach for it to store a to-do list you could keep in a Google Sheet.
It can, once you have decided the shape. From a vague prompt it has to guess whether a customer is one thing or five, and guesses drift row to row. Give it the tables and the keys and it becomes very good at filling them. Structure is a decision you make; the AI is the fast hands, not the architect.
Postgres wants a shape up front and rewards you with joins, consistency, and one source of truth. NoSQL (Mongo, DynamoDB) lets you throw in flexible documents and scales writes hard, but you carry the consistency yourself. Most founders building a normal app want Postgres. You care because switching later is a rebuild, not a setting.
Often, no. If it is a list you read a few times a day, a spreadsheet or Airtable is the right database, and outgrowing it is a good problem you will feel clearly. The skill I teach is not "always use Postgres." It is knowing which tier of tool matches the job, and when the pain tells you to move up.
Do not take the page's word for it
Every headline number on this page comes from a computation, not from copy I typed. This button re-runs those computations from the raw data embedded in the page and checks each claim. It can fail, and it says exactly what it checked.