In a microservices architecture, why does each service typically own and manage its own database rather than multiple services sharing one database?

## What the rule actually requires **Database-per-service** means that each microservice is the exclusive owner of the data it needs to do its job: - it has its own schema (and often its own database instance or cluster); - it runs the migrations for that schema; - it is the only piece of code in the system allowed to write to those tables. Other services never open a connection to that database and never run SQL against it directly. If Service A needs data that Service B owns, A has exactly two legitimate paths: 1. call an API that B exposes, or 2. subscribe to events that B publishes when its data changes. ## Physical or purely logical The isolation can be physical or purely logical — what makes the pattern real is the access rule, not the hardware topology. | Shape | What it looks like | |---|---| | Physical | a separate database server or managed instance per service | | Purely logical | separate schemas and database users within one shared instance, with no cross-schema grants | A three-service startup running all three schemas on one Postgres instance with per-service roles and zero cross-schema queries is following the pattern just as much as a large company running fifty separate database clusters. ## Why the rule exists The reason this rule exists is that a shared database, used by multiple services as their integration mechanism, silently reintroduces every coupling problem microservices are meant to remove. This is sometimes called the **'integration database' anti-pattern**: when two services both read and write the same tables, each one is implicitly depending on the other's internal representation of its data — column names, types, foreign keys, even row-level invariants that only make sense from inside the owning service's business logic. That dependency isn't visible in any interface or contract; it's just there in a query somewhere. A schema change that looks perfectly safe from inside the owning team's context (renaming a column, splitting a table, adding a `NOT NULL` constraint) becomes a cross-team incident because some other service was quietly relying on the old shape. Database-per-service forces that dependency to surface as an explicit, versioned interface — an API endpoint or an event schema — that the owning team can evolve deliberately and the consuming team can adapt to on their own schedule. ## The trade-off The trade-off is real and shouldn't be hand-waved away. On the benefit side: - each service can deploy independently without coordinating schema migrations with anyone else; - it can choose the storage technology that actually fits its access pattern (a relational store for an orders ledger, a document store for a flexible catalog, a graph store for a recommendation engine); - failures in one service's database don't directly corrupt or lock another's. On the cost side: - you lose the ability to run a single SQL join across two services' data; - you lose the ability to wrap a change to two services' data in one local ACID transaction; - you now operate and monitor N databases instead of one; - any cross-service view of the data has to be built and kept consistent asynchronously, which means living with eventual consistency instead of always-fresh reads. ## How it fails in production In production, this rule fails in a specific, recurring way: someone finds it inconvenient. A report is due, a dashboard needs a number, a service needs 'just one more field' from another service's table, and instead of waiting for an API to be built, an engineer opens a read-only connection straight into the other service's production schema. It works, right up until the owning team refactors that table during an unrelated change and breaks a consumer they didn't know existed and never agreed to support. The same failure shows up in more subtle forms: - a **'read replica'** of another service's database that starts as a reporting convenience and slowly becomes a load-bearing dependency for live decisions; - a service that avoids direct SQL but instead makes a synchronous API call to another service inside a loop for every item in a list — not a database coupling anymore, but it recreates the same availability coupling under a different name, a **'distributed monolith'** where every service's uptime depends on every other service it talks to. ## Putting it together A concrete illustration: in an order-management system, an Order service should never run a query against the Inventory service's stock table to check availability. Instead it calls Inventory's `checkAvailability` API (or, for less time-critical checks, consumes an event stream Inventory publishes about stock levels). When the Inventory team later decides to split their single stock table into a 'reserved' and 'available' quantity for a new feature, that's an internal detail; the Order service's contract (the API or event shape) doesn't have to change, and Order keeps working without anyone from that team needing to notify or coordinate with the Order team at all — which is the entire point of owning your own data.