Database software for small business: when a spreadsheet stops being enough

Database software for small business is usually considered too late, when a spreadsheet has quietly become the system of record for customers, inventory or projects — and started producing wrong answers. The move is not about row counts. It is about the moment the same fact starts living in more than one place.

Four signals say the spreadsheet has outgrown itself, and none of them is size.

The four signals

• Duplication. The same customer, product or project appears in two tabs, and updating one no longer updates the other. This is the signal that matters most, because from here the data quietly diverges.
• Concurrent editing. Two people open the file and one set of changes wins. Version conflicts in a shared sheet are a warning, not an inconvenience.
• History. You need to know what a value was last month and who changed it — and the spreadsheet cannot say.
• Relationships. You are copying a customer name onto every order row because there is no way to point at the customer instead.

The distinction in one sentence: a spreadsheet stores a grid of values, a database stores records with types and relationships. The moment you need one row to reference another — orders to customers, tasks to projects — you have left spreadsheet territory, whatever the file size.

What to look for

• Typed fields: text, number, date, select, checkbox, relation. Types are what stop "12/03" being a date in one row and text in another.
• Relations between tables, so a customer exists once and every order points at it.
• Views on the same data — grid for editing, kanban for status, gallery for anything visual — rather than duplicate sheets per view.
• Saved filters and sorts per view, so people stop re-filtering by hand every morning.
• Formulas and rollups across related rows, which is where most of the manual recalculation disappears.
• Revision history at cell level, and comments where the data lives rather than in a chat thread.
• Import from CSV and export to CSV or JSON. Your data should enter and leave in one step.

Migrating without breaking the week

1. Clean the spreadsheet first: one row per thing, one value per cell, no merged cells, no colour-as-meaning. Colour coding is data that no import will carry.
2. Split it into tables. Anything you find yourself repeating — customer names, product names, categories — is a separate table you should be pointing at.
3. Import one table, set the field types by hand, and check ten rows against the original before importing the rest.
4. Rebuild the views people actually use, and only those. A view nobody opens is maintenance with no payoff.
5. Run both for one cycle — a week, a month — and compare a few numbers before switching off the sheet.
6. Export on a schedule from day one. The measure of a good database tool is how easily the data leaves it.

Ettex Records is built for exactly this step: custom tables with typed fields and no code, relations between tables, grid, kanban and gallery views of the same data, saved views with per-view filters and ordering, formulas and rollups across related rows, revision history where every cell change is tracked and restorable, row comments, real-time collaboration, CSV import that turns a spreadsheet into a database in a minute, and export of any view as CSV or JSON. It is local-first, so the data sits on your device and syncs encrypted between them — you can browse and edit offline. Ready templates cover CRMs, trackers and catalogues.

What not to do

• Rebuilding the spreadsheet exactly, merged cells and all. If the structure is not changing, neither will the problems.
• Modelling every edge case up front. Add fields when a real record needs them.
• Choosing a tool whose export is a partial CSV. Data that cannot leave is data you no longer own.
• Giving everyone edit rights on the schema. Records edit freely; structure changes need one owner.
• Migrating history nobody reads. Archive the old sheet as-is and move only what is live.

Database software for small business earns its place the day one fact stops living in one place. Clean the sheet, split it into tables, keep the export path open — the rest is ordinary work.