Testcontainers and Reuse

A large multi-module Java build was suffering from Testcontainers scaling problems: each module runs tests in its own JVM and jdbc:tc: URLs cause Testcontainers to start a full Postgres container per JVM, so a 40-module project spawns dozens of containers in parallel and Docker Desktop hits resource limits, causing Flyway connection failures. Enabling Testcontainers' reuse (jdbc:tc:... ?TC_REUSABLE=true) avoids creating many containers but breaks test isolation: modules have different migration sets and many tests assume a fresh database, so a shared database produces Flyway validation errors, stray rows, duplicate keys and invalid test results.

The solution is to reuse one Postgres server process while giving each test JVM its own ephemeral database inside that container. A Spring EnvironmentPostProcessor replaces jdbc:tc: URLs with a real JDBC URL to a per-JVM database created on first use by a SharedTestDatabase helper. That helper starts a reusable PostgreSQLContainer (with a file lock to prevent races), configures max_connections and fsync=off, creates a database named with the JVM pid+UUID, registers a shutdown hook to drop it, and has logic to drop stale test_ databases whose owner pids are gone. Reuse still requires opt-in on the developer machine (~/.testcontainers.properties), so CI and non-opted-in environments keep the previous one-container-per-JVM behavior while avoiding Docker overload and preserving test isolation locally.