NoSQL Options: MongoDB, Redis, DynamoDB

NoSQL encompasses several database paradigms, each solving different problems. MongoDB stores documents. Redis stores key-value pairs. DynamoDB is AWS's managed NoSQL service. Understanding when each makes sense prevents costly wrong choices.

MongoDB: The Document Store

MongoDB stores JSON-like documents in collections. No schema enforcement by default. Documents in the same collection can have completely different structures. This flexibility appeals to developers building rapidly-iterating features.

MongoDB has improved significantly. Recent versions support transactions across documents. Aggregation pipelines enable complex queries. With schema validation, you can enforce structure optionally. MongoDB is a mature, production-ready database.

The use case: applications where documents truly vary in structure, or where you want to avoid migration overhead. In practice, most applications discover they need structure anyway—adding validation after the fact is possible but awkward.

Redis: The In-Memory Store

Redis is not a primary database. It's a high-speed cache and data structure store. It lives in RAM, providing sub-millisecond latency. Data is ephemeral—it doesn't survive restarts unless persisted.

Use Redis for: caching frequently-accessed data, session storage, job queues, rate limiting, pub-sub messaging, leaderboards, real-time counters. Any use case where you need fast, ephemeral data.

A typical architecture: PostgreSQL holds all data. Redis caches hot data. Cache misses query PostgreSQL and update the cache. Writes go directly to PostgreSQL and invalidate the cache. This combination is standard for performant systems.

DynamoDB: AWS's Managed NoSQL

DynamoDB is AWS's answer to NoSQL. It scales horizontally automatically. You define access patterns upfront—the queries you'll make. DynamoDB optimizes for those patterns.

DynamoDB pricing is complex. You pay for read/write capacity (recently changed to pay-per-request). If you don't understand your access patterns or underestimate capacity, costs explode. DynamoDB is excellent for specific access patterns like gaming leaderboards or time-series data, but wrong for general-purpose applications.

Downsides: limited querying (you can't do arbitrary JOINs), pricing complexity, vendor lock-in to AWS. For most applications, PostgreSQL is simpler and cheaper.

When Each Makes Sense

MongoDB: document-heavy data where structure genuinely varies. More commonly, use PostgreSQL's JSONB. MongoDB adds operational complexity for little benefit in most cases.

Redis: caching, sessions, queues, real-time counters. Indispensable for performance-critical systems. Always pair with a primary database.

DynamoDB: AWS-native applications with known, simple access patterns. Time-series data at scale. For other use cases, PostgreSQL is likely better.

The MongoDB vs PostgreSQL Myth

"Use MongoDB for flexibility" is outdated. PostgreSQL with JSONB provides document flexibility with SQL query power. You get the best of both. MongoDB is more complex operationally (sharding, replication, monitoring) for unclear benefits.

If you think you need MongoDB for flexibility, try PostgreSQL with JSONB first. Odds are you'll find it sufficient.

Search Databases

For full-text search at scale, PostgreSQL's built-in search isn't sufficient. Elasticsearch and Meilisearch are purpose-built for search. They handle typos, synonyms, ranking, and faceted search elegantly.

A typical setup: PostgreSQL holds the canonical data. Elasticsearch mirrors the data for search. Writes go to PostgreSQL and are re-indexed in Elasticsearch. Search queries hit Elasticsearch. This approach gives you the benefits of both.

Operational Complexity

PostgreSQL is simpler operationally than MongoDB or DynamoDB. Managed PostgreSQL (Supabase, RDS) abstracts most complexity. MongoDB and DynamoDB have their own operational burdens and require expertise to use well.

For startups and most projects, simpler is better. PostgreSQL is simpler. Choose it unless you have a specific reason not to.