Database-per-Service Pattern

Analogy categoryAnalogies

What Is the Database-per-Service Pattern?

In the database-per-service pattern, every microservice is given its own private data store, and no other service is permitted to read or write that store directly. All access to a service's data goes through the service's own API — typically REST or gRPC calls, or asynchronous events. This is different from a monolith or a poorly decomposed 'distributed monolith', where multiple services share one large relational database and simply divide up tables by convention. The moment two services query the same tables, they become coupled at the schema level: a column rename in one team's migration can silently break another team's queries, even though no code was shared.

🏏

Cricket analogy: Just as each IPL franchise like Mumbai Indians maintains its own scouting database and training records rather than sharing a single league-wide player file, each service keeps its own data so a schema change by Chennai Super Kings' analytics team can't break Mumbai's dashboards.

Why Shared Databases Break Microservices

A shared database undermines the core promise of microservices: independent deployability. If the Orders service and the Inventory service both read and write the same 'products' table, then a schema migration for Orders (say, adding a NOT NULL constraint) can break Inventory's queries even though the two teams never touched each other's code. This also destroys encapsulation of business rules — validation logic meant to live inside a service can be bypassed entirely if another service writes straight to the table. Over time, shared databases become a de facto integration layer that nobody owns, and every schema change requires cross-team coordination meetings, exactly the kind of organizational drag microservices were meant to eliminate.

🏏

Cricket analogy: If both the batting coach and the bowling coach were allowed to edit the same team strategy whiteboard simultaneously, a bowling change scribbled over the batting order could cause chaos on match day without either coach intentionally sabotaging the other.

Implementation Approaches

Database-per-service doesn't strictly require separate physical database servers, though that is the strongest isolation. Three common levels exist: private schema in a shared instance (separate schema/namespace, separate credentials, same physical server), private database in a shared cluster (separate logical database, still managed by one DBA team), and fully private infrastructure (each service's own database engine, possibly a different technology entirely — Postgres for Orders, MongoDB for Catalog, Redis for Sessions). Polyglot persistence, choosing the storage technology that best fits each service's access patterns, is a major benefit: a service doing full-text search might use Elasticsearch while a service needing strict transactional consistency uses PostgreSQL. The tradeoff is operational: more databases means more backup strategies, more monitoring dashboards, and more infrastructure to patch.

🏏

Cricket analogy: A franchise might let the batting and bowling coaches share one training ground (shared instance) but keep separate locker rooms (private schema), while the fitness team runs an entirely separate facility with its own equipment (fully private infrastructure).

yaml

# docker-compose.yml excerpt: each service owns a dedicated database
services:
  orders-service:
    image: myorg/orders-service:1.4.0
    environment:
      DATABASE_URL: postgres://orders_user:pass@orders-db:5432/orders
    depends_on:
      - orders-db

  orders-db:
    image: postgres:16
    environment:
      POSTGRES_DB: orders
      POSTGRES_USER: orders_user

  catalog-service:
    image: myorg/catalog-service:2.1.0
    environment:
      MONGO_URL: mongodb://catalog-db:27017/catalog
    depends_on:
      - catalog-db

  catalog-db:
    image: mongo:7

  # NOTE: orders-service has no network access to catalog-db and
  # vice versa in the compose network policy — enforced isolation,
  # not just convention.

A useful litmus test: if you can point to a single connection string or credential that two different services both use to reach the same schema, you do not yet have database-per-service — you have a distributed monolith wearing microservice clothing.

Cross-Service Queries and Data Duplication

The obvious question is: how do you join data that now lives in different databases? For example, showing an order with the customer's current shipping address and the product's current price requires data from three services. There are three standard answers. First, API composition: the calling service (or an API gateway/BFF) fans out requests to each service and joins the results in application code — simple but adds latency and couples the caller to multiple services' availability. Second, each service maintains a denormalized local copy of the data it needs from other services, kept in sync via events (this is the Command Query Responsibility Segregation-adjacent read-model pattern). Third, a dedicated reporting or analytics database is populated via change-data-capture or ETL specifically for cross-cutting queries, keeping operational databases clean of ad-hoc joins.

🏏

Cricket analogy: A TV broadcast combining live scores from the stadium's official scoreboard, a separate weather feed, and a separate commentary graphics system is like API composition — the broadcast team fans out to three sources and assembles one screen in real time.

Denormalized local copies mean you now have eventually-consistent data by design. A common mistake is assuming these read models are always up to date; you must design UI and business logic to tolerate a short window (often milliseconds to a few seconds) where a locally cached field lags behind the source of truth.

Database-per-service means each microservice exclusively owns its data store; other services never query it directly.
Shared databases recreate tight coupling and break independent deployability, even when the application code itself is split into services.
Isolation can range from a private schema on shared infrastructure to fully separate database engines chosen per service (polyglot persistence).
Cross-service data needs are met via API composition, denormalized local read models kept in sync by events, or a dedicated CDC/ETL reporting store.
The pattern trades query convenience for team autonomy and technology flexibility — expect to write more integration code in exchange.
Denormalized copies introduce eventual consistency; UI and business logic must tolerate brief staleness rather than assuming real-time accuracy.
A quick test for true database-per-service: no two services should ever share the same connection string or credentials to the same schema.