Enterprise database work, on estates nobody designed
Large database estates are rarely the product of a decision. They are the accumulated residue of acquisitions, departmental purchases, and a migration that stopped at 80% — which is why the first task is almost always finding out what is actually there.
What changes here
Database Management in enterprise is not the same engagement
Inventory before strategy
Most estates contain instances nobody owns, running versions nobody supports, holding data somebody depends on. We map what exists, what reads from it, and what would break — before proposing anything, because a consolidation plan built on an assumed inventory fails at the first unexpected dependency.
Licence cost is an architecture decision
Commercial database licensing is often the largest line in an enterprise data budget, and it is set by core counts and edition choices made years ago. Consolidation and version choices move that number materially, which is usually what funds the rest of the work.
Performance work without a rewrite
Most enterprise performance problems are a query plan, an index, or a lock pattern, not an architecture. We exhaust those before recommending anything structural, because a rewrite proposed early is usually a rewrite proposed instead of a diagnosis.
What makes enterprise database work different
The technical work is conventional. The constraints around it are what set the pace.
- Change control and approval gates that apply to schema changes as much as to code
- Retention and legal hold obligations that restrict what may be archived or deleted
- Cross-border transfer rules where the estate spans jurisdictions
- Licence terms that make some architectures far more expensive than others
- Downtime windows measured in hours per year, negotiated well in advance
The work itself
Full database management pagePerformance tuning and query optimization
Slow-query analysis, index and plan work, connection pooling, and caching — measured against your real workload rather than a synthetic benchmark.
Migrations, upgrades, and platform moves
Version upgrades, on-premise to cloud, and engine changes run with dual-write or replication, a verified row count, and a rollback path.
Schema design and data modelling
Normalization where integrity matters and denormalization where reads do, with constraints and migrations version-controlled alongside the application.
High availability and replication
Primary/replica topologies, automatic failover, and read scaling, with the failover path exercised rather than documented and forgotten.
Backup, retention, and tested restore
Point-in-time recovery, retention set against your obligations, and restore drills that produce an actual number for how long it takes.
Monitoring and managed DBA cover
Query, lock, replication-lag, and capacity alerting, with a named engineer for the escalations that arrive at 2am.
Enterprise questions we get asked
Something more specific? Send us the situation and we’ll answer it straight.