git.stella-ops.org/docs/workflow/engine/11-postgres-performance-baseline-2026-03-17.md

PostgreSQL Performance Baseline 2026-03-17

Purpose

This document captures the current PostgreSQL-backed load and performance baseline for the Serdica workflow engine. It is the reference point for later MongoDB backend comparisons and the final three-backend decision pack.

The durable machine-readable companion is 11-postgres-performance-baseline-2026-03-17.json.

Run Metadata

• Date: 2026-03-17
• Test command:
  • integration performance suite filtered to PostgresPerformance
• Suite result:
  • 11/11 tests passed
  • total wall-clock time: 2 m 16 s
• Raw artifact directory:
  • TestResults/workflow-performance/
• PostgreSQL environment:
  • Docker image: postgres:16-alpine
  • database: workflow
  • version: PostgreSQL 16.13
  • backend: durable queue tables plus LISTEN/NOTIFY wake hints

Scenario Summary

Scenario	Tier	Ops	Conc	Duration ms	Throughput/s	Avg ms	P95 ms	Max ms
postgres-signal-roundtrip-capacity-c1	WorkflowPerfCapacity	16	1	3895.54	4.11	3738.08	3762.51	3771.10
postgres-signal-roundtrip-capacity-c4	WorkflowPerfCapacity	64	4	3700.99	17.29	3577.49	3583.70	3584.43
postgres-signal-roundtrip-capacity-c8	WorkflowPerfCapacity	128	8	3853.89	33.21	3713.31	3718.66	3719.34
postgres-signal-roundtrip-capacity-c16	WorkflowPerfCapacity	256	16	4488.07	57.04	4251.48	4287.87	4294.09
postgres-signal-roundtrip-latency-serial	WorkflowPerfLatency	16	1	49290.47	0.32	3079.33	3094.94	3101.71
postgres-bulstrad-quotation-confirm-convert-to-policy-nightly	WorkflowPerfNightly	12	4	3598.64	3.33	3478.52	3500.76	3503.73
postgres-delayed-burst-nightly	WorkflowPerfNightly	48	1	2449.25	19.60	2096.34	2152.50	2157.39
postgres-immediate-burst-nightly	WorkflowPerfNightly	120	1	1711.87	70.10	849.78	1012.13	1030.98
postgres-synthetic-external-resume-nightly	WorkflowPerfNightly	36	8	4162.56	8.65	4026.50	4048.09	4049.91
postgres-bulstrad-quote-or-apl-cancel-smoke	WorkflowPerfSmoke	10	4	166.99	59.88	13.51	23.87	26.35
postgres-delayed-burst-smoke	WorkflowPerfSmoke	12	1	2146.89	5.59	2032.67	2050.20	2051.30
postgres-immediate-burst-smoke	WorkflowPerfSmoke	24	1	341.84	70.21	176.19	197.25	197.91
postgres-signal-roundtrip-soak	WorkflowPerfSoak	108	8	25121.68	4.30	4164.52	4208.42	4209.96
postgres-signal-roundtrip-throughput-parallel	WorkflowPerfThroughput	96	16	3729.17	25.74	3603.54	3635.59	3649.96

Measurement Split

The synthetic signal round-trip workload is measured in three separate ways:

• postgres-signal-roundtrip-latency-serial: one workflow at a time, one signal worker, used as the single-instance latency baseline.
• postgres-signal-roundtrip-throughput-parallel: 96 workflows, 16-way workload concurrency, 8 signal workers, used as the steady-state throughput baseline.
• postgres-signal-roundtrip-capacity-c*: batch-wave capacity ladder used to observe scaling and pressure points.

The useful PostgreSQL baseline is:

• serial latency baseline: 3079.33 ms average end-to-end per workflow
• steady throughput baseline: 25.74 ops/s with 16 workload concurrency and 8 signal workers
• capacity c1: 4.11 ops/s; this is only the smallest batch-wave rung

Serial Latency Baseline

Phase	Avg ms	P95 ms	Max ms
start	6.12	9.29	11.26
signalPublish	5.63	6.82	7.53
signalToCompletion	3073.20	3086.59	3090.44

Interpretation:

• almost all serial latency is in signalToCompletion
• workflow start is very cheap on this backend
• external signal publication is also cheap

Steady Throughput Baseline

Phase	Avg ms	P95 ms	Max ms
start	16.21	40.31	47.02
signalPublish	18.11	23.62	28.41
signalToCompletion	3504.24	3530.38	3531.14

Interpretation:

• the engine sustained 25.74 ops/s in a 96-operation wave
• end-to-end average stayed at 3603.54 ms
• start and signal publication remained small compared to the resume path

PostgreSQL Observations

Dominant Waits

• Client:ClientRead was the top observed wait class in 13/14 scenario artifacts.
• The serial latency scenario had no distinct competing wait class because the measurement ran with effectively no backend concurrency.
• On this local PostgreSQL profile the wake-up path is not the visible bottleneck; the dominant observed state is clients waiting on the next command while the engine completes work in short transactions.

Capacity Ladder

Scenario	Throughput/s	P95 ms	Xact Commits	Buffer Hits	Buffer Reads	Tuples Inserted	Tuples Updated	Tuples Deleted	Top Wait
c1	4.11	3762.51	251	1654	24	48	48	16	Client:ClientRead
c4	17.29	3583.70	1080	7084	1	192	192	64	Client:ClientRead
c8	33.21	3718.66	2348	17069	0	384	384	128	Client:ClientRead
c16	57.04	4287.87	4536	40443	0	768	768	256	Client:ClientRead

Interpretation:

• the capacity ladder scales more smoothly than the Oracle baseline on the same local machine
• c16 is the fastest tested rung and does not yet show a hard cliff
• the next meaningful PostgreSQL characterization step should test above c16 before declaring a saturation boundary

Transport Baselines

Scenario	Throughput/s	Xact Commits	Buffer Hits	Buffer Reads	Tuples Inserted	Tuples Updated	Top Wait
postgres-immediate-burst-nightly	70.10	801	13207	4	570	162	Client:ClientRead
postgres-delayed-burst-nightly	19.60	269	11472	3	498	33	Client:ClientRead

Interpretation:

• immediate transport remains much cheaper than full workflow resume
• delayed transport is still dominated by the intentional delay window, not by raw dequeue speed
• the very short smoke transport runs are useful for end-to-end timing, but they are too brief to rely on as the primary PostgreSQL stat sample

Business Flow Baselines

Scenario	Throughput/s	Avg ms	Xact Commits	Buffer Hits	Buffer Reads	Tuples Inserted	Tuples Updated	Top Wait
postgres-bulstrad-quote-or-apl-cancel-smoke	59.88	13.51	3	93	0	0	0	Client:ClientRead
postgres-bulstrad-quotation-confirm-convert-to-policy-nightly	3.33	3478.52	236	12028	270	546	75	Client:ClientRead

Interpretation:

• the short Bulstrad flow is still mostly transport and orchestration overhead
• the heavier QuotationConfirm -> ConvertToPolicy flow is a better real-workload pressure baseline because it exercises deeper projection and signal traffic

Soak Baseline

postgres-signal-roundtrip-soak completed 108 operations at concurrency 8 with:

• throughput: 4.30 ops/s
• average latency: 4164.52 ms
• P95 latency: 4208.42 ms
• 0 failures
• 0 dead-lettered signals
• 0 runtime conflicts
• 0 stuck instances

PostgreSQL metrics for the soak run:

• xact_commit: 3313
• xact_rollback: 352
• blks_hit: 26548
• blks_read: 269
• tup_inserted: 774
• tup_updated: 339
• tup_deleted: 108
• top wait:
  • Client:ClientRead

What Must Stay Constant For Future Backend Comparisons

When MongoDB is benchmarked and the final Oracle/PostgreSQL/MongoDB comparison is produced, keep these constant:

• same scenario names
• same operation counts
• same concurrency levels
• same worker counts for signal drain
• same synthetic workflow definitions
• same Bulstrad workflow families
• same correctness assertions

Compare these dimensions directly:

• throughput per second
• latency average, P95, P99, and max
• phase latency summaries for start, signal publish, and signal-to-completion on the synthetic signal round-trip workload
• failures, dead letters, runtime conflicts, and stuck instances
• commit count analogs
• row, tuple, or document movement analogs
• read-hit or read-amplification analogs
• dominant waits, locks, or wake-path contention classes

First Sizing Note

On this local PostgreSQL baseline:

• immediate queue burst handling is comfortably above the small workflow tiers; the current nightly transport baseline is 70.10 ops/s
• the separated steady throughput baseline is 25.74 ops/s, ahead of the current Oracle baseline on the same synthetic workflow profile
• the ladder through c16 still looks healthy and does not yet expose a sharp pressure rung
• the dominant observed backend state is client read waiting, which suggests the next tuning conversation should focus on queue claim cadence, notification wake-ups, and transaction shape rather than on an obvious storage stall

This is a baseline, not a production commitment. MongoDB should now reuse the same scenarios and produce the same summary tables before any backend recommendation is declared.