It is slow. Nobody can say why.

Slow is a symptom. The question is what of.

The month-end close takes longer every quarter. A report that used to run in seconds now times out. Somebody suggests more hardware, somebody else suggests an index, and nobody can say which of the two hundred things happening inside the database is the one actually burning the time. So the estate accumulates indexes nobody measured, settings nobody revisits, and a slow drift that only becomes urgent the quarter it threatens a deadline.

The reason this persists is not that the answers are hard. It is that nobody measured. A database keeps detailed statistics about its own behaviour — which statements consume the time, which indexes are never read, which tables are never vacuumed, which configuration makes diagnosis impossible later. Reading those honestly takes an afternoon and turns an argument into a ranked list. Almost nobody does it before starting work.

To be exact about the boundary, because it is the question a DBA asks first: we never connect to your database. You run a bundle of read-only SQL that you have read, and hand back the output. The statements are checked against a forbidden-verb classifier when the pack loads and again immediately before each one executes, and the classifier refuses writes, DDL, transaction control, locking hints and host-touching functions. There is no agent to install and nothing to open in your firewall.

How a tuning engagement runs

1. /01

   Free 30-minute discovery call

   A working session, not a demo. What is slow, when it started, what changed, and what deadline it threatens. We tell you honestly whether measurement is warranted — and if the answer is that you need more hardware or a different query pattern rather than an engagement, we say that.

2. /02

   Read-only collection (your DBA runs it)

   We send a versioned bundle of read-only SQL plus a plain-English runbook. Your DBA reads every statement before running anything, runs it, and hands back one output file. We never connect to your database, and nothing is installed on your box. For PostgreSQL that is 4 pre-checks and 22 read-only queries; SQL Server is 5 and 19; MySQL is 4 and 17.

3. /03

   The ranked assessment (fixed fee)

   The collected evidence goes through a deterministic analysis engine — 18 rule packs across 9 finding categories — which produces a health score, a grade on a 5-band A–F scale, and every finding ranked by severity and ease of fix. Each finding cites the collected signal that produced it. A senior engineer then reads the whole report and writes the plan, because ranking is not judgement.

4. /04

   The tuning work itself

   A senior engineer does the work: index changes, query and access-path rewrites, configuration, vacuum and statistics strategy, and the maintenance window to land it in. Every change is a human decision — nothing is auto-applied to your database, ever.

5. /05

   Re-measure, and hand over

   The same read-only collection runs again against the same database, so the after-state is measured on the identical basis as the before-state rather than asserted. You keep the packs, the reports and the runbooks. If the honest finding is that the platform itself is the ceiling, that is the finding — and it is the conversation the migration practice exists for.

Rung three is the fuller read. If what you want first is simply to know what is wrong — one database, diagnosis only, and a smaller decision than this engagement asks for — that is a first look, and its fee credits against this work if you go on with it.

What the engine measures vs what the engineer does

"AI-powered performance tuning" is among the most over-claimed phrases in this market, so we separate the code that exists in our repository and runs today from the work a senior engineer performs by hand — and we name the things we do not measure rather than leaving you to discover them. If you ask us to demonstrate anything in the first column on a call, we can.

• Real todayMeasured — the read-only packs and the analysis engine
  • Ranks the statements actually consuming your database's time — the engine reports each hot statement's share of total DB time with its call count and mean duration, so effort goes where the time is rather than where it feels slow.
  • Finds unused and duplicate indexes, and separates a genuinely cold index (zero scans) from a low-usage one that still served reads — because the second is a judgement call and the first usually is not.
  • Flags foreign-key columns with no index, where a parent delete or update turns into a full scan of the child table.
  • Measures table bloat from dead tuples on PostgreSQL, and reports the engine-native proxies on MySQL and SQL Server as the proxies they are rather than as a measurement.
  • Checks the configuration that decides whether you can diagnose anything later at all: slow-query logging, autovacuum, buffer cache-hit ratio, and sessions sitting idle in transaction.
  • Reports connection-pool saturation, growth concentration, temp-file spill, stale planner statistics, never-vacuumed tables, and tables with no primary key.
  • Runs strictly read-only. Every statement is checked against a forbidden-verb classifier at load and again immediately before execution; locking hints and host-touching functions are refused outright.
  • Is deterministic. Same input, same findings, same score — there is no model in the analysis path, so a finding can be argued with rather than merely believed.
• Engineer-deliveredSenior-engineer work — priced as engineering
  • Reading the whole report and deciding what actually matters for your workload — a ranked list is an input to judgement, not a substitute for it.
  • Writing the index changes and the query rewrites, and proving each one against a plan before it goes anywhere near production.
  • Configuration and maintenance strategy: autovacuum and statistics targets, checkpoint and I/O behaviour, connection pooling, and the maintenance window to land changes safely.
  • Deciding what NOT to change. Dropping an index that serves one rare-but-critical report is the classic way a tuning engagement makes things worse.
  • The rollback plan, and being on the call when the change lands.
  • Saying when tuning has reached its ceiling and the honest answer is a version upgrade, an architecture change, or a migration.
• Not measuredWhat we do not do — discount it entirely
  • We do not analyse wait statistics. The SQL Server pack collects them, but the rule engine does not currently turn them into a finding — collected is not the same as analysed, and we will not imply the second because we do the first.
  • We do not tune automatically. Nothing is applied to your database by any tool of ours; every change is written, reviewed and executed by a person.
  • We have never run a collection against a CUSTOMER estate on any engine — there are no customers yet. PostgreSQL and SQL Server have each been run end-to-end against a live database, but both were Veltheon's own instance rather than anyone's production, and the SQL Server run was a seeded lab. MySQL has met no live database at all and is fixture-proven only. A first run against a real estate is still a disclosed hardening step on every engine, and if you are that first run we will tell you so and price accordingly.
  • We have no Oracle pack, collector or adapter. If Oracle is the database that is slow, this service does not cover it today.
  • We do not benchmark. The assessment is a point-in-time read of your database's own catalog and counters, not a synthetic load test, and it never claims to be one.

A real run — on our own database

Rather than an invented example, here is the engine's actual output against a real production PostgreSQL database. It scored 58/100, amber — grade D on the same A–F scale every assessment uses — 1 high-severity finding, 1 medium and 34 low. Three of those findings are below, quoted from the report as it was generated.

The database is ours. This is Veltheon's own production instance, not a customer's — we have no customers yet and will not imply otherwise. It is also a small estate. What it demonstrates is that the collection, the analysis and the report run end to end against a live database and produce specific, evidenced, actionable findings — not that we have tuned anyone. Your database will produce different findings, and the engine will show you which signal each one came from.

Every impact figure the engine produces is labelled [est.] and is a bounded planning aid — the report validator rejects a finding whose estimated impact is not labelled. Measured values are read straight from the collected evidence. Neither is a guarantee, and no assessment is a benchmark.

Where all 36 findings landed

The shape of a report is worth as much as its headline, because it is what tells you whether the engine looked where you needed it to. This is the whole distribution, not a selection.

Every category this run produced is a performance category. The same engine can also emit security, migration and availability findings — 9 categories in total — and this database produced none of them, so the report is a tuning report end to end. That is not a claim about your database; it is what one real collection returned.

If you want to read a whole assessment rather than three rows of one, the full deliverable — the score arithmetic, every finding, the evidence row behind each — renders in full on the sample report. That one is computed from a synthetic database when the page loads, not from ours: publishing all 36 findings from the run above would publish our own schema along with them. The engine, the scoring and the format are identical, and DB Observatory is the engine itself.

Dynamics NAV and Business Central

On-premises. And the distinction is not pedantry. Everything in this section describes Dynamics NAV and Business Central on-premises, where the ERP runs on a SQL Server instance you own and your own DBA can read. Business Central online — the SaaS tenant — runs on an Azure SQL database Microsoft administers, and nobody outside Microsoft holds a SQL surface on it. Not us, not your implementation partner, not you. You cannot open Management Studio against it, and you cannot add an index there. The method on this page is a read-only collection your own DBA runs against the ERP's database, so it is available on-premises and it is not available on SaaS. If a firm offers you SQL Server index tuning on a Business Central online tenant, that is worth one more question before you sign anything.

A slow SaaS tenant is still somebody's problem — the levers simply move up a layer, into AL and configuration: keys and SIFT, SetLoadFields and partial records, DataAccessIntent, and the telemetry Microsoft does expose through Application Insights. That is real work and it needs real skill. It is also a different engagement from this one, running on different evidence, and this page does not claim to be it. What is scoped here is the on-premises work.

A NAV or Business Central database on-premises is a SQL Server database, but it is slow for reasons a general-purpose tuner does not look for — and the two most common ones are things the ERP itself creates. So the collection runs an extra lens: 3 pre-checks and 10 read-only queries on top of the standard SQL Server pack, 8 and 29 together. It is the same engine and the same read-only guard, with an ERP lens over it — not a different product.

The two findings a generic tuner gets wrong

• SIFT keys are not indexes you can drop. NAV materializes every maintained SumIndexField key as a SQL Server indexed view, so each one is updated by every posting that touches the base table. The engine measures each key's reads against its maintenance writes and flags the ones that are written constantly and never read — the classic write-amplification sink. The remediation is the part that matters: the fix is made in NAV/AL by turning MaintainSIFTIndex off for the key, not in SQL Server. Drop the indexed view directly and the application recreates it. It also tells you to check the instance has been up long enough to cover a month-end before believing a key is cold, because a key read only at close would otherwise look unused.
• Statistics staleness is judged at your compatibility level, not your server version. SQL Server changed the auto-update-statistics threshold at compatibility level 130; below it, the old and far laxer formula still applies. Most ERP estates run a modern server hosting a database left at a legacy level, which is exactly the case where using the server version would over-report staleness on every large table. The engine branches on the collected compatibility level, prints which formula it used in each finding's evidence, and takes the laxer one when the level was not collected — declining to report staleness it cannot prove. On a real estate the two answers differ by roughly an order of magnitude, so this is the difference between a real finding and a page of noise.

What this lens does NOT do, and these are the absences most worth knowing before you buy it. It does not analyse lock contention. The pack collects SQL Server's cumulative lock-wait counters and the report prints them, but they are instance-wide and cumulative since the last restart, with no observation window — so the engine deliberately rates them at zero and projects no impact from them. Attributing contention to a specific posting routine or SIFT key needs a live capture while posting runs, which is engineering work, not a read-only audit. There is no table-extension lens: nothing measures Business Central extension tables, extension counts, or per-table key counts. It does not read C/AL or AL source — there is no parser, and the inventory comes from NAV's own metadata tables and the SQL catalog. And this lens has never run against a real customer NAV estate; it is proven against a synthetic one.

One framing note, because it decides whether this page is the right one for you. The ERP lens was built to answer can this estate move to Business Central, and most of what it collects still answers that — so a NAV assessment produces a migration-readiness report with the performance findings inside it, rather than a tuning report. If the deadline you are working to is Microsoft's NAV support cliff rather than a slow month-end, Dynamics NAV → Business Central is the engagement built around it, and it runs this same collection.

What we can measure, by engine

PostgreSQL work is also backed by a library of 15 operational runbooks — the procedures we follow, written down before we need them. The tuning-relevant ones cover query-performance regression, table and index bloat, lock contention, autovacuum, checkpoint and I/O tuning, connection storms, storage exhaustion and transaction-ID wraparound; the rest of the library is failover, restore and upgrade procedure rather than tuning. 4 of the 15 carry their own flag saying they need specialist review before anyone leans on them in an incident, and we publish that count for the same reason we publish the rest: a corpus claiming zero would be claiming a review it has not had.

Engagement & how it is quoted

Measurement is a small, scoped, fixed-fee step, and it is deliberately cheap relative to the tuning it scopes — you should not have to buy an engagement to find out whether you need one. The measurement fee is credited against the tuning work if you proceed with Veltheon, and the reports and packs are yours either way.

This is a scoped engagement with an end, not a retainer. If what you want is an ongoing operating partner — Dynamics 365 / Business Central performance work, cloud and database cost reduction, or senior judgment on call across a wider estate — that is Consulting, and it covers engines this page does not, Oracle among them.

Fixed fee in Canadian dollars, never time-and-materials. We do not publish a figure before we have seen the estate: scope depends on engine, database count, workload complexity and how much of the remediation you want to run yourselves. If measurement shows the platform itself is the ceiling, the honest next step is the Discovery Audit, not a tuning sprint we know will not hold.

Why Veltheon

• Evidence before opinion — the assessment is deterministic and every finding cites the collected signal it came from. You can disagree with a recommendation and check the measurement behind it, which is not true of a consultant's list of suggestions.
• Read-only by construction, not by promise — the refusal to write is enforced by a classifier in code, checked at load and again before execution, and your DBA reads every statement before running it.
• Senior-led — over twenty years of production database work across SQL Server, PostgreSQL, Oracle and Azure, including five-plus years specialising in Dynamics 365 BC/NAV performance. The tooling removes the grind, not the judgment.
• Honest track record — we are early and have no client references yet. We show the engine, the packs and a real run against our own database instead of implying customers we do not have.
• No lock-in — you keep the query packs, the reports and the runbooks. Nothing we leave behind requires Veltheon to read it, and the assessment is a document you could hand to any other engineer.