Database Per Service

Assign each service exclusive ownership of its own database schema or instance, prohibiting direct cross-service database access and enforcing data encapsulation at the service boundary.

Shared databases create coupling between services: schema changes cascade across service boundaries, slow queries from one service degrade others, and independent deployment and scaling become impossible when services share a data store.

In a shared-database architecture, multiple services read and write the same tables. Schema changes in one service break others. A slow query from one service degrades database performance for all services. Operational incidents in one service can corrupt data owned by another. Data model coupling prevents services from being deployed or scaled independently.

Database-per-service enforces a hard boundary: each service owns a set of tables (or an entire schema or database instance) that no other service can access via SQL. The only way to read or modify another service's data is via that service's API. This enables independent schema evolution, independent scaling, independent operational failure domains, and independent technology selection (one service uses PostgreSQL, another uses Redis, another uses Cassandra).

The boundary is enforced at multiple levels. At the network level: database credentials are service-specific; no service has credentials for another service's database. At the schema level: tables are prefixed or namespaced per service; global database users do not have cross-service grants. At the process level: shared ORM models or shared schema migration tools are a code smell that signals boundary violation.

The fundamental operational consequence is that queries requiring data from multiple services cannot be expressed as SQL JOINs. They require one of: (1) API composition : the calling service fetches from each service's API and joins in memory; (2) event-driven denormalisation: downstream services subscribe to upstream events and maintain their own read-optimised copies of relevant data; (3) a dedicated reporting store that aggregates data from multiple services for analytical queries.

Cross-service ACID transactions are impossible without a distributed transaction protocol. The Saga pattern is the standard substitute, accepting eventual consistency at the business transaction level.