A database consulting engagement is judged by what it leaves behind, and most leave behind a slide deck. The slides say the buffer pool should be larger, the indexes should be reviewed, and the replication topology should be reconsidered, and none of it is wrong; it is also not evidence, not a procedure, and not something the customer’s own team can act on at 3 a.m. six months later.
The difference between consulting that changes an estate and consulting that decorates it is the deliverable: what is handed over, and what each handed-over thing has to prove before it is accepted.
This page describes database consulting as five deliverables, in the order they are produced, with the acceptance criterion for each: the evidence pack, the ranked findings, the change procedure, the verification record and the handover.
Each section explains what the deliverable contains, how a customer should test it before signing it off, and which archive post shows the deliverable produced for a specific engine, from Exadata and SQL Server to Db2 for z/OS, SAP HANA, MongoDB, MySQL and Azure SQL. The order is the method; a consulting engagement that produces the third deliverable without the first is a guess with a procedure attached.
Database consulting deliverable 1: the evidence pack
The first thing a consulting engagement hands over is not an opinion but a collection: the catalog views, wait statistics, plan history, configuration, log excerpts and host metrics that describe the estate as it was found, each with a timestamp and the query or command that produced it. The pack is the baseline every later claim is measured against, and it is delivered before any recommendation is made, because a recommendation made before the pack exists is one that the pack may later contradict.
The acceptance test is reproducibility: a customer engineer runs the same queries and gets the same shape of result. expensive SQL on Exadata 26.1: reading the offload numbers is an evidence pack for one engine, and its structure is the reusable part: the AWR and SQL Monitor sections that show where the time went, the cell offload statistics that show what the storage did, and the plan with actual rows against estimates.
Db2 13 for z/OS index efficiency: eight troubleshooting checks is the same deliverable on a platform where the evidence comes from EXPLAIN tables, RUNSTATS currency and the accounting trace, and where the customer’s systems programmer is the one who has to be able to rerun it.
Database consulting deliverable 2: the ranked findings
The second deliverable is a list of findings, each tied to a line in the evidence pack, each with the share of the problem it accounts for, and ranked by that share divided by the cost and risk of the fix. A finding without an evidence line is an opinion; a finding without a share is unranked; a list that is not ranked leaves the customer to guess where to start. The list is short by design, because the share column concentrates: three findings usually account for most of the latency, and the rest are noted for a later engagement.
SQL Server 2025 expensive queries: seven proven ways to find and fix them is a findings list in that form, where the Query Store supplies the share (total duration and total CPU by query over the window) and the ranking follows from it. how to diagnose slow queries in SAP HANA, step by step is the HANA version, where the share comes from M_EXPENSIVE_STATEMENTS and the plan cache, and the ranking is complicated by the memory dimension: a statement that is fast but unloads columns for others is a finding in its own right.
The acceptance test for the findings is the share column adding up. If the top three findings claim to account for eighty percent of the latency and the evidence pack’s total does not support that, the list is rewritten before it is presented, not defended after.
-- deliverable 2 as data: findings tied to evidence, with the share that ranks them (PostgreSQL 12+; illustrative)
CREATE TABLE consulting_finding (
finding_id smallint NOT NULL,
engagement_id text NOT NULL, -- e.g. MDB-HC-2026-09-ACME
evidence_ref text NOT NULL, -- pack section and query, e.g. 'E1.4 pg_stat_statements top-25'
finding text NOT NULL,
share_pct numeric(5,2) NOT NULL, -- share of the measured problem this finding accounts for
fix_cost smallint NOT NULL, -- 1 (setting) .. 5 (re-architecture)
fix_risk smallint NOT NULL, -- 1 (reversible online) .. 5 (irreversible / downtime)
rank_score numeric(8,3) GENERATED ALWAYS AS (share_pct / (fix_cost * fix_risk)) STORED,
CONSTRAINT pk_consulting_finding PRIMARY KEY (engagement_id, finding_id),
CONSTRAINT ck_consulting_finding_share CHECK (share_pct >= 0 AND 100 >= share_pct)
);
-- the acceptance query: the shares must be consistent with the evidence pack's measured total
SELECT engagement_id,
COUNT(*) AS findings,
ROUND(SUM(share_pct), 1) AS share_claimed_pct,
ROUND(MAX(rank_score), 3) AS top_rank_score
FROM consulting_finding
GROUP BY engagement_id
HAVING SUM(share_pct) > 100; -- any row here is a findings list that overclaimsKeeping the findings as rows is not bureaucracy; it is what lets the fourth deliverable be produced automatically, because the same evidence reference is re-run after the change and the share column is measured again rather than asserted.
Database consulting deliverable 3: the change procedure
The third deliverable is a procedure per finding, written so that the customer’s own on-call engineer could execute it: purpose, scope, prerequisites, the verification query that confirms the precondition, the change itself with the exact parameter or statement, the expected output, the validation query that confirms the effect, the rollback, and the escalation path.
A destructive step (anything that drops, truncates, detaches or rewrites) sits behind a confirmation gate that names what will be lost. This is the house runbook form, and the reason it is the third deliverable rather than the first is that its verification queries come from the evidence pack and its ordering comes from the findings.
connection pooling best practices for MySQL at scale is a change procedure in that shape for one finding class (pool saturation at the proxy and thread pool at the server), and eight proven Azure SQL caching strategies for sub-millisecond reads is a set of them for a managed service, where the procedure has to say which changes are the customer’s to make and which need a service-tier change. The acceptance test is a dry run on a staging copy by someone who did not write the procedure; a step that needed the author present is rewritten.
Database consulting deliverable 4: the verification record
The fourth deliverable is the evidence pack run again after the changes, laid beside the original, with the share column of the findings list re-measured. This is the deliverable that most consulting engagements skip, and it is the one that makes the others honest: a finding that claimed forty percent of the latency and removed five percent of it was misranked, and the record says so. The record also catches the regressions, because a change that fixed one finding and created another shows up as a new line in the second pack.
MongoDB performance tuning from 1 ms to 100 microseconds is a verification record in narrative form: the same operations profiled before and after each change, with the numbers at each step and the change that produced them. The figures are the customer’s and are labelled as such; the transferable part is the discipline of re-measuring after every step rather than at the end, so that each change’s effect is attributable. The acceptance test is that every finding in deliverable 2 has a before and an after line, including the ones whose after line is disappointing.
Database consulting deliverable 5: the handover
The fifth deliverable is what lets the customer’s team operate without the consultant: the runbooks from deliverable 3 filed where the on-call engineer will find them, the evidence-pack queries scheduled so that the baseline keeps being collected, the monitoring alerts that page on the conditions the findings described, and a short written statement of what was changed, what was not, and what should trigger the next engagement. A handover that consists of the slide deck and a phone number is not a handover.
polyglot persistence: the case for five data models is in this archive because the handover for a multi-engine estate has to say which engine owns which workload and why, so that the next team does not undo a placement decision the engagement made on evidence. The acceptance test for the handover is a question the consultant is not there to answer: the customer’s engineer is given a symptom from the findings list and asked which runbook applies, and finds it.
The five database consulting deliverables, side by side
| Deliverable | Contains | Accepted when | The failure it prevents |
|---|---|---|---|
| 1. Evidence pack | Catalog views, waits, plans, config, logs, host metrics; each with timestamp and the query that produced it | A customer engineer reruns the queries and gets the same shape of result | Recommendations the evidence later contradicts |
| 2. Ranked findings | Findings tied to evidence lines, each with its share of the problem, ranked by share over cost and risk | The shares are consistent with the measured total; the list is short | Twelve unranked suggestions and a customer who starts with the easiest |
| 3. Change procedure | Per-finding runbook: verify, change, expected output, validate, roll back, escalate; gates on destructive steps | A dry run on staging by someone who did not write it | A change the on-call engineer cannot execute, or cannot reverse |
| 4. Verification record | The evidence pack rerun after the changes, findings re-measured, regressions listed | Every finding has a before and an after line | Claimed improvements; hidden regressions |
| 5. Handover | Runbooks filed, baseline collection scheduled, alerts set, statement of what changed and what should trigger the next engagement | The customer’s engineer finds the right runbook for a symptom without asking | Dependence on the consultant |
The order is fixed because each deliverable is built from the one before it; an engagement that starts at deliverable 3 has skipped the two that would have told it what to change.
Sizing a database consulting engagement by its deliverables
The five deliverables also size the engagement. A health check is deliverables 1 and 2 with the procedures sketched rather than written; a performance engagement is all five for one engine and one workload; an architecture review is deliverables 1, 2 and 5 with the change procedures owned by the customer’s own project; a migration is all five with deliverable 3 as the largest, since the cutover runbook is the procedure.
Stating an engagement in these terms, rather than in days, is what lets a customer compare two proposals and what lets the engagement be accepted piecewise rather than at the end.
Vendor neutrality is the other thing the deliverables enforce. A findings list ranked by measured share cannot favour a product, and a verification record that re-measures cannot claim an improvement a product did not deliver. MinervaDB’s consulting practice covers PostgreSQL, MySQL and MariaDB, SQL Server, Oracle and Exadata, Db2, SAP HANA, MongoDB, ClickHouse (through ChistaDATA) and the major cloud services, and the same five deliverables are produced on each; the recommendation against an engine, when the evidence supports it, is written in the same form as the recommendation for one.
Version notes: the catalog views and wait names that populate an evidence pack move with engine releases (the posts above are pinned to Exadata 26.1, SQL Server 2025, Db2 13, HANA 2.0 and current MongoDB and Azure SQL), so every pack states the exact versions it was collected on, and every procedure is tested on those versions before it is handed over.
Every change procedure carries the standing caveat: test on a staging copy under production-shaped load before applying to production, and keep a restore-tested backup and a rehearsed DR posture in place before any step that touches durability, storage layout or topology.
What each database consulting deliverable asks of the customer
The deliverables are not produced by the consultant alone, and the customer’s share of the work is stated at the start so that it is not discovered at the end. The evidence pack needs read access to the catalog and to the host, a window in which the collection queries can run without being mistaken for an incident, and an engineer who can say which workloads matter, since the pack is filtered by the workload’s own queries rather than by the whole server.
The findings need an hour with the people who own the application, because the share column can be measured but the cost and risk columns are partly theirs: an index that is cheap to build on one table is expensive on a table the application rebuilds nightly, and only the application team knows which is which. The change procedure needs a staging environment that resembles production closely enough for the dry run to mean something, and a named engineer to perform it.
The verification record needs the same window the evidence pack had, at the same time of day and on the same day of the week where possible, because a before-and-after comparison across a quiet Sunday and a busy Monday measures the calendar rather than the change. The handover needs the on-call rota, the alerting stack and the document store where the runbooks will live, and it needs the customer’s engineer in the room for the symptom-to-runbook test.
How the same deliverables run a 24×7 database consulting relationship
An engagement ends with a handover, and a support relationship begins with one. The evidence-pack queries that were scheduled in deliverable 5 keep collecting, so that the next incident starts with a baseline rather than with a blank page; the findings list becomes the backlog that quarterly reviews re-rank as the workload changes; the change procedures become the runbooks the on-call engineer executes under the S1 fifteen-minute response; and the verification record is re-run after every change the support team makes, so that the estate’s history is a sequence of measured deltas rather than a folder of tickets.
This is the reason the practice insists on the five deliverables even for a short engagement: they are the same artefacts a long relationship runs on, and an engagement that produced them has already done the onboarding for the support contract that may follow. A customer who chooses not to continue keeps a set of documents that a different team can pick up, which is the vendor-neutral principle applied to the engagement itself.
Where this database consulting archive sits
This archive is the engagement-method layer of minervadb.com. The database performance tuning archive is the cross-engine method that produces deliverable 2’s share column, the monitoring archive is where deliverable 5’s alerts come from, the data strategy archive is where the placement decisions a handover records are made, and the DBaaS archive covers the managed-service boundary that a procedure has to respect. The runbook form used in deliverable 3 follows the operational principles set out in the Google SRE book, adapted to the database estate.
For a health check, a performance engagement, an architecture review or a migration delivered as these five deliverables with their acceptance tests, the MinervaDB database consulting practice states at proposal time which deliverables the engagement produces, and at handover which finding each change addressed and what the verification record measured.
