Should each service have its own database instance or share one?

As a general design goal, give each application or service its own database and credentials. Separate databases prevent accidental access and reduce the chance that a destructive migration or corrupted index in one service will directly affect another. Running multiple logical databases in one PostgreSQL instance usually adds very little overhead, so this is often a good compromise. If services need common data, consider exposing it through an API or deliberately replicating the required data rather than having every service share tables.

The practical answer depends on the environment and workload. For local development, one PostgreSQL container and perhaps one user is simple and resource-efficient. For a lower-cost production setup, use one PostgreSQL instance with a separate database and user for each service. If stronger failure isolation, independent scaling, or different backup and upgrade schedules matter, move to a separate instance per service. Keep production databases on a private container network rather than publishing them publicly; for local development, bind ports only to localhost.

Avoid treating “one database per service” as an absolute requirement. A separate logical database and restricted account can provide good security boundaries while keeping infrastructure affordable. Separate database servers become worthwhile when services have heavy or unpredictable workloads, require different PostgreSQL versions or settings, need independent availability, or must be restored and scaled independently. SQLite can work for some small, single-process applications, but it is not a universal replacement for PostgreSQL in multi-service systems.

A useful rule is to isolate by application stack: each stack can have its own database container and be started, upgraded, backed up, or removed without touching unrelated services. Using the same database image still allows container layers to be shared, so the disk cost is usually modest. The trade-off is additional memory and operational work for every running database.