Every database vendor has a list of reasons they are the best. Most sound the same. The job of the project lead is not to pick the best database. It is to pick the one that fits the job.
The reference piece runs through ten databases — Oracle, MySQL, SQLite, MariaDB and others — and lists their strengths. It is a useful starting map, not a destination. The interesting work is matching the database to the workload, the team and the regulatory environment.
At a glance
| Database | Popularity Score (2022) | Best For |
|---|---|---|
| Oracle | 1260 | Large enterprises, high-availability systems |
| MySQL | 1202 | Transactional web workloads, open-source teams |
| Microsoft SQL | 944 | Windows/Linux environments, structured data |
| PostgreSQL | 618 | Object-relational needs, complex data operations |
| MariaDB | 113.89 | Open-source fork of MySQL, active cloud development |
| SQLite | 138.87 | Embedded and mobile workloads, zero-configuration needs |
Why database choice is rarely a popularity contest
The reference surfaces two data points that get quoted a lot: Oracle's popularity score of 1260, MySQL's at 1202. The problem with chasing those numbers is that they measure familiarity, not fit. A team that already knows MySQL will ship faster with MySQL, even if another team has moved on to something newer.
Three filters cut through the noise faster than any benchmark:
- Workload shape.** Are you optimising for transactional integrity, analytical queries, embedded use, or a mix? Each workload has a natural default.
- Team skill set.** A database your team can operate is worth more than one with a better benchmark. Operational debt compounds faster than feature debt.
- Regulatory environment.** Some databases have stronger tooling for encryption, access management and audit logging. If you are in a regulated industry, that is the first filter.
Run those three filters before reading another vendor benchmark. They cut the list of viable options by half before any comparison starts.
A quick map of the four that usually make the shortlist
Most teams end up choosing from a familiar set:
- Oracle:** High availability, mature tooling, strong enterprise support. Comes with cost and operational overhead. Best when your scale matches Oracle, or the support contract matters more than the licence.
- MySQL:** Open-source, widely understood, easy to hire for. Best for transactional web workloads where team expertise is non-negotiable.
- SQLite:** Zero-setup, embedded, single-file. Best for mobile apps, small tools and any use case where running a server is overkill.
- MariaDB:** Open-source fork of MySQL with stronger cloud offerings and active development. Best when you want MySQL compatibility plus an active community that is not controlled by a single vendor.
The right choice depends on the team, the workload and the regulatory environment — not on the popularity score.
What it means for you
If you lead a project that will live with a database choice for more than a year, treat the decision as a delivery decision, not a procurement decision. The wrong choice will slow every sprint that touches it. The right choice will be invisible.
A working session with your engineering leads can answer four questions in an hour:
- What is the dominant workload? Transactional, analytical, embedded, mixed?
- What is the team's existing depth? Who can run it at 3 a.m. When it breaks?
- What regulatory constraints apply? Encryption at rest, audit logging, data residency?
- What is the migration cost if the choice is wrong? Some databases are cheap to swap out. Most are not.
Get those answers in writing before the architecture review, and the rest of the project runs faster.
What to watch next
Watch whether the team can run the chosen database themselves, or whether they need a vendor to hold their hand. The teams that ship fast are the ones that own the operational depth, not the ones that outsource it to a managed service they cannot debug.
Bottom line
The best database is the one your team can run, that fits your workload, and that survives your regulatory filter. Pick that one. Ignore the popularity score.
Key takeaways
- The right database fits the workload, team and regulatory environment — not the one with the highest popularity score.
- Filter choices through workload shape, team skill set and regulatory environment before reading any vendor benchmark.
- Treat the database decision as a delivery decision; get four answers in writing before the architecture review.
- Document the choice and migration cost in an architecture decision record so the project can move on.
Frequently asked questions
Why do project leads rarely pick a database by popularity score?
Popularity scores measure familiarity, not fit. A database your team can operate is worth more than one with a better benchmark.
What are the three filters that cut a database shortlist down fastest?
Workload shape, team skill set and regulatory environment. Apply them before any vendor benchmark.
Which four databases usually make the shortlist for project leads?
Oracle, MySQL, SQLite and MariaDB. Each fits a different workload and operational profile.
How should a team validate a database choice before committing?
Run a spike on the next-best alternative with a real workload, compared on developer experience, operational cost and regulatory fit.