Polyglot Persistence: Using the Right Database for Each Job

Uber's Database Zoo: 4 Databases, 1 Ride

When you request an Uber ride, at least four databases are involved, a real-world example of polyglot persistence in action. MySQL stores your account and payment info (ACID transactions). Redis matches you with the nearest driver in real time (sub-millisecond geospatial queries). Cassandra logs your ride history across millions of rows (write-heavy time series). Elasticsearch powers the search for addresses and places. Each database was chosen because it does one thing better than any alternative.

Database Selection Matrix

Which Database for Which Job?

  Data Type         Best DB           Why Not PostgreSQL?
  ───────────────   ──────────────    ──────────────────────────────
  Users, orders,    PostgreSQL        (This IS PostgreSQL's job)
  payments                            ACID, joins, complex queries

  Sessions, carts,  Redis             PG: ~1ms. Redis: ~0.1ms.
  rate limits                         10x faster for simple K/V

  Full-text search  Elasticsearch     PG full-text: OK for simple.
  with ranking                        ES: relevance scoring, facets,
                                      typo tolerance, 100x faster

  Time-series       Cassandra/        PG: single-node write limit.
  (10M users x 5yr) TimescaleDB       Cassandra: 100K writes/sec,
                                      linear scale across nodes

  Graphs (fraud,    Neo4j             PG: 6-table JOIN for 3-hop
  recommendations)                    query. Neo4j: single traversal

  Binary blobs      S3/GCS            PG: 1GB max per row, expensive
  (images, PDFs)                      S3: unlimited, $0.023/GB/mo

Data Synchronization Architecture

Cross-Database Data Flow:

  [PostgreSQL]  --- CDC (Debezium) ---> [Kafka]
  Source of truth                        |
  for users, orders                 +----+----+----+
                                    |    |    |    |
                              [Redis] [ES]  [Cass] [S3]
                              Cache   Search History Backup

  Pattern: PostgreSQL is the source of truth.
  Changes stream via CDC to other databases.

  Consistency model:
  - PG writes are strongly consistent
  - Other DBs are eventually consistent (lag: 100ms-5s)
  - This is acceptable because:
    - Search results can be 1s stale
    - Cache can be invalidated on next miss
    - History can lag by seconds

When NOT to Go Polyglot

Decision Framework:

  Q: Can PostgreSQL handle it?
  |
  YES -> Use PostgreSQL. Stop.
  |
  NO -> Q: Is the pain severe enough to justify ops cost?
        |
        YES -> Add specialized DB + CDC pipeline
        |
        NO -> Optimize PostgreSQL first (indexes, partitioning)

  Common mistake: adding Redis 'for performance' when a
  PostgreSQL index would have been enough.

  Rule of thumb: 1 DB until 10K users.
  2-3 DBs at 100K users. 4+ only at millions.

Interview Tip

When asked 'what database would you use?' in system design, say: 'I would start with PostgreSQL as the source of truth for transactional data. As the system scales, I would add Redis for caching and rate limiting, Elasticsearch for search, and S3 for binary storage. Data flows from PostgreSQL to other stores via CDC (Debezium to Kafka). Each store is eventually consistent with PG as the authoritative source. I would only add a database when PostgreSQL cannot handle a specific access pattern efficiently.'

<

Architecture overview

/blockquote>

Key Takeaway

Polyglot persistence picks the best database for each specific need rather than forcing all data into one system. The result is better performance, better developer experience, and lower total cost. The trade-off is operational complexity and the need for explicit data synchronization between systems.

Related reading

• Paxos Made Simple

• Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services (The CAP Theorem)