Relational Databases

The engine matters less than how well it matches your stack, licensing budget and team. SQL Server fits naturally with .NET applications and the Microsoft ecosystem, PostgreSQL is a strong open-source default with rich data types and extensions, MySQL and MariaDB remain a lightweight, widely hosted choice for PHP and web workloads, and Oracle Database suits organisations that already run Oracle applications or need its enterprise features. Every major cloud offers managed versions of these engines, which removes much of the patching and backup work.

Most performance problems we are asked to fix come from the data model and queries rather than the hardware. We start with a review of the schema, indexes and execution plans for the slowest and most frequent queries, then address normalisation issues, missing or redundant indexes, locking and connection pooling. For production systems we also set up automated backups with tested restores, replication or high-availability failover, and monitoring, so problems are caught before your users notice them.

A normalised schema stores each fact once, so a customer's address lives in one row and an update cannot leave two versions disagreeing. That is the right default for transactional systems. Denormalisation - copying a value into another table, keeping a running total, or building a reporting table - trades that safety for read speed, so we add it only where measured query load justifies it, and keep the copy in sync with a trigger, a scheduled job or a materialised view rather than application code that someone will forget.

Indexing follows the same rule of evidence. We index foreign keys and the columns your most frequent queries filter, join and sort on, use composite indexes in the order queries actually use them, and add covering or filtered indexes for hot paths. Every index also slows writes and takes space, so unused and duplicate indexes are found from the engine's usage statistics and removed.

We compare engines against the same questions every time. What does licensing cost at your size, and which features are limited to paid or enterprise editions? Which managed service is available on the cloud you already use? Do you need specific features such as table partitioning, spatial data, full-text search, JSON indexing or PL/SQL compatibility? How will high availability and disaster recovery work, and who on your team will run it? The engine that answers these best for your situation is the right one, even if it is not the newest.

Schema changes belong in version control next to the application code, as numbered migration scripts managed by a tool such as Flyway, Liquibase, EF Core migrations or the framework's own migrator. The pipeline applies them to a fresh database on every build, then to staging, and only then to production. Risky changes use the expand-and-contract pattern: add the new column, backfill it, switch the application over, and drop the old column in a later release, so the database never blocks a deployment or a rollback.

A backup that has never been restored is a hope, not a plan. We schedule restores of production backups into an isolated environment, run integrity checks and row-count comparisons, and record how long the restore took, so recovery point and recovery time targets are based on measurements rather than assumptions.