Databaseper Service: ownership, not isolation

The myth of a security boundary hides the real cost of shared databases. Two product teams sharing a Postgres instance illustrate how a simple column rename can stall a release, turning a Friday afternoon change into a Monday blockage. When the organization splits into independent teams the diagram stays the same while the datastore remains coupled, creating hidden dependencies that surface long before an outage occurs. Database per Service separates three critical concerns: schema ownership determines who can modify tables and who is called when a migration fails, deployment cadence controls how quickly each team can ship schema changes without a committee, and failure blast radius limits how far a poison migration or lock contention propagates across services. Independence carries a price as cross service queries become pipeline challenges; the single SELECT that once joined orders and inventory now requires an outbox stream, a materialized view, or a saga with compensating steps, all of which add operational complexity compared to a straightforward join. A decision checklist helps teams evaluate whether the distributed-data tax is justified: do different teams own distinct services with separate roadmaps, has a shared migration already blocked a deploy, would a bad migration in one service be acceptable if it took down another service’s tables, and is the reporting workload built on cross service SQL joins that cannot yet be replaced by events or a warehouse. Split when team boundaries and release independence outweigh cross service transaction needs and ad-hoc reporting joins, stay shared when a single product, a unified release train, and relational reporting dominate the workload. Security concerns fade when ownership is explicit rather than implied, as each service controls its own database and no longer relies on a shared perimeter that can be bypassed by a single misconfigured migration. The flowchart below visualizes the contrast between a coupled shared database and a decoupled set of service-specific databases. In a coupled model services such as Orders, Inventory, and Billing all point to a single Postgres instance, while in a decoupled model each service owns its own database, creating clear bounded contexts. Performance may degrade when queries span multiple databases, but this cost is often offset by the ability to scale each service independently and to avoid long running locks that can halt an entire system. Teams can adopt event-driven architectures or materialized views to keep data fresh without sacrificing availability. Operational overhead grows with the number of databases, requiring consistent tooling for schema migrations, backups, and monitoring, yet these tasks can be standardized across services, reducing the risk of human error that often accompanies a monolithic schema. In practice the choice hinges on organizational maturity: start with a shared database when the team and product are unified, then introduce service specific databases as release trains diverge and the cost of coordinated migrations becomes a bottleneck. The key insight is that ownership, not isolation, determines whether a microservice architecture delivers true agility or merely a visual illusion.