Microservices Database
Database-per-service is the microservices data-isolation pattern canonically documented by Chris Richardson at microservices.io and in his book Microservices Patterns (Manning, 2018; 2nd edition MEAP underway). Three implementations exist: private-tables-per-service (lowest overhead, weakest isolation), schema-per-service (private schema on a shared server, per Richardson's FTGO reference app on a shared MySQL instance), and database-server-per-service (full isolation, highest operational cost). Cross-service joins and ACID transactions are banned, so teams add Saga (choreography or orchestration), CQRS materialized views, or API composition to keep data consistent. Uber ran roughly 4,500 microservices across three monorepos per a 2022 count (reported by InfoQ, 2024). Maintained by No single owner — canonically documented by Chris Richardson (microservices.io, author of Microservices Patterns, Manning 2018); independently adopted by Netflix, Uber, and Amazon in production.
Pick database-per-service when services have genuinely independent lifecycles and your team can stomach eventual consistency — greenfield microservices, polyglot persistence needs, teams that own their schema end-to-end. Skip it for a small team shipping a first product with tangled read patterns; a modular monolith with one shared database gets you 90 percent of the boundary discipline without the operational tax. Richardson's own pattern docs admit implementing cross-service business transactions this way "is not straightforward" — sagas trade ACID for compensating transactions, CQRS trades simplicity for replication lag. Uber's ~4,500-service sprawl needed a dedicated Domain-Oriented Microservice Architecture just to keep dependencies sane; the pattern doesn't prevent sprawl, it just isolates the blast radius. Known weakness: Cross-service business transactions can't use ACID and require Saga or CQRS instead, which the pattern's own reference documentation admits "is not straightforward" to implement correctly.