(Data management & DBA)

Database administration for systems you cannot take offline

Tuning, backups that somebody has actually restored, failover you have rehearsed, and version upgrades done without a weekend outage. Database administration is judged on the months when nothing happens.

Talk to an engineer What we deliver
AI concept render
Data management & DBA

(The backup nobody has tested)

Every organisation has a backup job. Far fewer have a restore that someone has run this year, against the current schema, with a stopwatch on it. The distance between those two things is where an afternoon’s incident turns into a week of one, usually while the person who knew the procedure is on leave.

A first engagement normally includes a timed restore drill on a copy, written up with the actual recovery time. Should it fail, you find out on a Tuesday rather than during the outage.

(What we deliver)

What database administration and data management covers

Taken as a whole for a managed arrangement, or one at a time when something specific is hurting.

  1. Query plans, missing and redundant indexes, lock contention, connection pooling and autovacuum settings that were last touched at installation. Findings come with measured before and after figures on your own workload, not a generic checklist.

  2. Point-in-time recovery configured properly, an agreed recovery point and recovery time, offsite copies, and restore drills on a schedule. The drill produces a timed runbook your own team can follow at three in the morning.

  3. Streaming replicas with Patroni, SQL Server availability groups, or managed multi-zone equivalents. Failover is tested deliberately rather than discovered during an incident, and read traffic is routed so replicas earn their cost.

  4. Major version upgrades, moves from self-hosted to RDS, Aurora or Cloud SQL, and engine changes such as Oracle to PostgreSQL. Cutover uses logical replication where possible, so the switch is minutes and the rollback is real.

  5. A retention schedule per table, archival that keeps the primary lean, masked copies for development, quarterly access reviews and deletion that satisfies a subject request under GDPR or India’s DPDP Act.

  6. Alerting on replication lag, disk headroom, slow queries and failed jobs, with capacity trends reviewed monthly. Small changes and patching come out of an agreed capacity; you get a named engineer and an escalation path.

(Databases we look after)

(How we work)

How a database engagement runs

The first two phases are short and produce evidence. Nothing is changed on a production database before that evidence exists.

  1. 01

    Assessment

    Configuration, schema, index usage, query statistics, backup configuration and current alerting. You get a written report listing the risks in the order they are likely to bite.

  2. 02

    Restore drill

    A recovery rehearsed on an isolated copy and timed against your stated recovery objective. Most of the uncomfortable findings in this work surface here.

  3. 03

    Stabilise

    The quick corrections: indexes, connection limits, autovacuum, alert thresholds, retention on log tables. Applied in maintenance windows with a rollback for each change.

  4. 04

    Improve

    Replication, failover testing, a read replica for reporting, archival of historical data, masked environments for development. Sequenced so each piece is useful on its own.

  5. 05

    Run

    Monitoring, patching, capacity review and a monthly report on growth and the slowest queries. Handover documentation stays current whether or not you keep us on support.

(Why Team of Keys)

How we keep database administration boring

Database incidents are rarely surprises in hindsight. Four disciplines account for most of the ones that never happen.

  1. 01

    Restores on a schedule

    Recovery is tested at an agreed interval and the time it took is recorded. A backup that has never been restored is a hope, and hopes do not have a recovery time.

  2. 02

    Least privilege, reviewed

    Application accounts get only the rights they use, administrative access is separate and logged, and the access list is reviewed quarterly rather than after somebody leaves.

  3. 03

    Every change has a way back

    Migrations run through version control with a tested down path. Schema changes on large tables use concurrent or online methods, so an index build does not lock a live service.

  4. 04

    Capacity watched ahead of time

    Disk growth, connection counts and replication lag are trended, so the conversation about a bigger instance happens weeks before the alert rather than during it.

  5. 05

    Runbooks your team can use

    Failover, restore, upgrade and scaling procedures are written for whoever is on call, in your wiki, in plain language. Nothing important lives only in an engineer’s memory.

(Related)

More in ai & data

All ai & data services

(FAQ)

Questions, answered

The assessment and restore drill are a fixed price over two to three weeks. Ongoing administration is a monthly capacity sized to the number of instances and how critical they are, covering monitoring, patching, tuning and an escalation path. Larger projects such as a migration or a high-availability build are quoted separately.

Frequently, yes. Indexes, configuration, connection pooling, statistics and vacuum behaviour often account for most of the problem and need no application change. Where a query pattern is the real cause, you get the specific statement, the plan and a suggested rewrite for your developers to review.

Managed services remove backup plumbing, patching and failover mechanics, which is worth a great deal to a small team. They cost more per hour and restrict extensions and configuration. Where you have tight latency requirements, unusual extensions or an existing platform team, self-managed can still be the better answer.

Often that is the arrangement. Common patterns are out-of-hours cover, a second pair of eyes on a migration, or specialist help with an engine your team does not use daily. Findings are shared with your DBA first rather than delivered over their head.

Yes, and the honest part of that answer is that the database is the easy half. Stored procedures, PL/SQL packages, driver behaviour and reporting tools need attention. Assessment comes first, giving a component-by-component view of what converts automatically, what needs rewriting and whether the licence saving justifies it.

(Global presence)

Nine countries, one studio behind them.

Every project is designed, built and shipped from one studio.
Turn the globe, or pick a country to see what we deliver there.

NoidaDrag to turn

Studio · Noida, India · --:--

(Next step)

When did you last restore a backup?

Tell us which databases you run, what version they are on and what worries you about them. The assessment gives you a risk-ordered list and a price.

START

Or write to info@teamofkeys.com · Noida, India