Why does having multiple 'microservices' read and write the same shared database (or even the same tables) recreate the coupling problems of a monolith?

## The rule a shared schema breaks In a properly decomposed microservices system, each service exclusively owns its own data store, following the **'database-per-service'** pattern: other services never touch that data directly with SQL, they only ask for it through the owning service's published API or consume events it publishes. When teams instead point several services at one shared schema — very common when a service is extracted from an existing monolith's database without splitting the data — the schema itself becomes a **de facto integration contract**. Any DDL change is consumed by every service holding a connection string to that database, not just the team that considers itself the 'owner': - adding a `NOT NULL` constraint - renaming a column - changing a foreign key - dropping an index another service silently relied on for performance ## Why teams end up here This usually happens for understandable reasons: extracting a service's code into its own deployable is technically easier and faster than also splitting its data, especially when the new service still needs joins or transactional consistency with data 'owned' by other parts of the system. Keeping one database avoids the harder distributed-data problems — cross-service joins, referential integrity, multi-service transactions — in the short term, so teams under delivery pressure ship the code split and defer the data split, sometimes indefinitely. ## The trade-off The trade-off is real on both sides. A single shared database gives you **cheap consistency**: real ACID transactions and joins across what are nominally separate services, without touching sagas or eventual consistency. The cost is what you lose: - **independent deployability** — any schema migration needs review and coordination from everyone touching that table - **failure isolation**, since connection-pool exhaustion or lock contention from one service's heavy query can starve an unrelated service sharing the same database instance - **the ability to reason about dependencies**, because no compiler or contract enforces the schema as an API; breakage is discovered in production or by a job quietly failing against a renamed column ## Production failure modes Production failure modes recur in a few characteristic shapes. 1. **One:** Service A runs a schema migration (an `ALTER TABLE` that takes a lock) and Service B's completely unrelated queries start timing out or the shared connection pool saturates, causing an outage for a service that made no code change that day. 2. **Two:** Service B silently depends on the semantics of a column 'owned' by Service A; A's team cleans up dead code, drops the column, and B breaks in production with no compile-time warning. 3. **Three:** an old, half-forgotten batch job in Service C does a nightly bulk update against tables it doesn't 'own,' and nobody on-call for A or B even knows that dependency exists until anomalous data changes show up. ## The remediation pattern The remediation pattern — **'database-per-service,'** catalogued as one of the foundational microservices data patterns — is to: 1. identify the true **bounded-context owner** of each table; 2. migrate write access so only that owner can write (temporarily via a compatibility API if needed); 3. replace other services' direct SQL reads with either synchronous calls to the owner's API or an **event-driven local read model** (a CQRS-style materialized projection kept current by consuming the owner's domain events); 4. and only then physically split the schema or database once no cross-service SQL remains. A concrete worked example: extracting an 'Orders' service from a monolith and giving it exclusive ownership of the `orders` table, while an 'Inventory' service that used to run a direct SQL `JOIN` against `orders.order_id` now instead calls the Orders API for what it needs, or maintains its own local copy of the relevant fields kept up to date by consuming an `OrderPlaced` event — removing the shared-schema coupling while preserving the functionality both services need.