Your databases are where the record of your business actually lives. This capability covers keeping them fast, keeping them available, keeping them recoverable, and moving them when the platform underneath has to change. These are services defined by function rather than by product — the engine matters less than the discipline.
Database administration
Senior database administration, delivered as an ongoing service or as a defined project. Performance tuning, indexing strategy, query optimisation, capacity planning, access-control hardening, patching and version upgrades.
Most mid-sized institutions do not have a full-time senior DBA, and do not need one. What they need is someone accountable for the database being fast, patched, and correctly permissioned — and available when something is wrong. That is what this is.
- Health assessment. A documented review of configuration, performance, security posture and patch level, with prioritised findings.
- Performance tuning. Query and index optimisation, configuration tuning against your actual workload, and removal of the pathological queries every estate accumulates.
- Capacity planning. Growth trending for storage, connections and throughput, so procurement is planned rather than reactive.
- Access control hardening. Role and privilege review, removal of shared and orphaned accounts, least-privilege enforcement.
- Patching and upgrades. Planned patch cycles and major-version upgrades with tested rollback.
- PostgreSQL
- MySQL
- MariaDB
- Microsoft SQL Server
High availability and clustering
Design and implementation of replication and clustering so a single server failure is not a service outage.
The technology differs by engine — streaming replication and Patroni for PostgreSQL, Group Replication or Galera for MySQL, Always On availability groups for SQL Server — but the questions are the same. How much data can you afford to lose, how long can you afford to be down, does failover happen automatically or by decision, and has anyone actually tested it. We answer those with you first, then build to the answer.
- RTO and RPO definition. How long you can be down and how much data you can lose, agreed with the business before any topology is chosen.
- Topology design. Replication or cluster architecture matched to those objectives and to your network and site layout.
- Implementation. Build of the replication or cluster configuration, including quorum and witness arrangements where relevant.
- Automatic failover. Failover automation configured and tuned, including the split-brain protections that make it safe to leave automatic.
- Connection routing. Application connection handling so clients follow the primary without manual reconfiguration.
- PostgreSQL streaming replication
- Patroni
- MySQL Group Replication
- Galera Cluster
- MariaDB replication
- SQL Server Always On availability groups
- SQL Server failover clustering
Backup and recovery
Backup and recovery designed around one question: how do we prove we can restore. Everything else follows from that.
A backup that has never been restored is a belief, not a control. We design the strategy — full, incremental and point-in-time — automate it, store it in a way that survives the failure it is meant to protect against, and then schedule regular restore tests with documented evidence.
- Recovery objectives. Agreed recovery point and recovery time targets per system, set against business impact rather than technical convenience.
- Strategy design. Full, incremental and differential schedules, retention periods and point-in-time recovery capability matched to those objectives.
- File system backup. Servers, workstations and virtual machines, with incremental scheduling to control storage growth.
- Database backup. Engine-native backup with point-in-time recovery, consistent with your replication topology.
- Storage design. On-site, off-site and offline or air-gapped copies, kept within your jurisdiction and your control.
- PostgreSQL
- MySQL / MariaDB
- Microsoft SQL Server
- Linux file systems
- Windows file servers
- Virtual machine images
Disaster recovery and business continuity
Disaster recovery and business continuity planning: what happens when it is not a server that fails, but a site.
This is documentation and implementation together. Recovery objectives defined with the business, a secondary site designed and built, failover procedures written down in language someone can follow under pressure, and drills run periodically to prove the plan survives contact with reality.
- Business impact analysis. Which systems matter, in what order, and what the cost of unavailability actually is — agreed with the business, not assumed by IT.
- RTO and RPO definition. Per-system recovery time and recovery point objectives, signed off by the people accountable for them.
- DR site design. Secondary site architecture — a second data centre or another location you control. Public cloud is not required and, where sovereignty is a concern, not recommended.
- Replication and standby build. Database and system replication to the recovery site, sized to meet the agreed recovery point.
- Failover procedures. Written, step-by-step procedures including decision authority — who declares a disaster, and who they need permission from.
Database migration
Structured migration between database engines, versions or hosting environments — with a cutover plan that fits inside the outage window you can actually get approved.
Common drivers are licence cost, an engine reaching end of support, consolidation after a merger, or moving from physical servers to virtualised or containerised infrastructure. The technical work is usually the manageable part; the risk sits in the cutover, the rollback and the verification that the new system holds the same data as the old one.
- Assessment. Schema, data-type, stored-procedure and application-dependency analysis, with the incompatibilities identified up front rather than discovered at cutover.
- Migration design. Method, sequencing and cutover approach chosen against your acceptable outage window.
- Schema and object conversion. Tables, constraints, indexes, views, procedures and jobs converted and reviewed.
- Data migration build. Repeatable, automated migration process — not a one-off manual run.
- Rehearsal. Full dress rehearsal against production-scale data, timed, so the cutover window is known rather than estimated.
- Microsoft SQL Server → PostgreSQL
- Oracle → PostgreSQL
- MySQL → PostgreSQL
- Legacy MySQL → modern MySQL / MariaDB
- Physical → virtual
- Virtual → containerised
- Version upgrades within an engine
ETL and data integration
Building and maintaining the data pipelines between your systems — extracting from operational databases and legacy platforms, transforming to a usable shape, and loading into reporting, analytics or consolidated stores.
Everything stays inside your network. There is no cloud ETL service in the path, which matters when the data being moved is customer, transaction or account data.
- Source analysis. What data exists, where, in what state, and what it actually means — usually the part that takes longest and matters most.
- Pipeline design. Extraction method, transformation rules and load strategy, including how incremental updates and late-arriving data are handled.
- Implementation. Built pipelines using tooling appropriate to your estate, kept on your infrastructure.
- Data quality rules. Validation and reconciliation checks so a silently wrong load is caught rather than reported on.
- Scheduling and orchestration. Dependency-aware scheduling with retry and failure handling.
- PostgreSQL
- MySQL / MariaDB
- Microsoft SQL Server
- Flat file and CSV sources
- Legacy and proprietary exports
- Reporting and BI targets
Engines we work across
PostgreSQL, MySQL and MariaDB, and Microsoft SQL Server — including mixed estates, which is what most institutions actually have once different applications have each brought their own database along.
Where the work is a migration, the most common direction we are asked about is away from proprietary per-core licensing towards PostgreSQL. We will give you an honest assessment of whether that is realistic for your specific application estate, including the cases where it is not.
Microsoft SQL Server is administered, clustered and migrated alongside these. It is not open source, so it does not appear in the row above — that row is the open-source engines we deploy as well as operate.
Visit the PostgreSQL website
The official site of the PostgreSQL Global Development Group. Opens in a new tab — hold Ctrl (⌘ on a Mac) or middle-click to keep it in the background.
www.postgresql.orgVisit the MySQL website
The official site of Oracle Corporation, which publishes MySQL. Opens in a new tab — hold Ctrl (⌘ on a Mac) or middle-click to keep it in the background.
www.mysql.comVisit the MariaDB website
The official site of the MariaDB Foundation, which stewards MariaDB Server. Opens in a new tab — hold Ctrl (⌘ on a Mac) or middle-click to keep it in the background.
mariadb.org
Every service above, on your infrastructure
Each of these is delivered inside your network. The comparison that matters — jurisdiction, continuity, autonomy, evidence — is set out once, on Why On-Premises, rather than repeated here six times.