Can Two Compose Projects Safely Share One Database Container?

Yes, when the database has a stable external network, separate databases and users, explicit lifecycle ownership, and backups independent of either app project.

The decision matters when two self-hosted apps should reuse one PostgreSQL or MariaDB container to save memory. The two competing states are shared service with tenant isolation and coupled upgrades, credentials, restart, and resource contention. Begin with a saved configuration and disposable data, observe one branch at a time, and stop if the test expands data-loss, permission, or availability risk.

Define the Conditions Behind the Shared Database Service Across Compose Projects Decision

Record the environment before changing anything: software and firmware versions, device identities, mount or network path, free space, permissions, and the observable symptom. The baseline must preserve enough detail to reproduce two self-hosted apps should reuse one PostgreSQL or MariaDB container to save memory.

The first candidate is shared service with tenant isolation. The second is coupled upgrades, credentials, restart, and resource contention. The current external Compose networks defines the mechanism or command boundary used in the test; it does not replace observation from this specific home server.

Write the acceptance condition and stop condition before running the discriminator. A pass must change the evidence predicted by one branch while leaving unrelated services unchanged; a fail must return the system to the saved state rather than trigger a chain of speculative fixes.

Test the Claim Without Lowering the Original Requirement

Use this discriminator: connect each project through an external network, create least-privilege users, then stop and update one app while the other runs. Keep workload, client, path, file set, and timing constant so the result is attributable to the changed variable.

Use Compose network lifecycle to select the field that can actually separate the branches, then capture its timestamp, exit status, error text, device or snapshot identity, latency, transferred bytes, permissions, and recovery state. A clean command exit is not enough when identity, durability, or application state is the claim under test.

Repeat the test once after a restart, reconnect, remount, or cold cache when that event is part of the original condition. If the first run is destructive or the environment cannot be restored, stop and reproduce on a disposable copy instead.

networks:
  database-net:
    external: true
# Database lifecycle belongs to a separate infrastructure project

Interpret Pass, Fail, and Exception Results

PASS: each app accesses only its schema or database and one project can redeploy without recreating the shared database. Record the exact version, identity, and workload that passed so the conclusion stays conditional rather than becoming a universal claim.

FAIL: Compose down removes shared state, one user can read another database, or migrations and resource spikes affect both. A fail does not automatically prove the opposite branch when network, memory, permissions, or source consistency can influence both; isolate those shared dependencies before escalating.

EXCEPTION OR AMBIGUOUS RESULT: separate the databases or deploy a dedicated infrastructure Compose project that owns the shared service. Preserve logs and do not run repair, prune, destroy, repartition, or recursive ownership commands until a recoverable copy exists.

-15% OFF

ZimaBoard 2 - Mini Home Server for Your Big Idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Confirm the Decision Under the Original Workload

Apply the action matched to the observed branch, then repeat the original condition rather than a reduced substitute. The decision holds only when each app accesses only its schema or database and one project can redeploy without recreating the shared database across two cycles or the relevant reboot, sleep, interruption, or load transition.

Use the dedicated Docker networks to check the nearest dependent workflow, but keep the original trigger unchanged. Unrelated datasets, shares, containers, users, and recovery points must retain their previous access and timing.

The stop boundary is explicit: if Compose down removes shared state, one user can read another database, or migrations and resource spikes affect both, return to the last verified configuration, retain the evidence, and escalate to a deeper platform or hardware test only when the branch is repeatable.

After the target result holds, compare it with the service restart policies so the fix does not move risk into a neighboring service. A successful target test with a new backup, identity, timeout, or availability failure is still a failed change.

FAQ

For shared database service across Compose projects, the remaining searches usually concern can depends_on manage a database in another project, should both apps share one database user, and who runs database backups and updates. The answers below keep those edge cases separate from the primary decision.

The acceptance boundary does not move: each app accesses only its schema or database and one project can redeploy without recreating the shared database. If a follow-up condition changes the filesystem, identity, network path, or application version, repeat only the discriminator affected by that change.

Stop broadening the experiment when Compose down removes shared state, one user can read another database, or migrations and resource spikes affect both. At that point, separate the databases or deploy a dedicated infrastructure Compose project that owns the shared service; preserve the evidence before escalating to the platform, storage, or hardware owner.

Can depends_on manage a database in another project?

Not directly across independent project models; use health checks and application retry instead.

Should both apps share one database user?

No. Use separate credentials and least-privilege grants for audit and containment.

Who runs database backups and updates?

A dedicated infrastructure owner or project, not whichever application happens to start first.

For shared database service across Compose projects, the practical answer remains conditional: each app accesses only its schema or database and one project can redeploy without recreating the shared database. When Compose down removes shared state, one user can read another database, or migrations and resource spikes affect both, separate the databases or deploy a dedicated infrastructure Compose project that owns the shared service; a partial success that cannot survive the original workload is not compatibility.