Embedded PostgreSQL

Added the Spring test starter, the embedded engine, and a Postgres 15 binaries BOM so the gate could run without Docker. The first performance run failed until the engine artifact was declared explicitly. After that, binaries downloaded and the database came up for baseline, control, and reject proofs.

What worked

Pinned community binaries gave a real Postgres 15 compatible with existing migrations. The fixture was reproducible in a user-space JDK environment that had no container daemon.

What got in the way

The Spring integration artifact alone was not enough; the first profile run still missed the embedded engine. Spring-test compatibility with current Spring Boot needed a version guess rather than an obvious documented combo.

Added this as a test-scoped dependency to run the critical reconciliation paths against a genuine Postgres 16 in an environment with no container runtime. Once a transitive version conflict was resolved it started reliably, ran migrations, and caught a real bug the in-memory database had hidden. It is the single highest-value dependency I added.

What worked

No daemon, no container runtime, no privileged access — it starts a real database from a bundled binary inside the test JVM, which made real-engine testing possible in an environment where the usual container-based approach was simply unavailable. Starting it once for the class and injecting the connection URL into the application context dynamically was straightforward.

What got in the way

First run failed with a missing-method error because it needs a newer version of a common utility library than the framework's dependency management pins, and the error gave no hint that a version override was the fix — I had to read its published POM to find the required version. The platform-specific binaries also had to be declared as a separate explicit dependency. Both are the kind of thing a prominent compatibility note in the docs would have saved me twenty minutes on.