The no-code database: a plain guide

"No-code database" is a marketing term wrapped around a genuinely useful category. This guide explains what is actually underneath it, and how to judge one.

What it means

A no-code database gives you the things a database provides — structure, relationships, queries, permissions — through an interface rather than through SQL and a codebase.

Concretely, you get:

• Tables you create by clicking, with typed fields (text, number, date, select, attachment, and so on).
• Relations between tables, so records genuinely reference each other.
• Views — grid, calendar, board, timeline, map — as configuration, not as an application you build.
• Permissions by person, role, row and often field.
• Automations — when this changes, do that.
• An API, so it can be part of a larger system.

What you do not get: schema migrations, ORMs, a deployment pipeline, or a front end to build. The interface is provided.

What "no-code" does not mean

Two honest caveats, because the marketing tends to skip them.

It does not mean no thinking. You still have to decide what your tables are, how they relate, and what each field means. That is modelling, and it is most of the intellectual work of building a database. No-code removes the typing, not the thinking. A badly modelled no-code database is just as painful as a badly modelled SQL one — it is only cheaper to fix.

It does not mean no limits. These tools sit between spreadsheets and real databases, and they inherit constraints from that position: row ceilings, rate limits on APIs, formula languages less expressive than SQL, and query patterns that can get slow at the top of the range.

If you are building a consumer product with a million users, this is not the category. If you are running operations for a team of five to five hundred, it very often is.

Who it is genuinely for

The category exists because of a specific gap.

Plenty of teams have data that is genuinely relational — orders and line items, candidates and applications, assets and maintenance — but cannot justify an engineering project to model it. A spreadsheet cannot express the relationships; a SQL database needs a developer plus a user interface.

So the fit is:

• Operations teams running processes that span several entities.
• Small companies with no in-house engineers.
• Departments inside larger companies whose needs are too specific for the corporate system and too important for a sheet.
• Teams prototyping something that may become a real application later.

The fit is poor for consumer-scale applications, heavy analytical workloads over tens of millions of rows, and anything with hard sub-millisecond latency requirements.

How to evaluate one

Vendors compete on feature lists. Feature lists are a poor way to choose. These are the things that actually determine whether you will still be happy in a year.

1. How deep do relationships go?

The single most important question, and the one demos gloss over.

Every tool in this category links two tables. The real question is what happens on the second and third hop. Can a line item show its order's client's account manager? Can you roll a value up through two levels?

Many tools stop at one hop, which forces you to duplicate fields to bridge the gap — reintroducing exactly the drift you left spreadsheets to escape. Test this with your actual data shape before committing.

2. Are views genuinely separate from data?

You want many views over one set of records. Check that a filter someone applies does not change what a colleague sees, and that a saved view persists per person.

If you find yourself duplicating tables to give two teams different views, the separation is not real.

3. How granular are permissions?

"Can open the base" is not permissions. Ask:

• Can someone see only their rows?
• Can a field be hidden from a role while remaining usable in calculations?
• Can you give someone read-only access without them being able to export everything?

Field-level control is the line between "we can give the contractor access" and "we cannot".

4. Is there a real audit trail?

When a number is wrong, you need to know who changed what, when, and what it was before. Ask whether history is per-field, how far back it goes, and whether it survives a deletion.

Related: is deletion recoverable? Soft delete with a recycle bin is the difference between an incident and a catastrophe.

5. Can you get your data out?

Test the export before you commit, not after. Specifically: does the export preserve relationships, or does it flatten to CSVs where links become names again?

An API with reasonable rate limits is the strongest form of this. Data you cannot extract with its structure intact is data you do not really own.

6. What happens at your realistic ceiling?

Ask for the row limit per table, not per account, and the rate limit on the API. Then be honest about your five-year volume, not your current one.

7. What does it cost as you grow?

Most pricing is per user per month, often with the features you need on a higher tier. Model the cost at three times your current team size and check which features sit behind which tier. The common unpleasant surprise is that permissions — the thing that made it viable — is enterprise-only.

The questions to ask on a trial

Not "does it have automations?" but:

• Build your actual messiest table. Does the field set survive?
• Model your hardest relationship — the many-to-many one. How many clicks?
• Give a colleague restricted access. Can they see something they should not?
• Change a value and find it in the audit log.
• Export everything, and check whether the relationships survived.
• Ask a question you currently need a day to answer. How long does it take?

An afternoon spent this way tells you more than a month of feature comparison.

Where it fits alongside what you have

Most teams end up with a division of labour rather than a replacement:

• Spreadsheets keep modelling, forecasting and ad-hoc analysis. They are better at it.
• The no-code database becomes the operational source of truth — the records everything else reads from.
• Business intelligence tools, if you have them, read from the database's API rather than from a file someone exports on Fridays.

The failure mode is not picking the wrong tool. It is asking one tool to do all three jobs.

Where to go next

• What is a relational workspace — the concepts underneath.
• The best no-code database tools — how the main options differ.
• Spreadsheet vs database — the trade-offs, honestly.