Database and pipeline benchmarks

Run the benchmark

With MariaDB and PostgreSQL available on the configured test URLs, run the default volume ladder from the repository root:

composer bench-databases

The default run measures database and application workloads at 100, 1,000 and 10,000 synthetic pages. The longer end-to-end pipelines default to 100 and 1,000 pages. Run their 10,000-page variants explicitly when needed:

PUSHWORD_BENCH_PIPELINE_VOLUMES=100,1000,10000 composer bench-databases

To reproduce only the 10,000-page static generation measurement:

PUSHWORD_BENCH_PIPELINE_VOLUMES=10000 \
  ./.scripts/test --benchmark StaticGeneratorBenchmarkTest

The runner prints Markdown tables and removes its temporary databases, generated files and result files after the run. DSN and volume overrides are documented in Contribute > Database volume benchmark.

What is measured

The pipeline volume is the number of synthetic pages added to the normal test fixtures. Consequently, operation and SQL-query totals also include the small set of pages already present in the development application. For pw:static, the query counter covers the command’s coordinating entity manager, not the separate render kernel connection. Instrumenting both connections is useful for profiling but adds enough overhead to invalidate cross-engine duration comparisons. Xdebug is disabled, database engines run locally, pipelines are sequential, and timings use a monotonic clock.

Reference environment

All three engines used the same application code and test environment. The server databases were reached over loopback, so these results do not include production network latency.

Database operation results

Times are milliseconds; lower is better. Write covers fixture insertion. Lookups is the complete batch of 200 indexed slug queries.

SQLite has the lowest write and point-lookup cost on this local, single-process workload. PostgreSQL’s larger fixed cost is visible at low volume, while its count, tag, JSON and list timings remain closer to SQLite than MariaDB at 10,000 pages.

Application workload results

Times are milliseconds; lower is better. Rich seed creates the related editorial and catalogue corpus and is not included in Read total.

The small-volume result is dominated by fixed round-trip cost. At 10,000 pages, PostgreSQL completes this particular read mix fastest, especially the catalogue and facet queries. MariaDB’s export pass is the largest outlier in this snapshot. These are workload-specific results, not a ranking of the databases in general.

Initial end-to-end pipeline results

Throughput includes the development fixtures as well as the requested synthetic volume. Peak memory is the PHP process peak, not total database or operating-system memory.

EasyAdmin stays effectively flat from 100 to 1,000 pages, and its constant query count is the more durable signal than the small timing differences. Page scan issues approximately two observed queries per processed page. The initial static-generation result showed the same shape on its coordinating connection, but profiling the render kernel exposed additional corpus-wide work hidden behind that count.

Static generation at 10,000 pages

The 10,000-page static scenario was run separately because it takes several minutes per engine. Each run successfully rendered and validated exactly 10,000 synthetic HTML files; the operation count also includes 17 development-fixture pages.

The initial run rebuilt two complete page maps for every rendered page: redirect lookup data in Core and internal-link source data in Link Improver. Both caches were cleared by the render kernel’s service reset after every request, turning otherwise linear work into two quadratic paths. Static generation now pins those read-only maps for one build. A render epoch still invalidates Link Improver data when the page corpus changes in a long-lived process. Feed generation also preloads the set of parent pages once instead of issuing one child-count query per page.

At 5,000 pages, the render-kernel phase fell from 39.5 s to 11.0 s and the complete run from 64.4 s to 36.2 s. The optimized 1,000-page runs took 6.9 s on SQLite, 8.2 s on MariaDB and 8.1 s on PostgreSQL. From 1,000 to 10,000 pages, duration now grows by 11.1x, 13.0x and 13.9x respectively, instead of 21–23x in the initial snapshot.

The benchmark also records generated HTML size and the kernel.handle, compression, file-write and page-generation phases in its JSON result. The 10,000-page corpus produced about 86.9 MiB of HTML on every engine. These diagnostics are deliberately reported rather than enforced as CI thresholds; shared-runner timing noise would make such thresholds unreliable.

Interpreting and updating the results

• Compare query counts and scaling curves before comparing sub-millisecond timings.
• Repeat pipeline runs when investigating a small difference; their published values are single snapshots, unlike the median database and application reads.
• Keep the same machine, engine versions and volume ladder when comparing a change.
• Do not infer concurrent request capacity: this benchmark is deliberately sequential and uses local databases.
• Update the date, environment and complete affected table after a representative rerun. Label code revisions explicitly when a table is intended as a before/after comparison.

The structural query-count regression tests under packages/core/tests/Perf/ and packages/admin/tests/Perf/ run in normal CI. Timing benchmarks remain opt-in because shared CI runners are too noisy for stable latency thresholds.