Somewhere in the first few weeks of a new business application, a line appears in the proposal saying it will be built on a particular database. It reads like a technical detail and gets approved the way you’d approve the type of cabling in a new office. Three years later you’re asking who patches it, why the licence arrangement is what it is, and how hard it would be to move to something else.
The database is the part of an application that holds your records: customers, orders, jobs, invoices, whatever the system exists to manage. The application is the layer people see and use, but it’s usually written to work with one specific database product, and that is often what makes the choice sticky. You’re not picking a component you can swap in an afternoon. You’re picking something the application, the people who maintain it and your data will all grow around. So we’d rather you came away from this with questions than with a vendor name.
Why it’s expensive to change your mind
Once an application has been running for a year or two, the database holds your history, the application’s code leans on that product’s particular features, and the people who look after it have learned its habits. Moving means copying the data across, rewriting whatever relied on the old product and testing it all again, and that’s a project in its own right, not a tidy-up.
Who will look after it, and do they know it
Skills tend to decide more than features do. Any of the mainstream database products can run a typical business application well, so the practical question is whether the person who’ll patch it, tune it and restore it at a bad moment knows that product. A platform your developer loves and your IT support has never touched leaves you dependent on one supplier for everything. It cuts both ways, too: a well-known product with plenty of people able to support it gives you somewhere to turn if the original supplier moves on.
Find out who will be responsible after go-live and whether they’re comfortable with the proposed platform. If the answer is “the developer”, it’s worth knowing what happens if that stops being true. For a small organisation we’d want a named person responsible, plus a written note of where the data lives and how to restore it, so that it doesn’t all sit in one head. If you’d want someone to keep an eye on it after launch, our continuing support page describes how that kind of arrangement is agreed individually.
Licensing is a promise about the next five years
Open-source and commercial databases ask different things of you. PostgreSQL, for example, is released under a licence the project describes as liberal and similar to the BSD or MIT licences, with permission to use, copy, modify and distribute it for any purpose without fee. That removes the licence fee, but not the cost of running it, which is the people, hosting and time.
Commercial products come with licence terms that depend on the edition you choose and where it runs, so ask for them in writing: what you’ll be licensed for, who holds the licence (you or them) and what happens to it if the contract ends.
Lifecycle: every version has an end date
Every database version stops receiving fixes eventually, and the platform you choose decides how that shows up. Here’s where the vendors’ own pages put things as at May 2026:
| Platform | What the vendor says | What it means for you |
|---|---|---|
| PostgreSQL | A major version is supported for 5 years after its first release, with fixes in minor releases at least every three months | Plan an upgrade roughly every few years; major upgrades need a dump and reload of the data or the pg_upgrade tool |
| SQL Server 2022 | Microsoft’s Fixed Lifecycle Policy; mainstream support to January 2028, extended support to January 2033 | After mainstream support ends, extended support brings security updates but no design changes or new features |
| Azure SQL Database | Always runs on the most recent stable version of the engine, and Microsoft handles most patching | Most of the version question becomes the provider’s problem |
Whichever route you take, someone has to budget the time to move to a supported version and test the application against it, and that work rarely appears in the original quote.
Hosting moves the work, not the responsibility
You can run a database on a server in your own premises, on a virtual machine you rent, or as a managed service where the provider looks after the underlying machinery. With Azure SQL Database, for example, Microsoft says it handles most database management functions and takes automatic backups, with recovery to any point in time within the retention period. That takes real work off your plate.
It doesn’t remove the questions, though. Someone still has to decide how long backups are kept, check that a restore works and decide where the data is allowed to live. A backup nobody has ever restored is an assumption. Self-hosting gives you more control and more to look after, while a managed service takes more of it away and gives you less say over timing and settings. Neither is wrong, but you should know which of the two you’ve bought. Our backup strategy guide covers the wider picture beyond the database.
Settle the exit before you start
Leaving isn’t a comfortable topic at the start of a project, which is exactly why it’s worth raising. Check in what format you could get all your data out, who owns the structure of the database as well as the contents, and whether that structure is documented. Better still, have the supplier show you an export restored somewhere else before you go live.
What good enough looks like
For most small and medium-sized organisations it’s fairly modest. You want a mainstream, widely supported product on a version that’s well inside its support period, a named person or supplier responsible for patching and restores, backups kept somewhere other than the database server, and a restore you’ve watched working before go-live. If there’s no IT person in-house, a managed service such as Azure SQL Database takes much of the patching and backup work off your hands, which is worth weighing against the time self-hosting would cost you. Self-hosting makes sense when you already have the skills, or a good reason to control the machine.
If your organisation has its own IT department, or the application is one the business can’t run without, you’ll want more: recovery that’s been tested against how long you can afford to be without it, and an upgrade plan agreed up front. That’s the point where it’s worth bringing in a specialist to check the plan.
Questions to put to whoever’s proposing it
Rather than judging the product yourself, put these to the supplier. How readily they answer tells you almost as much as the answers do.
- Why this platform for this application, and what else did you consider?
- Who will patch, monitor and restore it after go-live, and how do we know that has happened?
- What licence terms apply, in whose name, and what happens to them if we part company?
- Which version are we starting on, when does its support end and who plans the upgrade?
- Where will it be hosted, and where do the backups go and how long are they kept?
- When did anyone last restore a backup of a system like this, and can we see that done?
- How would we get our data out, in what format and at what effort?
If a proposal has already named its platform and you’re not sure what to ask before you sign, send us a message and we’ll happily help you frame the questions, or look over the supplier’s answers with you.
