We help companies whose product runs on PostgreSQL, Oracle, SQL Server or MySQL find and fix the schema, query, configuration and recovery problems behind slow pages, rising bills and repeat incidents. We diagnose with read-only access, make the fixes on the database you already run, and stay on with ongoing support after they ship.
30 minutes with DharmOps. Or describe the problem and an engineer replies within 24 hours.
Most teams don't call us because of a database. They call because something the business depends on has stopped working the way it used to. These are the situations we hear most often.
Queries that used to return in milliseconds now take seconds, reports time out, and the usual fixes (adding an index, adding a replica, buying a bigger instance) helped for a few weeks and then stopped helping. The cause is usually a query plan, a missing composite index, table bloat or a configuration default that was never changed as the data grew.
How we debug a slow SQL queryCase: 4 minutes to 17 seconds on 340GB
Connections run out on Monday mornings. Disk fills overnight. A failover that should take seconds takes fifteen minutes. Each time the team restarts something and the alert clears, but nobody has found the reason it happened.
The instance has been resized twice, storage and I/O charges keep climbing, and nobody can say which queries are driving the cost. Often the database is paying for full table scans and dead rows, not for customers.
Lock waits, replication lag and "too many connections" errors appear at peak traffic. The design that worked at 10 GB doesn't work at 300 GB, and every new feature makes it worse.
The schema, the backup scripts and the failover setup were built by one person. Now nobody is sure the backups restore, why a setting was changed, or what will break during the next upgrade.
Amazon RDS for MySQL 8.0 left standard support on July 31, 2026, and RDS now bills Extended Support per vCPU-hour on top of the instance cost. SQL Server 2016 reached end of support on July 14, 2026. Upgrading a production database without a rehearsal and a rollback plan is how outages start.
AWS RDS Extended Support: what it costs and how to get off itPrice your extended-support bill on AWS, Azure or Google Cloud
Connections run out, queries queue up and transactions slow down. A bigger instance buys a few weeks, but the connection pool and the queries holding connections open are still sized for last year's traffic.
Replicas can't keep up with production writes, so reads return stale data and a failover would lose whatever hadn't arrived yet. The usual causes are write volume, long-running transactions or a replica undersized for the work sent to it.
Backups run every night, but nobody has restored one recently, so nobody knows whether recovery would meet the RTO and RPO the business assumes. The first real test shouldn't be the outage.
A migration that ran in seconds on staging locks a large table in production, or a deployment ships a change the application isn't ready for. The team starts saving changes for late-night windows, which makes each one riskier.
Too many people and services have privileged access, and nobody can say what each role is for. Removing anything feels risky, so permissions only ever grow.
Monitoring covers CPU and disk, but not the slow queries and query regressions users actually feel. By the time an alert fires, the support tickets have already arrived.
If one of these describes your week, the next step is a 30-minute call.
Book a Discovery Call (opens in a new tab)Want to see the work first? Read four situations we've fixed, with before/after numbers
Database engineering is the work of designing, fixing and changing the production database your application runs on, so it handles today's load and next year's at a sensible cost.
In practice, that means we work on:
Database engineering is not data pipelines, ETL or the data warehouse; that work belongs to our Data Engineering service. It is also not routine day-to-day administration such as patching, scheduled backups or creating user accounts.
PostgreSQL, Oracle and SQL Server, where our published case studies come from, plus MySQL, MariaDB, MongoDB and Redis. Self-hosted or managed: Amazon RDS and Aurora, Azure SQL and Google Cloud SQL.
When a database slows down, the first instinct is often to move to a different engine or a larger server. In most cases we see, the problem is the schema, the queries or the configuration, and it moves with you. The 340GB PostgreSQL database in our case study went from 4 minutes to 17 seconds on the same 32 GB server, without new hardware.
Each of these comes from a completed engagement, measured against the baseline we recorded before making any change.
| What changes | What it looked like | Why it matters to you |
|---|---|---|
| Your product gets faster | Primary report: 4 min → 17 s (340GB PostgreSQL). Finance reports: 3+ hours → 15 min average (Oracle ERP). Financial report: 45 s → 4 s (fintech). Dashboard: 8 s → 200 ms (B2B SaaS). | Users stop waiting, reports finish, and your team starts asking questions it had given up on. |
| The same hardware carries more load | 60% less disk I/O at peak reporting hours; 48 GB of dead-row bloat reclaimed. | You put off the next instance upgrade, and spikes stop slowing unrelated queries. |
| Changes ship without taking the product down | Zero downtime across all four published cases, including an Oracle to PostgreSQL migration with 0 records lost. | Schema changes and upgrades stop being something the team schedules for 2 a.m. and dreads. |
| Recovery is tested, not assumed | Restore drills and failover rehearsals with written runbooks. | When something does fail, the team follows a procedure it has already run once. |
| The knowledge stays with your team | Every change versioned in your repository; runbooks and architecture notes in your accounts. | You are not dependent on one person, including us. |
Query plan analysis, index design, configuration tuning, bloat and vacuum fixes, connection pooling.
You receive: a baseline report, a query bottleneck and wait-event analysis, a ranked list of fixes, and before/after measurements on the same metrics.
Why it matters: you can see exactly what changed and by how much, rather than taking "it feels faster" on trust.
Data model review, partitioning, read/write separation, design for the next stage of growth.
You receive: a reviewed design and scaling recommendations with the trade-offs written down, and schema changes delivered as versioned migrations.
Why it matters: future developers can see why the database is built the way it is, and changes go through your normal review.
Replication and failover setup, backup design, RTO and RPO targets.
You receive: a failover test result, a tested restore, and runbooks for both.
Why it matters: you know how long recovery takes and how much data is at risk before you need to find out.
Version upgrades (for example MySQL 8.0 to 8.4, SQL Server 2016 to a supported release) and engine moves (Oracle to PostgreSQL).
You receive: an inventory of everything that has to move, a rehearsal plan, rehearsal results, a data consistency report, and a cutover plan with a rollback.
Why it matters: the cutover is the fourth time the team has done it, not the first.
Oracle to PostgreSQL migration costMoving a warehouse or pipelines instead? Warehouse and pipeline modernization
Right-sizing instances to measured load, cutting the I/O and storage that bad queries and bloat create.
You receive: a list of changes tied to the metric each one reduces.
Why it matters: cost drops for a reason you can point to, so it doesn't creep back.
Cloud spend outside the database: Data Infrastructure FinOps
Health checks against the baseline, alert review, capacity and upgrade planning, schema and query review for new features, help during business hours, and on-call incident response if it's part of your support plan.
You receive: regular health reports, query monitoring with alerts configured, an upgrade and capacity plan kept current, and the same engineer who did the original work.
Why it matters: problems are found while they are still small, and you never have to explain your database to a stranger during an incident.
| Included | Not included |
|---|---|
| Transactional databases: PostgreSQL, Oracle, SQL Server, MySQL/MariaDB, MongoDB, Redis, and their managed cloud versions | Data pipelines, ETL, warehouses and lakehouses (Data Engineering) |
| Schema, indexes, queries, configuration, replication, failover, backup and recovery, upgrades, engine migrations | Routine administration: patching, scheduled backups, user account requests |
| Roles and least-privilege access | Formal compliance audits or certification (our work supports them; it isn't the audit) |
| Fixes in the database, plus guidance on the application queries that cause load | Rewriting application features or front-end work |
| Cost reduction that comes from database changes | Cloud spend outside the database (FinOps) |
| Advanced query and workload optimization | |
| Partitioning and connection pooling to scale on the same hardware | |
| CDC-based and low-downtime migrations | |
| Query monitoring and alerting | |
| Online schema changes, validated in staging at production volume | |
| Database-specific incident troubleshooting | |
| Everything in the agreed written scope | Anything new, which is added to the scope in writing first |
There are six stages, and you approve each one before the next starts. Nothing in your production database changes until you've seen the evidence and agreed to the change.
You describe the symptom, the engines you run and what you've already tried. We tell you whether it looks like a database problem and what a diagnostic would examine. If the fix is small enough for your team, or we're not the right team, we tell you on the call.
30 minutes · scheduled on our booking page
We sign an NDA, then work with read-only access to metrics, logs and query statistics. We record a baseline (query times, CPU, disk I/O, waits, bloat, connection use), trace each symptom to its cause, and write the report.
Usually 3–4 working days, report included · starts within 3 business days of the NDA being signed and read-only access being approved
We walk you through the report, answer questions on each finding, and turn the fixes you choose into a written scope.
A review meeting with your engineering and business leads, held when the report is delivered (or the next business day if your leads aren't available)
Each change is tested on staging at production volume first and ships with a rollback. Indexes are built without locking tables. Structural changes run old and new versions side by side until the switch is confirmed. Migrations are rehearsed in full against a copy of production before the cutover.
Applied in the change windows you agreed
We measure the same metrics as the baseline, on production, and compare them.
Straight after the last change
Business hours: health checks against the baseline, alert review, upgrade and capacity planning, and review of schema and query changes for new features. Outside business hours: on-call incident response, if it's part of your support plan.
Continues after the fix, with the same engineer
| Severity | Example | First response |
|---|---|---|
| Critical | Production database down, data at risk | Within 30 minutes |
| High | Severe slowdown, failing jobs, replication broken | Within 2 hours |
| Normal | Questions, planned changes, reviews | Next business day |
Response times apply during the hours in your written scope. On-call is an option within ongoing support, scoped and priced separately. These are response times, not repair times.
Estimates are given in writing in the diagnostic report and the agreed scope, and updated in the shared channel if anything changes them.
"We were running performance issues on a PostgreSQL database with over 300GB of data. DharmOps analysed the workload, found the bottlenecks, and handled the tuning at a scale that required genuine expertise. The scope of what they delivered at that data volume exceeded what we expected going in."
"Our PostgreSQL queries were slowing down as our dataset grew. We'd already tried the obvious fixes ourselves. DharmOps got into our query plans, identified the root cause quickly, and tuned what mattered. The kind of deep database knowledge you can't easily find elsewhere."
More on our work with SaaS and software companies.
When a database becomes a problem, teams usually weigh five other routes. Each one has a place; here is what each does and doesn't cover.
| Basis | DharmOps | Hire a full-time DBA | Large consultancy | Monitoring tool | Managed cloud database | Switch database engines |
|---|---|---|---|---|---|---|
| Time to start | A discovery call, then a diagnostic | Months to recruit | Weeks of scoping | Days | Already running | Months |
| Finds the cause | Yes, with evidence in writing | Depends on the hire | Yes | Shows symptoms and alerts | No: patches and backs up, doesn't redesign | No: the schema and queries move with you |
| Makes the fix | Yes, on the database you run | Yes | Often a report, with implementation sold separately | No | No | Rebuilds instead of fixing |
| Engines covered | PostgreSQL, Oracle, SQL Server, MySQL, MongoDB and more, one team | Usually one or two | Several, across separate teams | Several | One per service | One new engine |
| After the fix | Same engineer stays for ongoing support | Stays | Engagement ends | Keeps alerting | Keeps running | You start over on a new platform |
| Who owns the work | You: every change, report and runbook | You | Varies | Vendor dashboards | Cloud provider | You |
For the full numbers on one of these, see managed DBA vs hiring in-house: cost comparison.
One team from diagnosis to ongoing support.The engineer who found the problem fixes it and stays on. No handoff to a separate support desk.
Several engines, one team.If you run PostgreSQL next to SQL Server or Oracle, one team covers both.
Fix before you switch.We look for the design problem first, because a new engine won't fix a bad query.
Read-only first.Diagnosis starts without write access to anything.
You own everything.Changes live in your repository, documents in your accounts. If you stop working with us, nothing stops working.
Giving an outside team access to a production database is a serious decision. These are the rules we work by.
You don't need to know before you call. Slow APIs and timeouts are often blamed on the database when the time is really spent in application code, the network or an external service. The diagnostic measures where the time goes. If it's outside the database, the report says so and shows the evidence, so you don't pay for fixes in the wrong place. Slow API? It might not be the database
We start from measurements, not from the usual checklist. Most teams have already added indexes, added a replica or moved to a bigger instance. We look at the query plans, wait events, bloat and configuration together, because the cause is often several small problems making each other worse. In the 340GB case, four separate causes, none visible in the application logs, added up to a 4-minute report.
In most cases, fix it first. Slow queries, a poor schema and default configuration move with you to a new engine, and the migration adds risk and months of work. Switching makes sense when something outside performance forces it: licensing cost, a feature the engine can't support, or the end of vendor support. In that case the move should be rehearsed in full before the cutover, as in our Oracle to PostgreSQL migration.
Yes. Managed databases hide the operating system, but most performance and reliability work happens through what they do expose: parameter groups and configuration, query statistics, Performance Insights or Query Store, replicas and failover settings, and instance sizing. AWS RDS performance tuning
It gets rolled back. Every change is tested on staging first, ships with a rollback, and is measured against the baseline after it's applied. If a change doesn't move the metric it was meant to move, we reverse it and say so in the results. You see the before/after numbers for every change, not a summary.
We work with them. Your team approves every production change, sees the reasoning in the shared channel, and gets the runbooks and a walkthrough as each change ships. Many clients keep their own engineers on day-to-day work and use us for diagnosis, the harder changes and on-call cover.
Each stage is priced separately, and you see the price before agreeing to it. The diagnostic is quoted after the discovery call. The fixes are quoted in the written scope, after you've seen the report. Ongoing support is a monthly retainer. What affects the price: how many databases and engines you run, the data size, how urgent the work is, and the support hours you need, including on-call if you want it. Cost-reduction work is usually planned so the savings help pay for the fixes.
No. The diagnostic, the fixes and ongoing support are separate stages, and you decide at each one whether to continue. Ongoing support runs month to month, and either side can end it with 30 days' notice. Everything we produce lives in your repository and accounts, so stopping doesn't leave you dependent on us.
Yes. Business-hours support runs in your time zone, wherever you are. During the hours in your written scope, critical incidents get a first response within 30 minutes. On-call outside those hours is an option within ongoing support, scoped and priced separately.
We work inside your environment, under your access controls, with least-privilege roles, logged access and verified deletion when the work ends. Tell us your requirements on the discovery call and we'll set up access to match them from day one. We support your compliance work; we don't run the audit. Access control and audit logging for SOC 2, HIPAA and GDPR
A slow or fragile database costs different things in different industries: a missed report deadline, a failed recovery, a checkout that stalls at peak. The cause is usually in the queries, the configuration or the recovery plan.
Moving off Oracle for licensing cost is a large project. We fix the design problems first so they don't move with you, and rehearse the migration in full against a copy of production before the cutover.
Clinical and claims systems can't afford an untested recovery. We rehearse failover and test restores, and write the runbooks, so recovery doesn't depend on someone remembering the steps.
A product page or checkout that slows at peak usually traces to a query plan or a connection limit, not the size of the server. We measure it and fix the cause before adding hardware.
Dashboards that were fast at launch slow down as customer data grows. We find the query and index causes, and every change lands in your repository for your engineers to review.
End-of-day reports that run for hours can block order entry. We trace the heaviest reports to their queries and processing logic, and fix them without changing what the report shows.
Shipment and fleet data arrives in constant high-volume writes. We tune ingestion and keep peak-hour reports finishing, with the work tested before it reaches production.
Bring the symptom to a 30-minute discovery call. You'll leave knowing whether the problem is in the database and what the diagnostic would look at.
"…We had a PostgreSQL function requirement that needed real database knowledge to implement well. They delivered a clean, working solution without any back-and-forth."