“We need a database” is usually said by someone looking at a spreadsheet that has stopped behaving. It is a reasonable conclusion and often a premature one, because what most businesses actually need is a few of the things a database provides, not the database itself.
Knowing which of those things you are missing decides whether the answer is a better spreadsheet, a tool you already pay for, or something built.
What a database actually gives you
Strip away the technology and a database does five things a spreadsheet does not do by default.
- It refuses bad data. A date field only takes dates. A customer must exist before an order can point at them.
- It handles many people at once. Twenty people adding records at the same moment, without copies and without anyone overwriting anyone else.
- It keeps things that relate to each other properly linked. A customer with many orders, each with many items, stored once and connected, rather than retyped on every row.
- It answers questions quickly at any size. Ten thousand rows or ten million, the right query comes back fast.
- It sits behind other things. A website, an app, a report, an automation. The database holds the truth and everything else reads from it.
If none of those five describes your problem, you do not need a database. If one or two do, you probably need something in between.
The options, from smallest to largest
A spreadsheet with rules. Dropdowns, protected cells, validation, and the file kept somewhere shared with version history. Solves bad data and the copies problem for almost nothing. The cheap steps are set out here, and they fix more than people expect.
A list or table tool. A SharePoint list if you are on Microsoft 365, or a hosted table product such as Airtable if you are not. Typed columns, permissions, history, forms for entry, and a spreadsheet-like view people are comfortable with. For a business with a handful of staff and one process that outgrew a spreadsheet, this is frequently where it should end.
A real database behind a small application. PostgreSQL or similar, with a simple web interface built on top. No per-person fee, no ceiling worth worrying about, and it can serve customers as well as staff. It needs building and it needs looking after, which is the price of those advantages.
A platform database. Dataverse, in the Microsoft world. Relational depth and governance inside Microsoft 365, licensed per user. Strong for larger organisations already committed to that platform, and usually more than a small business needs to pay for.
How to tell which you need
Three questions do most of the work.
Who uses it? Staff only, and a handful of them, points toward a list. Customers, suppliers or the public points toward a small application, because those people should never need an account on your internal tools.
How do the records relate? One flat table of jobs is a list. Customers, sites, jobs, visits and parts, each linked to the others, is a database. Linked lists can stretch some way, and they stop stretching suddenly.
What has to read from it? If the answer is “people, on a screen”, a list or table tool is fine. If it is a website, a booking form, a nightly job and a monthly report, the data wants to live somewhere designed to be the single source for all of them.
Three situations, worked through
A cleaning company tracking forty contracts in a spreadsheet. Three office staff, one table, the occasional wrong entry. Add validation and move it somewhere shared. If it still hurts, a list or table tool. A database would be engineering for its own sake.
A training provider managing courses, dates, venues, trainers and bookings. Five kinds of thing, all linked, and customers booking from the website. This is a database problem. Holding it in linked spreadsheets is how double bookings happen. A small application with a proper database behind it is the honest answer, and it removes the per-seat cost a platform would add.
A property manager with tenancies, properties, maintenance jobs and contractors. Relational, but used only by four staff who already live in Microsoft 365. Linked SharePoint lists with a simple app on top may well hold it, and the licences are already paid for. Worth testing before building anything outside.
Five things worth doing
- List the kinds of thing you track: customers, jobs, items, visits. One or two suggests a list. Four or more that link together suggests a database.
- Note who enters and who reads, and whether any of them are outside the business.
- Fix the cheap problems first. Validation and a shared location remove most of the pain before any decision is needed.
- Write down what reads from the data, including reports and automations. That list often makes the decision on its own.
- Ask what it costs to run in three years, not just to build. Per-user licences and maintenance both compound.
Common misconceptions
- “A database is a big project.” The database itself is the easy part. The interface people use, and getting the existing data in cleanly, is where the time goes.
- “Spreadsheets cannot cope with large data.” Size is rarely the real problem. Many people editing at once, and records that relate to each other, are.
- “Moving to a database will tidy our data.” It will expose how untidy it is. Cleaning it is a job in its own right, and best done before the move.
- “Microsoft 365 means we must use Dataverse.” It is one option. A list may be enough, and a database outside Microsoft may be cheaper, depending on who needs access.
The honest summary
Most small businesses asking for a database need validation, a shared place to work, and somewhere to enter data without touching the structure. That is a better spreadsheet or a list, and it costs very little.
A real database earns its place when records genuinely relate to each other, when people outside the business need to reach the data, or when several things have to read from one source of truth. At that point it is worth doing properly, and it is usually cheaper than paying per person for a platform that does the same job.
If you are not sure which side of that line you are on, describe what you track and who touches it. That is usually enough to give a straight answer, including when the answer is that the spreadsheet is fine.
Common questions
When does a small business actually need a database?
When records relate to each other, such as customers, jobs and visits, when people outside the business need to reach the data, or when several systems need to read from one source. Before that point, a spreadsheet with rules or a list tool is usually enough.
Is a SharePoint list a database?
It behaves like a small one: typed columns, permissions and history. It handles a single table or a few linked tables well. It is not built for complex relationships, heavy concurrent use, or anything customer-facing.
What does a small database application cost to run?
The database itself costs very little on ordinary hosting. The real costs are building the interface, moving the existing data in, and keeping the whole thing maintained. There is usually no per-user fee, which is where it often comes out cheaper than a platform.
Can we start small and move to a database later?
Yes, and that is often the best route. Running a process in a list or a well-behaved spreadsheet for a while tells you exactly what a database would need to do, which makes the eventual build smaller and better.