Databases are the longest-lived decision in any system: frameworks come and go, but the data stays. We run all of these in production for clients, and the right answer is often "two of them, for different jobs". Here is how we think about it.
Relational first
If your data has relationships and your business has rules — bookings, orders, invoices, patients — start relational. Constraints, transactions and joins are not legacy features; they are the cheapest correctness you will ever buy.
MySQL / MariaDB
Fast, ubiquitous, inexpensive to host, excellent on Azure Database for MySQL and Amazon RDS. Our choice for web platforms and SaaS products where licensing cost matters and the workload is read-heavy.
Microsoft SQL Server
The natural partner of .NET. Superb tooling, spatial types (we use them for driver matching), columnstore indexes for reporting, always-encrypted columns for medical data, and Azure SQL for managed hosting. Our default for enterprise and healthcare systems.
Oracle Database
Still the backbone of banks, telecoms and government. We work with Oracle where it already exists — PL/SQL integration, RAC environments, migrations to Oracle Cloud or to PostgreSQL where the licence no longer pays for itself.
PostgreSQL
Not in your original list, but worth knowing: an open-source engine with Oracle-grade features, JSONB and PostGIS. Frequently our recommendation when a client wants relational power without licence fees.
Document databases: MongoDB
When each record is naturally a self-contained document with a flexible shape — a product catalog, an order with embedded items, an event log — MongoDB shines. Horizontal scaling and geospatial queries are built in.
// MongoDB — an order document with embedded items
{
"_id": "ord_8f3c",
"customerId": "cus_120",
"status": "PickedUp",
"items": [ { "sku": "KEB-01", "qty": 2, "price": 7.5 } ],
"courier": { "id": "drv_44", "location": { "type": "Point", "coordinates": [24.94, 60.17] } },
"updatedAt": ISODate("2026-06-02T10:14:00Z")
}The trade-off is that cross-document consistency is your responsibility. We keep money and identity in SQL and put catalogs, logs and analytics in MongoDB.
Real-time: Firebase
Firebase Realtime Database and Cloud Firestore are not general-purpose databases — they are synchronisation services with a database attached. For live driver locations, chat, presence and collaborative screens they are unbeatable: the mobile SDK handles offline caching, reconnection and fan-out to thousands of clients with no server code.
A quick decision table
| Workload | Our usual choice |
|---|---|
| Bookings, orders, payments, patient records | SQL Server / MySQL / PostgreSQL |
| Catalogs, content, event streams | MongoDB |
| Live tracking, chat, presence | Firebase Realtime DB / Firestore |
| Caching, rate limiting, geospatial sets | Redis |
| Existing enterprise estates | Oracle (integrate, then modernise) |
Whatever you choose
- Use migrations (EF Core, Flyway, Liquibase) — never hand-edit production schemas.
- Automate backups and test the restore quarterly.
- Encrypt personal data at rest and design deletion from the start.
- Measure with real query plans before adding indexes or caches.
Need help choosing or migrating? Our consultants have moved systems between all of the above — get in touch.