Scale signals that determine paradigm fit:
  Row/document count:
    < 10M     → Any paradigm works. Choose the simplest.
    10M–100M  → B-tree index efficiency matters. Postgres still dominant.
    100M–1B   → Partitioning or distributed SQL required for Postgres.
    > 1B      → Distributed paradigm (Cassandra, DynamoDB, CockroachDB) mandatory.

  Write throughput:
    < 10K writes/sec    → Postgres with PgBouncer handles this.
    10K–100K writes/sec → Cassandra or DynamoDB territory.
    > 100K writes/sec   → Distributed NoSQL with horizontal sharding.

  Vector count:
    < 10M  → pgvector (HNSW) handles at < 100ms P99.
    > 10M  → Dedicated vector store required.

Operational ramp estimate for an unfamiliar paradigm:
  Redis:          2–4 weeks (simple mental model, good docs)
  MongoDB:        4–6 weeks (document modeling discipline)
  Elasticsearch:  6–8 weeks (mapping discipline, JVM ops)
  Cassandra:      8–12 weeks (LSM-tree ops, compaction tuning, tombstones)
  CockroachDB:    8–12 weeks (Raft, serialization retries, clock skew)
  Neo4j:          4–6 weeks (Cypher, graph modeling)

1. Users and profiles: OLTP, point reads, strong consistency for auth
   → PostgreSQL (relational, ACID, pgvector for ML features)

2. Tweets and timeline: high-volume writes, fan-out reads, eventual consistency ok
   → Redis (in-memory sorted sets for timeline cache)
   → Cassandra (write-heavy, time-series, wide-row for tweet storage at billions)

3. Search (full-text tweet search): inverted index, relevance ranking
   → Elasticsearch (full-text, BM25 scoring, CDC-synced from Cassandra)

4. Social graph (follow/follower): 3+ hop traversal for recommendations
   → Neo4j (graph DB for follow relationship traversal)
   → OR: Postgres with materialized follower counts if traversal stays ≤ 2 hops

1. Document/chunk storage: structured metadata + raw text
   → PostgreSQL (title, source URL, created_at, chunk_index as typed columns)

2. Vector embeddings: similarity search for retrieval
   → pgvector if < 10M chunks (HNSW index, stays inside Postgres — no new infra)
   → Qdrant if > 10M chunks or hybrid BM25+dense search required

3. Conversation history: session-based, read-heavy, TTL expiry
   → Redis (Hash per conversation, TTL = 24 hours)

4. Usage/billing metadata: OLTP, ACID, FK constraints
   → PostgreSQL (same instance as document store — one Postgres, many purposes)

1. Driver/rider profiles: OLTP, strong consistency
   → PostgreSQL

2. Real-time driver location: high-write, TTL expiry, geospatial lookup
   → Redis Geosearch (GEOADD / GEORADIUS) — sub-millisecond at any scale
   → Fallback: PostGIS for historical trip analysis (not real-time)

3. Trip ledger (billing, receipts): ACID, financial transactions
   → PostgreSQL (serializable isolation, FK constraints, pg_audit for compliance)

4. Surge pricing regions: geospatial, computed in near-real-time
   → Redis (pre-computed per-region surge multiplier, refreshed every 30 seconds)

5. Trip history: append-only, time-range queries, billions of rows
   → Cassandra (time-series, wide-row, TWCS compaction)

// Anti-pattern 1: MongoDB for everything
// Symptom: JOIN-heavy reporting now done in application code with N+1 fetch loops
const orders = await Order.find({})  // fetch all orders
const users = await Promise.all(orders.map(o => User.findById(o.userId)))  // N queries!
// Fix: PostgreSQL — the relational model exists precisely for this access pattern

// Anti-pattern 2: Elasticsearch as a primary database
await elasticsearch.index({ index: 'orders', id: orderId, body: { ... } })
// No ACID. No FK constraints. Index propagation is eventually consistent.
// An order write can appear "committed" to the app but not yet searchable.
// Fix: Postgres as primary → CDC → Elasticsearch for search-only reads

// Anti-pattern 3: Redis as durable store without AOF
await redis.set(`order:${orderId}`, JSON.stringify(order))
// Redis restarts at 3 AM. RDB snapshot from 2 hours ago. 2 hours of orders gone.
// Fix: appendonly yes + appendfsync everysec in redis.conf

// Anti-pattern 4: Distributed SQL for a single-region MVP
// CockroachDB Dedicated, 3-node: $450/month for a service with 100 active users
// Postgres on Supabase: $25/month for the same workload
// Fix: choose the simplest store that survives your 12-month scale projection