Database server PGO tests show why optimisation can reduce speed
PGO tests of the open-source relational database used by many web applications reported by Percona show that an optimisation intended to make database software faster can also produce a slower executable. In one comparison, a release built with profile-guided optimisation (PGO), which uses recorded program behaviour to guide compilation, delivered an improvement below 5%. But custom builds trained on a particular database test ran more slowly than builds without PGO. These are separate observations, not evidence that the technique universally helps or hurts.
In an article dated October 9, 2026, Percona describes investigating whether enabling PGO by default for its database server makes sense. The report is the opening part of a three-part explanation covering what PGO is, how it works, and why a build trained with sysbench, a performance-testing tool, loses performance and how to approach training correctly. This first instalment reports the unexpected result but does not establish its cause.
PGO changes how software is built. Compilation translates source code into an executable program. In the two-pass process Percona describes, the first build includes instrumentation, extra counters that record activity at branches, where execution chooses a path; loops, where work repeats; and call sites, where one function invokes another. A representative training workload, the tasks used to exercise the program, then runs against that instrumented build. The counters identify frequently executed code, called hot code, and rarely executed code, called cold code. A second compilation uses those observations to shape the resulting executable.
The compiler can use this information in several ways. It can inline hot calls more aggressively, placing a function's instructions directly where they are needed rather than making a separate call. It can arrange frequently taken paths so execution continues through adjacent instructions, while moving rarely used paths aside. It can also reorder functions inside the binary, the compiled executable file, so code that frequently works together sits close together. This improves instruction-cache locality, meaning the processor can make better use of its small, fast store of program instructions. Frequently resolved indirect calls, whose destination is selected during execution, can also become direct calls to a known destination.
These mechanisms explain why training quality matters. PGO does not simply accelerate the training session. It changes the executable's structure according to the activity observed during that session. The relevant question is therefore whether the training reflects the work the database needs to perform, not merely whether a training run completed successfully. A profile supplies evidence about one pattern of execution, not a promise of faster performance under every pattern.
Percona reports two distinct outcomes. Comparing a non-PGO build with a PGO release showed a small benefit, below 5%. Separately, when compiling the open-source database with PGO using a recording of sysbench-tpcc, a database transaction test, the resulting build was consistently slower than the build without PGO in the reported tests. Changing the training concurrency, the number of threads carrying out work at once, did not reverse that result: Percona says it tried thread counts from 128 to 1024. The account does not quantify the slowdown in its prose, so there is no supported percentage to attach to that regression.
An important qualification appears in the reader discussion. A commenter questions whether all other compiler settings remained identical when PGO was switched off. The comment also suggests enabling link-time optimisation (LTO), which lets the build tools optimise across separately compiled parts of a program, and argues that it can strengthen PGO's gains. Those are a reader's proposed checks, not confirmed explanations or additional experimental findings. The supplied account does not establish whether other settings changed or whether LTO was enabled.
For database operators and businesses relying on the open-source database, the transferable lesson is to validate a build change rather than treat an optimisation label as proof of improvement. A useful comparison should hold other build settings constant and use work that reflects the intended deployment. The reported thread range also shows why increasing training concurrency alone cannot be assumed to solve a performance regression. This is a performance investigation, not a report of a security vulnerability.
For organisations relying on outside operational support, AEU Data's managed databases, monitoring and automated backups are relevant to overseeing database changes and protecting stored data, but those services do not establish whether a particular PGO build is faster. The unresolved issue in Percona's opening report remains specific: why this sysbench-trained build lost performance, despite a separate release comparison showing a modest gain.