Under what circumstances might a team deliberately choose NOT to fully split a database per service, or to relax strict data ownership boundaries, and what risk are they accepting by doing so?

## When the pattern actually pays Database-per-service is a tool aimed at a specific problem — letting different teams, or services with different scaling, reliability, or technology needs, evolve independently without coordinating on a shared schema — and like any tool, it pays for itself only when that problem is actually present. Its benefits, independent deployment, freedom to pick storage technology per service, fault isolation between services' data layers, materialize specifically when services are owned by different teams with different release cadences, or genuinely need different scaling profiles or storage engines. When those conditions aren't yet true, the pattern's real costs, operating and monitoring many databases instead of one, losing the ability to join or transact across services, and having to build and reason about eventual consistency for any cross-service view, can outweigh benefits that haven't kicked in yet. ## Three situations that justify relaxing the rule Three situations commonly justify deliberately relaxing the rule. 1. **The first is a small team** running a handful of logically-separate services that are, in practice, still one team's concern and deploy together or nearly together; splitting the database here adds distributed-systems overhead, network calls, eventual consistency, more infrastructure to run, to solve a coordination problem that doesn't yet exist, since there's no second team to coordinate with. This is the reasoning behind starting with a **modular monolith**, separate modules with disciplined internal boundaries sharing one deployable and often one schema, and splitting out services later once real organizational or scaling pressure appears. 2. **The second is a shared, explicitly read-only reporting or analytics database**, fed by CDC or ETL from each service's own database, used purely for dashboards and offline analysis; because nothing treats it as a live source of truth for runtime decisions and no service writes through it, it doesn't reintroduce the coupling the rule exists to prevent. 3. **The third is an early product stage** where the domain's real boundaries are still being discovered — locking in a hard database split along boundaries that turn out to be wrong is often more expensive to undo later than temporarily sharing a schema with disciplined access rules, since re-merging split databases and migrating their consumers back is a much bigger project than tightening access to an already-shared one. ## The trade-off runs both ways The trade-off of relaxing the boundary runs in both directions. | Direction | What it holds | |---|---| | What you gain | less operational overhead for a small team, the ability to run ad hoc joins and reports easily, lower cognitive load while the system and domain model are both still small and changing quickly, and avoiding real distributed-systems complexity, network partitions, message ordering, eventual-consistency bugs, before the system actually needs to pay for it | | What you risk | the exact coupling problem the pattern exists to prevent creeps back in gradually | Convenient direct queries become de facto contracts that nobody wrote down; the longer a shared schema lives, the more application code accumulates around it, so the eventual split gets harder, not easier, the longer it's deferred. ## How it goes wrong in practice The way this goes wrong in practice usually isn't a single bad decision but an accumulation: - a temporary shared table used by two services stays around because it always works, until the day both teams deploy conflicting schema migrations against it in the same week and cause an outage neither expected; - or a read-only analytics replica, originally meant only for dashboards, quietly becomes a dependency for a live feature when someone decides it's basically the same data and queries it for a real-time decision, silently recreating the integration-database problem through a side door; - or a team simply waits too long: by the time they actually need to split out a service for real scaling or ownership reasons, hundreds of queries across the codebase touch the shared tables directly, and the eventual migration needs a multi-phase project, temporary dual writes, backfills, contract tests, instead of a clean cutover. ## A pattern that keeps the later split cheap A concrete pattern that avoids most of this: a three-person startup runs Orders, Users, and Payments as separate deployable processes sharing one database instance and schema in year one, deliberately, because splitting into three managed databases isn't worth the overhead yet and the domain boundaries are still shifting weekly, but they enforce one rule throughout: **no process queries or writes another process's tables directly**, only in-process function calls that mirror what a future API would look like. A year later, when a second team is hired specifically to own Payments, partly for compliance-driven isolation, extracting Payments into its own service and database is mostly an infrastructure migration, because the application-level coupling that would have made it painful was never allowed to form in the first place.