Polyglot Persistence — Multiple Databases, One System

Polyglot persistence is the practice of using multiple, specialized databases in one application — each store chosen because it is the best tool for a specific workload. Your relational DB holds orders; Redis holds sessions; Elasticsearch serves search; S3 holds images. One DB no longer tries to do everything, so each workload gets the engine that was designed exactly for it.

Let's walk through a story that mirrors what dozens of real engineering teams have lived. You have an e-commerce application. You started with Postgres — good choice. It stores your products, orders, users, inventory. Everything works. Traffic grows. And then, one by one, the cracks appear.

Four Cracks That Appear Over Time

Crack 1 — Search gets slow. Your product catalog grows to 500,000 items. Users type "blue running shoes size 10" and wait 2.3 seconds while Postgres scans a B-tree index that was not designed for natural language. You could add tsvector columns and tune pg_trgm — or you could add Elasticsearch, which pre-builds an inverted index on every word and returns results in under 50 ms. Postgres is a brilliant relational store. It is a mediocre full-text search engine.

Crack 2 — Sessions dominate DB connections. Each HTTP request for a logged-in user hits Postgres to look up their session token and permissions. At 50,000 concurrent users, that's 50,000 reads per second on your primary for data that almost never changes during a session. Redis stores every session in RAM and serves it in under 1 ms. Moving sessions off Postgres doesn't just speed up session reads — it frees your Postgres connections for the queries that actually need a relational store.

Crack 3 — Product images and video grow to terabytes. Storing binary blobs in Postgres balloons your database size, slows backups, and doesn't give you a CDN. S3 (or any object store) was purpose-built for massive binary objects: it's cheap, infinitely scalable, and integrates with CDNs natively. Postgres stores the metadata (filename, size, upload date, owner) — S3 stores the bytes.

Crack 4 — "Customers also bought" requires graph traversal. You want to recommend products: if User A bought items X, Y, Z, and User B bought X, Y — suggest Z to B. This is a graph problem: nodes are users and products, edges are purchase relationships. A SQL query to find second-degree connections across millions of relationships requires expensive self-joins and gets slower as the graph grows. A graph database like Neo4j traverses those relationships natively, in milliseconds, because its storage model IS the graph.

Here is the mental model that makes polyglot persistence click: think of your data layer as a professional toolbox, not a single Swiss Army knife. Every tool in the box was designed for a specific job. A hammer drives nails. A screwdriver turns screws. You don't use a hammer on a screw just because you already have one in your hand.

Applied to databases: a relational store is a hammer for structured, transactional data with relationships. It is not a hammer for 500 ms substring searches across a free-text field. Redis is a hammer for in-memory, expiry-based key lookups. Pointing Redis at your transaction ledger is the wrong hammer. The key insight is that a workload pattern exists before the store does — you identify the access pattern first, then pick the store that was engineered for it.

Four Design Heuristics to Keep in Mind

These four rules prevent the most common mistakes teams make when going polyglot:

Polyglot persistence has its own vocabulary. You'll see these six terms in every architecture discussion, every design review, and every incident postmortem involving multiple data stores. Learn them as concepts with meaning, not just jargon to recite.

Real-world polyglot architectures are not invented from scratch. Most apps use one or more of six well-established store combinations, each built around a specific workload pair. Understanding these patterns means you won't reinvent the wheel — you'll recognize which one fits your situation and know the sync mechanisms, failure modes, and consistency trade-offs that come with it.

Polyglot persistence is a solution to a real problem — but it is not the default starting point. The honest truth is: a well-tuned Postgres instance handles the majority of production workloads at the scale most applications ever reach. Adding a second store should feel like a last resort after you've exhausted single-store optimizations, not a first move because the architecture diagram looks cleaner with five boxes.

Here are five signals that tell you to stop and stay with one store — at least for now.

Imagine your Postgres database is a busy kitchen. Every order that comes in, every item updated, every row deleted — these changes are recorded in a private journal called the Write-Ahead Log (WAL). Now imagine a tool that reads that journal automatically and whispers "row changed" to anyone who cares — Elasticsearch, ClickHouse, a cache. That tool is Change Data Capture (CDC).

The magic of CDC is what it avoids: your application code never writes to two stores. It writes to Postgres once. CDC reads the WAL and fans the change out to every derived store. If a secondary store goes down, CDC replays from where it left off when it recovers — no data lost, no manual reconciliation.

The Four CDC Patterns

The idea feels obvious: your app writes a product update to Postgres, then immediately writes the same update to Elasticsearch so search stays current. Two lines of code. Done. The problem is that two independent writes can never be atomic — and distributed systems fail in every possible partial way.

Every team that has shipped dual-write has eventually seen a user complain "I just updated my address but the confirmation email still shows the old one." That's dual-write failure. The report came in hours or days later because the inconsistency was silent.

The Four Failure Modes

The mitigation: instead of writing to two stores, write to one store and an "I changed something" note — in the same transaction — and let something else read that note and update the other stores. This is called the outbox pattern: a business row plus an event row, committed atomically. CDC picks up the event and fans it to derived stores. The event log provides ordering. Replays are idempotent. Failures retry without duplication.

If dual-write breaks because "write to two things" is inherently unsafe, the clean solution is to write to exactly one thing — an event log — and let everything else derive from it. Think of it like a diary: you write every change down once, in order, and anyone who wants to know the current state replays the diary entries. This is event-driven architecture applied to persistence: the event log is the source of truth; every other store is a materialized view built by replaying events.

Think of it like accounting. A company's ledger records every transaction as an immutable event. The "current balance" is not stored — it's computed by summing all events. If you need a balance by category, you build a new view of the same ledger. The ledger never changes. Only the views do.

The Four Core Components

When someone says "the data should be consistent," the right follow-up question is: consistent for whom, between which stores, and within what time window? With a single database, the database engine handles consistency. With multiple stores, you have to define consistency per store, per operation, and per user experience requirement.

There is no easy way to make every store agree on every write at the exact same instant — not without a heavyweight coordinator that locks every store until everyone confirms. That coordinator is called two-phase commit (2PC), and most teams reject it because it blocks under failure and destroys throughput. Instead, you pick a consistency level per operation and design the user experience around that choice.

Four Consistency Levels in Practice

Adding a new database to your stack feels straightforward on paper: run a Docker container locally, wire up the client library, ship. But every store you run in production comes with a recurring operational tax — not a one-time setup cost, but an ongoing burden your team pays indefinitely.

The honest accounting: each new store multiplies your monitoring surfaces, on-call runbooks, backup complexity, and the expertise your engineers need to carry. A team of 5 running 5 database technologies is not 5x as capable as a team running 1 — it is more fragile, because each engineer needs to be at least partially competent in 5 entirely different systems.

The Five Operational Dimensions

The rule is simple: every store you add must earn its operational burden through a measurable, quantified benefit. "Redis would be nice to have" is not justification. "Our Postgres read latency averages 340 ms on the /products endpoint, Redis brings it to under 5 ms, and that endpoint is called 40,000 times per minute" is justification.

If you can't complete the sentence "we need X because Y is 10× worse without it," the store is not yet justified. Measure first. Add the store second. Validate the improvement. Resist the pull of tech excitement over engineering discipline.

Six Stores and When They're Justified

The best way to make polyglot persistence concrete is to walk through a real system you already understand: an online store. You've bought something on Amazon or a similar site. Under the hood, your single "add to cart" click touches at least four different database technologies — each one chosen because it is the best possible tool for that exact piece of work.

Here is the cast of characters in a typical e-commerce polyglot stack and the plain-English reason each one is there:

• Postgres — stores orders, users, inventory, and payment records. This is structured relational data with ACID requirements. If your order record says "paid" but your inventory record wasn't decremented, you have a financial bug. Relational transactions prevent exactly that.
• Redis — stores active shopping carts and user sessions entirely in RAM. Why RAM? Because a cart read happens on every page load for every logged-in user. At 100,000 concurrent users that's 100,000 reads per second. Redis returns a cart in under 1 ms; Postgres under typical load takes 5–20 ms. More importantly, moving this load off Postgres frees your primary database for queries that actually need durable, relational storage.
• Elasticsearch — serves product search. The moment a user types "blue running shoes size 10", that query needs an inverted index with relevance scoring, fuzzy matching, and filters on multiple attributes simultaneously. Postgres can do basic full-text search, but Elasticsearch was designed from day one to do nothing else — it returns results in under 50 ms for hundreds of millions of documents.
• S3 / object storage — stores product images and video. Binary blobs don't belong in a relational database: they bloat backups, don't compress efficiently in row storage, and can't be served via CDN. S3-compatible stores cost pennies per GB and connect natively to global CDN networks.
• Kafka — the event bus. When a user places an order, that one action triggers: inventory decrement, email confirmation, loyalty points update, analytics event, fraud check, warehouse notification. Kafka lets the order service fire one event and walk away; every downstream service subscribes independently. This is how you decouple a dozen teams without building a tangled web of synchronous HTTP calls.
• Neo4j (optional) — powers "customers also bought" recommendations. Purchase relationships form a graph. Finding second-degree connections ("users who bought what you bought also bought X") is a graph traversal — a native operation for Neo4j, an expensive multi-join query for Postgres.

Trade-off Table — Each Store at a Glance

Every store in the stack has a primary job, a specific sync mechanism, and a clear failure mode you must plan for. The table below is your quick reference:

Code — Three Key Schema Patterns

The code below shows how each major store models its slice of the data. Notice how the shape of data in each store matches the access patterns that store is best at — Postgres uses normalized relational tables with foreign keys, Redis uses a flat hash keyed by user ID, and Elasticsearch uses a denormalized document with every searchable field embedded inline.

-- Source of truth: users and orders live here.
-- Postgres handles ACID guarantees for financial records.

CREATE TABLE users (
  id          UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  email       TEXT UNIQUE NOT NULL,
  created_at  TIMESTAMPTZ DEFAULT now()
);

CREATE TABLE orders (
  id          UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id     UUID REFERENCES users(id) NOT NULL,
  status      TEXT NOT NULL DEFAULT 'pending',  -- pending | paid | shipped | cancelled
  total_cents INT  NOT NULL,
  created_at  TIMESTAMPTZ DEFAULT now()
);

CREATE TABLE order_items (
  id          UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  order_id    UUID REFERENCES orders(id) NOT NULL,
  product_id  UUID NOT NULL,       -- product details live in a products table
  quantity    INT  NOT NULL CHECK (quantity > 0),
  unit_price_cents INT NOT NULL
);

-- Index for the common query: "show me all orders for user X, newest first"
CREATE INDEX idx_orders_user_created ON orders(user_id, created_at DESC);

import redis

r = redis.Redis(host="redis", port=6379, decode_responses=True)

CART_TTL_SECONDS = 7 * 24 * 3600   # 7 days — abandoned carts expire automatically

def add_to_cart(user_id: str, product_id: str, quantity: int = 1):
    """Add (or increment) a product in the user's cart."""
    key = f"cart:{user_id}"
    # HINCRBY is atomic — safe even if two requests arrive simultaneously
    r.hincrby(key, product_id, quantity)
    r.expire(key, CART_TTL_SECONDS)   # reset TTL on every activity

def get_cart(user_id: str) -> dict:
    """Returns {product_id: quantity} for every item in the cart."""
    return r.hgetall(f"cart:{user_id}")   # returns {} if cart doesn't exist

def remove_from_cart(user_id: str, product_id: str):
    """Remove a product entirely from the cart."""
    r.hdel(f"cart:{user_id}", product_id)

def clear_cart(user_id: str):
    """Called after checkout — wipe the cart."""
    r.delete(f"cart:{user_id}")

# Example usage:
# add_to_cart("user-123", "product-abc", 2)
# get_cart("user-123")  → {"product-abc": "2"}
# Cart key in Redis: "cart:user-123" → hash: {"product-abc": "2"}

// Elasticsearch index mapping for product search.
// All fields a user might filter or search on are embedded in ONE document.
// This is intentionally denormalized — that's the Elasticsearch way.

PUT /products
{
  "mappings": {
    "properties": {
      "id":          { "type": "keyword" },
      "name":        { "type": "text",    "analyzer": "english" },
      "description": { "type": "text",    "analyzer": "english" },
      "brand":       { "type": "keyword" },
      "category":    { "type": "keyword" },
      "price_cents": { "type": "integer" },
      "in_stock":    { "type": "boolean" },
      "tags":        { "type": "keyword" },
      "attributes": {
        "type": "nested",
        "properties": {
          "name":  { "type": "keyword" },
          "value": { "type": "keyword" }
        }
      },
      "updated_at":  { "type": "date" }
    }
  }
}

// A product document — notice all data is self-contained:
{
  "id":          "product-abc",
  "name":        "Blue Running Shoes",
  "description": "Lightweight mesh upper for long-distance comfort",
  "brand":       "Nike",
  "category":    "Footwear",
  "price_cents": 8999,
  "in_stock":    true,
  "tags":        ["running", "blue", "mesh"],
  "attributes":  [
    { "name": "size",  "value": "10" },
    { "name": "color", "value": "blue" }
  ],
  "updated_at":  "2025-09-01T12:00:00Z"
}

// How the sync happens: a Kafka consumer listens for product_updated events
// from Postgres (via Debezium CDC) and upserts the Elasticsearch document.
// Lag is typically under 5 seconds — acceptable for product catalog changes.

Video streaming is one of the most data-intensive use cases on the planet. When 200 million subscribers open Netflix simultaneously, the system must serve personalized recommendations, resume each user's exact playback position, deliver gigabytes of video bytes per second, and capture every viewing event for analytics — all in real time. No single database was built to do all four of those things. The result is one of the most complex polyglot persistence stacks in production.

Here is the architectural layer breakdown and the specific store each layer uses:

• Content layer — S3 / distributed object storage: Raw video files, encoding artifacts, and subtitle files live here. A single movie at multiple quality levels (4K, 1080p, 720p) can be tens of gigabytes. This data is write-once, read-many-times, and purely binary — a perfect match for object storage.
• Delivery layer — CDN: Video bytes are not served from S3 directly to users — that would be impossibly slow across continents. The CDN copies video segments to edge servers close to each user. This is not really a "database" but it is a critical persistence layer: bits cached at the edge are bits not fetched from origin.
• Metadata layer — Cassandra: Viewing history ("you watched 47 minutes of this title on Tuesday") and user watch lists are large, write-heavy datasets. Cassandra's design makes write throughput extremely high and scales horizontally by adding nodes. The trade-off is that Cassandra doesn't support complex joins — but viewing history doesn't need joins, just fast single-user reads and writes.
• Search — Elasticsearch: When a user searches for "action movies with strong female leads", that query needs full-text search, genre filters, and relevance ranking. Same story as e-commerce — Elasticsearch's inverted index handles this in milliseconds across millions of titles.
• Real-time state — Redis: The playback resume position ("you are at 1:23:45 in this film") must be readable in under 5 ms because it's fetched on every play button press. Redis stores this as a simple key-value pair keyed by {user_id}:{title_id} and returns it instantly.
• Event stream — Kafka: Every play event, pause event, seek event, and completion event is published to Kafka. Downstream services consume these events: the recommendation engine trains on them, the analytics platform aggregates them, the business intelligence team queries them via Druid or ClickHouse.
• Analytics — Druid / ClickHouse: These are OLAP stores designed for fast analytical queries: "how many users in Germany watched more than 3 hours yesterday?" Columnar storage means scanning one column across billions of rows is cheap. This query would be painfully slow in Cassandra or Postgres.

Social networks push polyglot persistence to its absolute limits. Think about what happens every second on a platform like Twitter or Instagram: millions of users are reading their timelines, thousands are posting new content, the system is computing who to notify for each new post, and search must return relevant results across billions of posts in real time. None of these workloads share the same data access pattern — so none of them share the same store.

Here is how the major stores map to social features:

• Sharded MySQL or Cassandra — core user data, posts, follower relationships. The choice between them depends on scale. MySQL can be sharded (split across many servers) and is familiar. Cassandra offers linear horizontal scale with higher write throughput — at Twitter or Instagram scale, write throughput is the bottleneck that forces this decision.
• Redis — pre-computed timelines and hot data. When you open Twitter and your timeline loads in 300 ms, that speed is almost certainly coming from Redis. The timeline was computed in advance and cached — reading a single Redis key is faster than re-running a complex fan-out query on every open.
• Elasticsearch — search across posts and users. Searching "news about Ukraine" across billions of posts requires an inverted index with recency ranking. Elasticsearch handles this; a traditional database cannot.
• Graph DB (TigerGraph, Neo4j) — friend graphs and recommendations. Who follows whom, who you might know, mutual friends — these are graph traversals. Some platforms build custom graph storage rather than using an off-the-shelf graph DB, but the concept is the same: edges are first-class data.
• Object storage (S3) — photos, videos, audio. Same story as e-commerce — binary blobs go to object storage, metadata goes to the relational or wide-column store.
• Kafka — the real-time distribution bus. When you post a tweet, Kafka distributes that event to every follower's notification service, the timeline fan-out service, the search indexer, the analytics pipeline, and the ML recommendation system — all independently and asynchronously.
• CDN — media delivery to users globally. Object storage is the origin; CDN is the global distribution network that ensures a photo loads in milliseconds whether the viewer is in Tokyo or São Paulo.

Four Core Patterns in Social Networks

Social platforms evolved four specific data patterns that are now well-understood in the industry. Each pattern solves a different performance challenge that a single relational store cannot solve alone:

AI applications — and specifically RAG (Retrieval-Augmented Generation) systems — introduced a new member to the polyglot family: the vector store. A vector store doesn't index words or values — it indexes embeddings, which are numerical representations of meaning. When you ask "what are our Q3 refund policies?", a RAG system finds documents that are semantically similar to your question — not documents that contain those exact words.

Here is what the stack looks like for a modern AI application:

• Postgres (+ pgvector extension) — application data AND embeddings in one place. The pgvector extension adds a vector column type to Postgres and supports approximate nearest-neighbor search. For many AI apps this is the sweet spot: you already run Postgres, adding vectors requires no new infrastructure, and moderate-scale similarity search (millions of documents) is fast enough. The moment you need billions of vectors or sub-10ms search at scale, you graduate to a dedicated vector store.
• Vector DB (Pinecone, Qdrant) — dedicated vector search at scale. These stores are built specifically for approximate nearest-neighbor search across billions of high-dimensional vectors. They are specialized tools — don't add them until pgvector's performance is the bottleneck you've actually measured.
• Object storage (S3) — raw documents. PDFs, Word files, scraped web pages — the original source documents before they are chunked and embedded. These are stored in S3 cheaply and referenced by metadata in Postgres.
• Redis — LLM response cache. LLM API calls are expensive (dollars per thousand requests) and slow (1–5 seconds). If two users ask the same question, the second answer can be served from Redis in milliseconds for a fraction of a cent. This is a classic cache pattern applied to AI calls.
• Kafka — the document ingestion pipeline. New documents arrive continuously (new support tickets, new product docs, new contracts). Kafka queues each document for the ingestion pipeline: chunking → embedding → upsert to vector store. This decouples arrival from processing so spikes in document uploads don't block user queries.
• Observability stack (Prometheus + Grafana or similar) — tracks LLM latency, cache hit rate, embedding freshness, and retrieval quality metrics. AI systems degrade silently when embeddings become stale or the LLM context window fills with irrelevant chunks — observability catches this before users notice.

Polyglot persistence and microservices were almost designed for each other. The microservices philosophy says: break your application into small, independently deployable services, each owned by a dedicated team. If you take that philosophy seriously, the next logical step is database-per-service: each service owns its own database schema, and no other service is allowed to query it directly.

This sounds radical at first. In a traditional monolith, it's completely normal for one SQL query to join the orders table, the users table, and the products table — three different domains, one query. In a microservices world, the order service, user service, and product service each own their data, and joining across them requires calling multiple services over the network. Why would you accept that complexity? Because the alternative — sharing one database across many services — creates a subtle but catastrophic coupling:

• The order team can't change the orders table schema without coordinating with every other team that queries it
• The users team can't upgrade their database version without potentially breaking the order service
• A slow query from the analytics team can lock rows and slow down real-time order processing
• One service's bad migration can corrupt another service's data

Database-per-service eliminates this coupling at the cost of making cross-service data operations harder.

Four Key Implications of Database-Per-Service

Almost nobody designs a polyglot architecture from scratch and builds it all at once. The real story is almost always incremental: you start with Postgres, you hit a specific bottleneck you can measure, you add the right tool to solve exactly that bottleneck, you validate it works, and then you move on to the next pain point. This is the disciplined, safe way to grow a polyglot stack. The big-bang approach — "let's redesign the entire data layer this quarter" — is how teams end up with half-implemented migrations, production incidents, and regret.

The evolution typically follows a predictable order, and there are good reasons why each step comes before the next:

Four Migration Patterns — Add One Store at a Time

Once you have decided to use multiple stores, the next question is practical: how do you actually keep them synchronized, move data between them, and observe the whole thing in production? You do not build this plumbing from scratch. There is a small, well-established toolkit that most polyglot architectures share. Think of these six tools as Lego pieces: each one does one job extremely well, and they snap together to form a reliable pipeline from your source database all the way to your analytics warehouse and your observability dashboards.

// POST http://localhost:8083/connectors
{
  "name": "orders-postgres-connector",
  "config": {
    "connector.class": "io.debezium.connector.postgresql.PostgresConnector",
    // Tell Debezium where to connect
    "database.hostname": "db.internal",
    "database.port": "5432",
    "database.user": "debezium_user",
    "database.password": "${file:/etc/secrets/db.properties:password}",
    "database.dbname": "shop",

    // Replication slot name — Postgres uses this to track WAL position
    // WHY: the slot ensures Postgres keeps WAL history until Debezium has consumed it
    "slot.name": "debezium_shop_slot",

    // Publication name — only tables in this publication are captured
    // WHY: limits Debezium's WAL reads to just the tables you care about
    "publication.name": "debezium_shop_pub",

    // Which tables to capture (regex: schema.table)
    "table.include.list": "public.orders,public.order_items,public.products",

    // Topic naming: each table gets its own Kafka topic
    // e.g. shop.public.orders
    "topic.prefix": "shop",

    // Include the full row before the change (not just after)
    // WHY: downstream consumers often need to know what changed, not just the new value
    "before.handling.mode": "schema_only"
  }
}

from confluent_kafka import Consumer
from elasticsearch import Elasticsearch
import json

# Connect to Kafka and Elasticsearch
consumer = Consumer({
    "bootstrap.servers": "kafka:9092",
    "group.id": "elasticsearch-sync-group",
    # Start from earliest unread message in this consumer group
    # WHY: if the indexer restarts, it resumes from where it left off
    "auto.offset.reset": "earliest",
})
es = Elasticsearch("http://elasticsearch:9200")

# Subscribe to the orders topic published by Debezium
consumer.subscribe(["shop.public.orders"])

while True:
    msg = consumer.poll(timeout=1.0)
    if msg is None or msg.error():
        continue

    event = json.loads(msg.value())
    op = event["payload"]["op"]   # "c" = insert, "u" = update, "d" = delete
    after = event["payload"].get("after")
    before = event["payload"].get("before")

    if op in ("c", "u") and after:
        # Upsert the order into the search index
        # WHY: we use the Postgres row ID as the ES document ID so updates are idempotent
        es.index(
            index="orders",
            id=after["id"],
            document={
                "order_id":     after["id"],
                "customer_id":  after["customer_id"],
                "status":       after["status"],
                "total_cents":  after["total_cents"],
                "created_at":   after["created_at"],
            }
        )
    elif op == "d" and before:
        # Delete removed orders from the search index
        es.delete(index="orders", id=before["id"], ignore=[404])

import psycopg2, json, uuid

def place_order(conn, customer_id: int, items: list) -> int:
    """
    Write order + outbox event in a single transaction.
    WHY: a transaction is atomic — either both writes succeed or neither does.
    No separate Kafka write = no chance of order written without event published.
    """
    with conn.cursor() as cur:
        # 1. Insert the actual business record
        cur.execute(
            "INSERT INTO orders (customer_id, status) VALUES (%s, 'pending') RETURNING id",
            (customer_id,)
        )
        order_id = cur.fetchone()[0]

        # 2. Write an outbox row in the SAME transaction
        # Debezium captures this row via CDC and publishes it to Kafka
        cur.execute(
            """INSERT INTO outbox_events
                 (aggregate_type, aggregate_id, event_type, payload)
               VALUES (%s, %s, %s, %s)""",
            (
                "Order",                          # which entity type
                str(order_id),                    # which specific entity
                "OrderPlaced",                    # event name
                json.dumps({                      # event data
                    "order_id": order_id,
                    "customer_id": customer_id,
                    "items": items,
                })
            )
        )

    conn.commit()   # both writes committed atomically
    return order_id

# Debezium config tip: use io.debezium.transforms.outbox.EventRouter
# to route outbox rows to the right Kafka topic by aggregate_type

Polyglot persistence gets misunderstood in both directions: some teams avoid it too strongly ("we'll never need multiple databases") and some adopt it too eagerly ("every microservice needs its own store"). Neither extreme is right. Below are the six most common myths that lead teams into bad decisions — each one contains a grain of truth that makes it believable, which is exactly why it keeps spreading.

The following incidents are composites of real patterns documented in engineering post-mortems, conference talks, and public failure analyses. They are anonymized and generalized, but every failure mode described here has been lived by real teams. They are presented not to scare you away from polyglot persistence, but to make these failure modes visceral enough that you remember them at the moment when you are considering adding a fifth store or implementing your first dual-write.

These eight rules are distilled from the incident patterns above and the architectural principles throughout this page. They are the right defaults for most teams. Violating any one requires a deliberate, documented reason — not inertia, not cargo-culting a blog post, and not "it seemed simpler at the time."

These questions come up in every system design interview, every architecture thread, and every team that has just discovered the term "polyglot persistence." Each answer is written to give you a defensible, honest position — not a vague "it depends," and not a textbook definition that helps no one in practice.

Polyglot persistence does not exist in isolation — it is the intersection of database internals, distributed systems coordination, caching theory, and operational engineering. The six topics below give you the full supporting context. Each one sharpens the decision framework from this page: you will understand not just when to use polyglot, but why the trade-offs exist at the physics level.