About SQLPress

Documentation describes what a database system does. Most articles describe what to do about it. The layer in between — why the system behaves that way, measured on a stated setup, with the boundary of the result written down — is what SQLPress publishes.

The subjects are query planning and execution, storage and internals, concurrency, and the operational side of running these systems in production. The audience is people who already write SQL — application developers, analysts, and database administrators — and who will notice when a claim is hand-waved.

The goal is not to be the largest database publication. It is for a reader to take a result from here, re-run it on their own system, and find out whether it holds. A claim that only works because the reader trusts the byline does not belong on this site.

Who writes SQLPress

Elias Rowe is a database engineer, and every article here carries that byline. The work spans four layers: how the planner chooses between access paths and where its row estimates come from, how storage and the buffer manager turn those choices into I/O, how concurrency control behaves when the two collide, and what the result looks like on a system that is already serving traffic. PostgreSQL and MySQL are covered in the most depth; data modeling and production operations are where the consequences of the other layers show up.

Depth here means being able to say where a claim stops. Naming a mechanism is not enough when the version it was observed on, the configuration that produced it, and the point at which it reverses are missing — those are the parts that decide whether the reader can use it. Articles include hypotheses that turned out to be wrong, results that failed to reproduce, and questions left open because the evidence ran out. Those are often the most useful parts, because they show the shape of the search rather than only its successful path.

What gets published, and what does not

Every article that reports numbers declares the environment they came from: the systems and their exact versions, the hardware, the dataset, the relevant configuration, and whether the workload was synthetic, a production trace, or production. That block is not a formality. It is the difference between a result you can check and a number you have to trust.

Every factual claim points at its source: official documentation, source code at a fixed ref, a mailing list thread, release notes, the SQL standard, published research, or a measurement published here. Version references are exact — the documented major version for a claim read from documentation, the full server version when numbers are reported, the specific release when a behavior changed there. Where a claim rests on someone else’s work, that work is named in a sentence, not a footnote.

Four things are not published. Recommendations produced for commercial reasons: there are no affiliate links and no sponsored content. Comparisons without measurements, and verdicts without the condition that would reverse them. Rewritten documentation — if the docs answer it, the docs get linked and the article covers what they leave out. And synthetic benchmarks presented as production reality: a synthetic result is evidence about a mechanism, not evidence about the reader’s system, and it is described that way in the sentence that reports it.

How an article is made

Every article goes through the same three steps. They are written down here because how an article was produced is part of whether its claims can be checked.

1. The author picks the subject and writes the draft. The starting material is real: production cases, query plans, and measurements taken on systems that were serving the workload. Nothing is invented to make a point.
2. A language model anonymizes and copy-edits the draft. Details that would identify the system a case came from are removed, and spelling, grammar, and awkward constructions are fixed. The model does not supply facts, numbers, versions, or sources.
3. The author audits the result before it is published. Every claim is checked back against its source or its measurement, the edits are reviewed for any meaning the model changed, and the article gets its final form. Nothing is published without this pass.

Claims that are checkable will sometimes be checked and found wrong. Corrections are published in place, with the date and the evidence that changed the conclusion; the original claim is not deleted quietly. A byline that rewrites its own history is worth less than one that publishes its corrections.

The place to verify any of this is an article. Open a recent one and read its References and Test environment blocks before trusting a number in it.