Polyglot Persistence and Trade-offs

The Database-Per-Service Pattern gives each microservice ownership of its own data. Once services have independent databases, an interesting opportunity emerges: different services can choose different database technologies based on their specific requirements.

For example, an Order Service might use PostgreSQL to manage transactions, a Product Catalog Service might use MongoDB to store flexible product documents, and a Search Service might use Elasticsearch to support full-text searches. This approach is called Polyglot Persistence.

The idea sounds straightforward, but it introduces important architectural decisions. Different databases have different consistency guarantees, query capabilities, scaling characteristics, and operational requirements.

Choosing the right database can improve performance and scalability. Choosing too many databases, however, can make an already complex microservices architecture even harder to operate. Let's understand how polyglot persistence works, when it makes sense, and how to evaluate its trade-offs.