Benchmark report 01 · measured August 31, 2026

PostgreSQL reference workload: 559.87 requests/second median

A synthetic PostgreSQL-backed HTTP application completed 41,884 measured requests across five repeated warm-cache runs with 0 application errors. Request-level results and the complete reproducer are published below.

Report maintained by Shakeel Ahmed, Lead Architect · Published August 31, 2026 · Browse all research and evidence

Scope: a reference workload, not a production capacity guarantee.

The application, load generator, and database ran on one Windows developer machine. This result establishes what the disclosed setup measured; it does not establish universal PostgreSQL performance, Core Panel overhead, or superiority over another control panel.

Headline results

Five repeated 15-second runs at concurrency 32

Median throughput

559.87

requests/second

p50 latency

42.528

milliseconds

p95 latency

160.584

milliseconds

p99 latency

258.382

milliseconds

Error rate

0.00%

0 of 41,884

The reported latency values are medians of each run's percentile, not percentiles recalculated from a pooled request population. Throughput ranged from 534.20 to 584.07 requests/second, with a sample standard deviation of 17.92 requests/second and 3.21% coefficient of variation.

Throughput and latency by run

Every run used the same duration, concurrency, worker count, dataset, and request mix. Bars share a zero baseline and the same 584.07 requests/second maximum.

Run 1584.07584.07 req/s

Run 2552.93552.93 req/s

Run 3559.87559.87 req/s

Run 4561.2561.20 req/s

Run 5534.2534.20 req/s

Run	Requests	Throughput	p50	p95	p99
1	8,761	584.07 req/s	43.321 ms	137.443 ms	211.899 ms
2	8,294	552.93 req/s	42.528 ms	160.863 ms	238.348 ms
3	8,398	559.87 req/s	40.934 ms	160.584 ms	261.103 ms
4	8,418	561.20 req/s	39.391 ms	161.116 ms	258.382 ms
5	8,013	534.20 req/s	42.624 ms	157.979 ms	268.971 ms

Operation-level medians

Operation	Mix	Requests	Median req/s	p50	p95	p99
Indexed account read	70%	29,521	394.20	39.231 ms	152.712 ms	247.338 ms
Regional aggregate	20%	8,439	112.73	49.673 ms	163.840 ms	249.659 ms
Transactional write	10%	3,924	52.87	48.609 ms	191.739 ms	327.436 ms

Dataset and query mix

Deterministic relational workload

Accounts: 100,000
Starting events: 500,000
Events after warm-up and runs: 504,184
Database after all runs: 82.1 MB
Indexed account read + latest event: 70%
Regional grouped aggregate: 20%
Transactional update + event insert: 10%

Connections and pooling

Eight persistent connections observed

The application used eight independent PHP workers. Each worker reused one persistent PDO connection, producing a measured peak of 8 database connections while 32 HTTP clients were active.

No external connection pooler was installed. This is process-local connection reuse and should not be treated as evidence for PgBouncer, queueing behavior, or a larger worker fleet.

CPU, memory, and I/O

Combined application and database process observations

Median peak CPU

9.68%

of 28 logical processors

Median peak working set

762.04 MiB

PostgreSQL + PHP

Median read transfers

0.00 MiB

per warm-cache run

Median write transfers

6.71 MiB

per measured run

CPU is combined process CPU time divided by total host logical-processor capacity. Memory is combined working set, not private memory. I/O uses Windows process transfer counters, which include cached and non-disk transfers; the zero median read observation is consistent with the disclosed warm-cache setup and is not a claim of zero physical disk reads.

Environment and method

One-host developer baseline

Host

Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz · 14 cores / 28 logical processors · 31.9 GB RAM

Storage

HS-SSD-WAVE(S) 512G · SCSI

Operating system

Microsoft Windows 11 Pro 10.0.22000 build 22000

Software

psql (PostgreSQL) 18.3 · PHP 8.5.7 · Node.js v25.9.0

Database configuration

PostgreSQL shared_buffers=128MB · max_connections=100

Run design

5s warm-up · 5 × 15s measured · concurrency 32 · 8 workers

Raw evidence and reproduction

Inspect every request and rerun the study

The published bundle contains request-level latency and status records, timestamped observer samples, environment metadata, execution logs, the deterministic schema, all runner source, and SHA-256 checksums.

Summary JSON Summary CSV Environment manifest Checksums Reproduction guide PowerShell runner Resource monitor Load generator Aggregation script Evidence verifier Reference app router Reference workload Dataset schema

Per-run request and resource files

Run 1 requests Run 1 resources Run 2 requests Run 2 resources Run 3 requests Run 3 resources Run 4 requests Run 4 resources Run 5 requests Run 5 resources

Limitations

• The PHP built-in server is a development server, not Nginx, Apache, PHP-FPM, Node.js, or a production Core Panel deployment.
• Client, application, and PostgreSQL ran on one host; network latency was nearly absent and load generation competed for the same CPU.
• The deterministic dataset and query mix are synthetic and do not represent every application, schema, index, cache, write ratio, or contention pattern.
• The study measured warm-cache steady state. Cold starts, backups, replication, failover, restores, and concurrent administrative work were excluded.
• Process I/O transfer counters are not physical-device throughput, and PDO persistent connections are not an external connection pool.
• Independent reproduction on a controlled Linux server is still required before these numbers support production sizing or cross-product comparisons.