Every story on QueryTuning.org is a real production incident. Not a tutorial. Not a reconstructed example. Something that broke, at a real company, on a real database, and required a real engineer to diagnose and fix it. This page explains exactly what that means and how we verify it before anything goes live.
A story must begin with a real alert — a page, a ticket, a Slack message, a customer complaint — and end with a root cause that was confirmed, not guessed. The middle is the investigation: the wrong hypotheses, the queries that pointed nowhere, and the query or log line that finally revealed the truth.
Concept explainers do not qualify. "Here is how parameter sniffing works" is documentation. "Here is the parameter sniffing incident that froze our checkout for 58 seconds on Black Friday" is a story. We publish the second kind only.
We require all post-mortems to be written in RCA investigation format. This is not a style preference — it is the format that makes the story useful to someone facing the same incident at 2 AM. A tutorial tells you the answer. An investigation shows you how to find it.
QueryTuning.org covers PostgreSQL, SQL Server, MySQL, and Oracle. These four engines cover the overwhelming majority of production relational database deployments globally. We do not plan to add additional engines.
The eight problem categories — Query Performance, Locking & Deadlocks, Memory, Disk & I/O, Replication, CPU & Connections, Indexing, and High Availability — map to how a DBA thinks during an incident, not how a product manager would organise a blog. Every database problem that has ever existed fits one of these eight. We will not add a ninth.
This constraint is intentional. In five years, when there are 200+ stories across 32 category-engine combinations, the taxonomy will be the site's most valuable asset. A DBA searching for "PostgreSQL locking incident" will find every story we have ever published on that combination in one place. That only works if the categories never change.
Every post-mortem on QueryTuning.org is cross-linked to the equivalent incident on other engines. A MySQL replica lag investigation links to the PostgreSQL replication slot story and the Oracle undo retention incident. The failure mode is the same. The diagnostic tools are different.
No other database publication does this. A PostgreSQL DBA reading a MySQL post has nothing to gain from it on any other site. Here they can see exactly how the same class of problem presents and resolves on their own engine. That cross-engine perspective is what we are building toward.
The standard in one sentence: If a senior DBA facing this exact incident at 2 AM would find the story genuinely useful — not just technically correct, but useful in the moment — it belongs here. If not, it does not.
If you were on-call when it happened, confirmed the root cause, and have the diagnostic SQL to show your work — we want to hear about it. Contributors are credited by name or anonymously, at their choice.
GET IN TOUCH →