Relational databases store data in tables with rows and columns. Relationships are enforced with foreign keys. You query with SQL (SELECT, JOIN, GROUP BY). ACID transactions guarantee consistency. Examples: PostgreSQL, MySQL, SQL Server. Best for: structured data, complex queries, reporting, and when consistency and relationships matter.

Strong schema: you define columns and types; the DB enforces them. Migrations manage schema changes over time.

Document databases (e.g. MongoDB, Couchbase) store documents (often JSON/BSON). Each document can have a different shape; schema is flexible or enforced by the application. You query by field, index, or aggregation pipeline. No JOINs across collections; you denormalize or embed related data.

Good for: catalogs, content, profiles, and when the schema evolves often or differs per record. Weaker transactional guarantees across documents (multi-document transactions exist but are a later addition).

Key-value stores (e.g. Redis, DynamoDB in key-value mode) map a key to a value. The value can be a string, hash, list, or set (Redis) or a blob. Lookup by key is O(1). No queries by value; you use it for caching, sessions, rate limiting, or when you always have the key.

Redis is in-memory and very fast; often used as a cache or for real-time structures (leaderboards, pub/sub). DynamoDB is durable and scalable; good for high-throughput key access.

Wide-column (e.g. Cassandra, HBase) store data in column families; each row can have many columns and rows are identified by a row key. Optimized for write throughput and horizontal scaling; query by row key or key range. No JOINs; you model for access patterns (e.g. time-series, events by partition key).

Use when: huge scale, write-heavy, and you can design the key structure for your reads. Learning curve is steeper than SQL.

Start with relational for most apps: it handles CRUD, reporting, and transactions well. Add Redis (or similar) for caching and sessions. Consider document when schema is fluid or you need horizontal scale without complex JOINs. Consider wide-column or key-value when scale and access patterns are very specific. You can use multiple stores in one system (e.g. PostgreSQL for source of truth, Redis for cache).