Database Tools for People Who Do Not Write SQL

A spreadsheet is the most successful database in the world. It is also the tool people keep using about two years past the point where it stops being appropriate, because the alternatives look like a bigger change than they are.

This is about the moment to move, and what to move to.

The four signals you have outgrown a spreadsheet

Not "you have a lot of rows." Row count is the wrong metric — a hundred thousand rows of one table is fine in a spreadsheet if nobody edits it concurrently.

The real signals are these:

Two or more people edit at once. Shared spreadsheets lose writes. Two people typing in the same file at the same time produce a conflict that resolves silently and incorrectly. This is the strongest signal and the one people ignore longest.

The same fact lives in three places. A client name appears in the invoices sheet, the projects sheet, and the contacts sheet. Someone changes it in one of them. Now you have three versions of the truth and no way to know which is right.

You need a different view of the same data. Everyone wants the full table; the accountant wants only unpaid invoices; the operations person wants only active projects. In a spreadsheet that becomes three copies. In a database it becomes three views of one table.

You need to give someone limited access. A spreadsheet is all-or-nothing. You cannot let a contractor see the project rows without also letting them see payroll.

If none of those apply, keep the spreadsheet. It is faster, everyone knows it, and the migration is not free.

The options, ranked by how much you have to learn

A relational database with a spreadsheet interface

This is the natural next step and the one most teams should take. It looks like a spreadsheet, behaves like a database: typed columns, linked records between tables, filtered views, and per-user permissions.

What you gain immediately: two people can edit at once, a client record exists once and is referenced everywhere, and a "view" is a saved filter rather than a copy.

What you gain later, and this is the part people underestimate: an API. Every serious option in this category exposes your data over HTTP, which means the moment you need a small script, a form, or a website to read it, the data is already reachable.

The costs: the free tiers cap records (often a thousand or so per base, which arrives faster than you expect), and the formula language is usually a subset of what a spreadsheet offers. Complex calculations often need to move into a script or a report rather than a cell.

A self-hosted equivalent

Same idea, running on your own server. Worth it when the data cannot leave the building, or when the record caps are the binding constraint.

The trade-off is honest: you take on upgrades, backups, and uptime. If nobody in the organisation enjoys that, the subscription is cheaper than the maintenance.

A real database with a query layer

Postgres plus something that lets a non-developer query it. This is the right answer for data that needs to be joined across many tables and reported on regularly.

It is also the option most likely to be abandoned halfway, because the moment something breaks, the person who set it up is the only one who can fix it. Only choose this if that person exists and is staying.

A local analytical engine for one-off questions

For "what is the total across these twelve CSV files," you do not need a database at all. A local analytical tool can query files directly with SQL and no server, and the answer comes back in seconds.

This is a genuinely underused option: most one-off reporting questions do not need infrastructure, they need a query engine and thirty seconds.

Designing the tables, without the jargon

The single most useful skill here is normalisation, which sounds intimidating and is actually one idea: store each fact once.

A workable three-table structure covers most small businesses:

The link is the whole point. The invoice does not repeat the client name; it points at the client row. Change the name once and every invoice follows.

Two rules that prevent most of the pain:

1. Never put two facts in one column. "12 Main St, Leeds" is three fields pretending to be one, and you will want to filter by city within a month.
2. Give every row a stable ID and never reuse it. Human-readable IDs get edited. A meaningless unique ID does not.

Migrating without losing a weekend

The migration is usually less work than feared, if you do it in this order:

1. Export to CSV, one sheet at a time. Do not try to import the workbook as a whole.
2. Import the parent table first — clients before projects, projects before invoices. Links need something to point at.
3. Deduplicate before importing, not after. A database will happily accept the same client five times with slightly different spellings, and unpicking that later is miserable.
4. Run both systems in parallel for two weeks. Compare totals at the end of each week. If they match, switch. If they do not, you have found a data problem while you still have the old system.
5. Freeze the spreadsheet read-only, do not delete it. You will want it in three months for something.

Step four is the one that gets skipped, and it is the one that catches the errors.

The permission question, which is the real upgrade

Most people migrate for the interface and stay for the permissions.

In a spreadsheet, access is file-level. In a database with a spreadsheet interface, you can typically say: this person sees only rows where the client is theirs; this person can edit projects but not invoices; this person can read everything and write nothing.

For a business with a contractor, an accountant, and a founder, that single capability is worth the migration on its own. It is also the reason to check permission granularity before you pick a tool — some products in this category treat permissions as a paid feature, and the free tier is still effectively all-or-nothing.

The honest recommendation

• One person, under a few thousand rows, no sharing: stay in the spreadsheet. Use a database only when a question needs a query.
• Two or more editors, or facts repeated across sheets: move to a database with a spreadsheet interface. This is the majority case.
• Data that cannot leave your infrastructure: the self-hosted version of the same thing.
• Regular multi-table reporting: a real database, but only if someone owns it.

The migration is a day of work and an afternoon of cleanup. The thing that makes it feel expensive is not the tool — it is that most teams do it six months after the second person started editing, by which point there are three conflicting versions of everything to reconcile first.