NoSQL Databases Guide: MongoDB, Redis, Cassandra, and DynamoDB

"Should we use NoSQL?" is the wrong question. The right question is: "What data access pattern does our application need, and which database serves that pattern best?" NoSQL databases aren't replacements for PostgreSQL or MySQL — they're specialized tools for specific problems. This guide covers the four most important NoSQL databases, when they're the right choice, and when you should stick with SQL.

NoSQL Database Types

MongoDB: Document Database

MongoDB stores data as BSON (binary JSON) documents. Each document can have a different structure — no fixed schema required. This makes it natural for applications where data shapes evolve frequently or vary between records.

// MongoDB — natural document modeling
db.products.insertOne({
  name: "Wireless Headphones Pro",
  brand: "AudioMax",
  price: 149.99,
  specs: {
    driver: "40mm",
    battery: "30 hours",
    anc: true,
    codecs: ["AAC", "LDAC", "aptX HD"]
  },
  reviews: [
    { user: "alice", rating: 5, text: "Best ANC I've tested" },
    { user: "bob", rating: 4, text: "Great sound, bulky case" }
  ],
  tags: ["wireless", "anc", "premium"]
});

// Aggregation pipeline — analytics
db.orders.aggregate([
  { $match: { status: "completed", date: { $gte: ISODate("2026-01-01") } } },
  { $unwind: "$items" },
  { $group: {
    _id: "$items.category",
    totalRevenue: { $sum: "$items.total" },
    avgOrderValue: { $avg: "$items.total" },
    count: { $sum: 1 }
  }},
  { $sort: { totalRevenue: -1 } }
]);

When MongoDB Shines

• Content management: Blog posts, articles, products — each with different attributes and nested content
• Catalogs with variable attributes: Electronics have specs, clothing has sizes/colors, food has nutrition — one collection handles all
• Rapid prototyping: Schema-less means you can iterate on data models without migrations
• Real-time analytics: Aggregation pipeline handles complex analytics queries efficiently

When MongoDB Doesn't Fit

• Complex joins across entities: MongoDB can do lookups ($lookup), but if your data is highly relational, SQL is better
• Multi-document transactions: Supported since 4.0, but they're slower and more limited than SQL transactions
• Strong consistency requirements: MongoDB's default is eventual consistency on replicas

Redis: In-Memory Data Store

Redis keeps all data in memory, making it the fastest database for read/write operations. Sub-millisecond latency, period. It's far more than a simple cache — Redis supports strings, hashes, lists, sets, sorted sets, streams, and even JSON documents.

# Redis — common patterns

# Session storage
SET session:abc123 '{"userId": 42, "role": "admin"}' EX 3600

# Rate limiting (sliding window)
MULTI
ZADD ratelimit:user:42 1709654400 "req:uuid1"
ZREMRANGEBYSCORE ratelimit:user:42 0 1709650800
ZCARD ratelimit:user:42
EXEC

# Leaderboard (sorted set)
ZADD leaderboard 9500 "player:alice"
ZADD leaderboard 8700 "player:bob"
ZREVRANGE leaderboard 0 9 WITHSCORES  # Top 10

# Pub/Sub for real-time
PUBLISH notifications '{"type": "order_shipped", "orderId": "12345"}'

# Redis Streams (event log)
XADD events * type "page_view" url "/products" userId "42"
XREAD COUNT 10 BLOCK 5000 STREAMS events $

Redis Use Cases

See our Redis caching patterns guide for deep implementation patterns including cache-aside, write-through, and cache invalidation strategies.

Cassandra: Wide-Column Store

Apache Cassandra is built for massive write throughput and linear horizontal scaling. It's a masterless architecture — every node can accept reads and writes, no single point of failure. Data is distributed across nodes using consistent hashing.

When Cassandra Excels

• Time-series data: IoT sensor readings, application logs, metrics — Cassandra handles millions of writes per second
• Multi-region deployment: Built-in multi-datacenter replication with tunable consistency
• Write-heavy workloads: Writes are faster than reads by design (append-only storage)
• Massive scale: Netflix runs 10,000+ Cassandra nodes. Apple runs 160,000+

-- Cassandra — design tables around queries, not entities
CREATE TABLE sensor_readings (
    device_id UUID,
    reading_date DATE,
    reading_time TIMESTAMP,
    temperature DOUBLE,
    humidity DOUBLE,
    PRIMARY KEY ((device_id, reading_date), reading_time)
) WITH CLUSTERING ORDER BY (reading_time DESC);

-- Query: last 24 hours for a specific device (very fast)
SELECT * FROM sensor_readings
WHERE device_id = ? AND reading_date = '2026-02-11'
ORDER BY reading_time DESC
LIMIT 100;

-- Query across devices? Requires a different table (denormalization)
CREATE TABLE readings_by_location (
    location TEXT,
    reading_time TIMESTAMP,
    device_id UUID,
    temperature DOUBLE,
    PRIMARY KEY ((location), reading_time, device_id)
);

DynamoDB: Managed NoSQL

Amazon DynamoDB is a fully managed key-value and document database. Zero server management, automatic scaling, single-digit millisecond performance at any scale. The trade-off: you're locked into AWS, and costs can surprise you at scale.

DynamoDB's Sweet Spot

• Serverless applications: Pairs naturally with Lambda, API Gateway, and the AWS ecosystem
• Consistent single-digit-ms latency: Guaranteed performance SLA at any scale
• Auto-scaling: Scales up and down automatically based on traffic patterns
• Global tables: Multi-region active-active replication with no operational overhead

DynamoDB Limitations

• Query flexibility: You can only query on partition key + sort key or secondary indexes. Ad-hoc queries require full table scans
• Cost at scale: On-demand pricing gets expensive with high throughput. Provisioned capacity requires capacity planning
• Item size limit: 400 KB per item. Large documents need to be stored in S3 with a reference in DynamoDB
• Vendor lock-in: DynamoDB is AWS-only. No self-hosted option

Head-to-Head Comparison

When to Stick with SQL

NoSQL is not a universal upgrade from SQL. Most applications are better served by a relational database. Use SQL when:

• Your data is relational: Users have orders, orders have items, items belong to categories — SQL handles this naturally with foreign keys and joins
• You need complex queries: Multi-table joins, subqueries, window functions, GROUP BY with HAVING — SQL is built for this
• ACID transactions matter: Financial data, inventory, booking systems — where partial updates are unacceptable
• You don't know your access patterns yet: SQL's flexible querying lets you adapt without redesigning your schema
• Your data fits on one server: At most scales, a properly tuned PostgreSQL or MySQL with read replicas and Redis caching handles the load

Frequently Asked Questions