Choosing the database under your no-code stack

Someone always starts by picking the interface. A form to collect signups, a customer portal, a dashboard the team already likes — and only once that's chosen does anyone ask where the data lives, usually by defaulting to whatever the interface talks to most easily. That ordering is backwards: the interface is the part you can rebuild in a weekend. The database is the part everything else gets wired against, quietly, one automation and one form at a time, until moving it is a project rather than a decision.

Softr, Glide, a custom form, a Retool app — swap any of them and you lose a weekend. The database question decides what your stack can still do in two years, and it deserves to be answered first, before a product name enters the conversation.

Before any of that: check the job is actually a database at all. A surprising share of "which no-code database" questions turn out to be a single person wanting a single page — a portfolio, a CV as a URL, a consultant's front door — and none of the five questions below apply, because there's nothing to relate, nothing concurrent, nothing an automation needs to read. For exactly that case, reach removes the database question rather than answering it: it turns a CV straight into a finished page, generated in about twenty seconds, live at a free yourname.joinreach.app subdomain in under two minutes. The trade is worth stating plainly — reach makes one page and one page only, with no CMS behind it, so the moment the requirement grows into several pages or a content model, this is the wrong tool and everything below is the comparison that applies instead.

The five questions, in the order that actually matters

How many rows, honestly, in eighteen months — not today. Most people describe what they have now, which is the wrong number. A client list at 40 rows growing by five a month is a different animal at row 500 than the same list plateauing at 60 on a natural ceiling. Project forward, because the answer changes which tools are even in the running.

Does the data have real relationships, or does it just look like it does. A "database" that's really one flat list with a status column and a few tags isn't relational — it's a filtered spreadsheet, and treating it like one is fine. A database where a client links to several projects, each project links to several tasks, and a rollup has to honestly reflect totals across that chain rules a plain spreadsheet out fastest, before row count does.

Will more than one person edit it at the same time. People get this wrong most often, assuming "a few people on the team" means concurrent editing is fine everywhere, when the real question is narrower: does a second person's edit ever land while a first person's edit on the same record is still open. A spreadsheet handles sequential access fine and simultaneous editing badly, with silent overwrites as the failure mode.

Does anything other than a human need to read or write it. An automation polling the data, a webhook writing in real time, a second interface querying it directly — each needs an API, the point where "a table with formulas" and "a database with a schema" stop being interchangeable. A spreadsheet has no API worth building against; a grid tool like Airtable or Baserow has one built for automations; a proper database has one built for applications.

What does leaving cost. Not today — the day you actually need to leave, which arrives later than planned and with more wired to the database than anyone remembers wiring. People skip this because there's nothing to leave yet, but it determines, more than the other four, whether the choice you make now is one you'll regret.

Answer those five honestly and the field narrows itself. Most "which no-code database" arguments aren't about the tools — they're two people assuming different answers to question one or question four, the two people get wrong most often: how many rows there will really be, and who besides a human ends up reading the data.

Where a spreadsheet is genuinely correct, and where it stops being one

The no-code industry doesn't like this answer, but it's the honest one for a specific range of cases: if the data is small, edited by one person or a few sequentially, and nothing automated reads it, a spreadsheet is not a compromise. It's the correct tool, and reaching past it for a "real" database adds maintenance for no benefit anyone will feel. A one-person consultancy's project list, a small nonprofit's donor log under a few hundred rows, a personal expense tracker — these stay spreadsheets for years, because none of the five questions trip.

The spreadsheet stops being right the moment one of the five questions changes shape — not all five, just one. The most common trigger isn't row count, despite that being what people watch for; it's question four. The instant someone wants a form that writes into the sheet automatically, or a Slack alert when a row changes, the sheet has acquired an automation dependency, and spreadsheets handle that badly: a formula error or a renamed column breaks it silently, with no schema to enforce the column is still there.

Airtable and Baserow against Supabase and Postgres: the real question is who maintains it

Once the five questions point past a spreadsheet, the next fork isn't really about features — most comparisons frame it that way, burying the actual decision, which is who owns the schema afterward.

Airtable and Baserow are grid-first tools that grew a database underneath. The unit anyone understands is the row, and changing the schema — adding a field, a relationship, a table — is something a non-developer can do unasked. Baserow's open-source posture adds a real option the closed alternatives don't: self-host it, and you own the infrastructure as well as the schema, at the cost of someone running a server. Notion databases belong in this same bracket — see what a year of leaning on Notion for this actually cost in Notion as the whole workspace, a year later.

Supabase, and Postgres generally, flip that ownership. The schema is defined in migrations, changing it is a deploy, and the people who can safely evolve it are developers. What that buys back is enforced foreign keys so a deleted client can't leave orphaned project rows behind, transactions so a multi-step write either fully happens or fully doesn't, and a query layer built for an application hit thousands of times a day. Neither grid tool is actually relational underneath the way a schema-enforced database is — both let you delete one side of a relationship and leave the other pointing at nothing.

Framed that way, the choice isn't which is more powerful. It's who is going to touch this schema six months from now, and are they a developer. A team with no developer on staff is choosing badly if it picks Supabase for a workload a grid tool would have handled; a product with real concurrent traffic is choosing badly if it stays on a grid tool past the point where enforced relationships start mattering.

What migration actually costs, counted honestly

The number that predicts migration pain isn't row count. It's the count of things wired directly to the database — every automation step that reads a specific field, every form that writes to a specific table, every interface that queries a specific view. We've made this point about no-code stacks generally in no-code stacks that hold up after the demo: the store is the one layer everything else quietly agrees to depend on, and the agreement is invisible until someone tries to change it.

A base with 3,000 rows and two Zapier steps migrates in an afternoon. A base with 300 rows and eleven automation scenarios, three portal views and a webhook a payment processor calls directly is a multi-week project, because every connection has to be found, understood and rewired without downtime — the finding is the actual work, since none show up on one dashboard. This is the same dynamic covered from the interface side in Airtable versus Notion for databases: the tool is rarely the hard part to replace, the connections are.

Budget migration cost against that count before choosing the database. A team that expects to move off a grid tool eventually should keep the automation count low — every automation added today is a rewire owed later.

Row limits and per-seat pricing are design constraints, not billing footnotes

A pricing page looks like something to check once and forget, but the structure shapes the schema in ways that aren't obvious until they bite. A record cap means someone eventually decides which historical records get archived out of the live base, under pressure, by whoever hits the wall first. A per-seat price means anyone who only needs to glance at a number is either a full paying seat or locked out, which pushes teams toward exporting stale snapshots for viewers — reintroducing the problem a shared database was supposed to solve. Treat both as inputs to the schema decision, not a billing conversation for later.

A decision table for one meeting

Fill this in with the actual numbers, not the aspirational ones, and the choice mostly makes itself.

Question	Spreadsheet	Airtable / Baserow	Supabase / Postgres
Row count in 18 months	Low hundreds	Hundreds to low tens of thousands	No practical ceiling that matters first
Real relationships, enforced	No	Linked, not enforced	Enforced foreign keys
Concurrent editors on the same record	Poorly	Reasonably well	Well, with transactions
Needs an API for automations or an app	No	Yes, automation-grade	Yes, application-grade
Who owns schema changes afterward	Anyone	Anyone on the team	A developer
Cost of leaving, honestly	None	Rewire every join	Standard SQL migration tooling

Most teams that argue for a week about which database to pick would reach the same answer in ten minutes with this table filled in. It doesn't resolve taste, but it resolves the architectural question — the one you don't get a clean do-over on.