CF
Databases thumbnail

Databases

114 courses 6 categories

Part of Learn Data & AI

Databases are the persistent layer underneath every serious application. This topic spans the breadth of database technology rather than any one product: relational engines (PostgreSQL, MySQL, SQL Server, Oracle), document stores (MongoDB, Couchbase), key-value stores and caches (Redis, DynamoDB, Memcached), search engines (Elasticsearch, OpenSearch, Meilisearch), column-oriented analytical warehouses (ClickHouse, BigQuery, Snowflake, DuckDB), and the messaging/streaming layer (Kafka, RabbitMQ, NATS, Pulsar) that sits next to them in modern architectures.

The 2026 picture has consolidated. PostgreSQL is the default for new projects unless there is a hard reason to pick something else — its JSONB, partitioning, logical replication, and growing extension ecosystem (pgvector, TimescaleDB, Citus) cover most workloads a startup will ever hit. Redis owns the cache and queue tier. MongoDB still dominates document workloads where schema flexibility matters more than joins. ClickHouse and DuckDB have eaten a large share of analytical work that used to require a full data warehouse. Vector databases moved from a separate category to a feature: pgvector, Qdrant, and Pinecone all coexist depending on scale.

What you'll find under this topic

  • Relational fundamentals: normalization, indexes, transactions, query plans
  • PostgreSQL deep dives: extensions, JSONB, partitioning, logical replication
  • MongoDB and document modeling: schema design, aggregation pipeline, change streams
  • Redis: data structures, persistence, Streams, pub/sub, Sentinel and Cluster
  • Elasticsearch and search: inverted indexes, analyzers, relevance tuning
  • Messaging and streaming: Kafka, RabbitMQ, NATS, exactly-once semantics
  • Operational concerns: backups, point-in-time recovery, sharding, failover

Roles hiring against this topic span database administrators at banks and telecoms, data engineers at any SaaS company moving toward an analytical warehouse, backend engineers who need to outgrow the ORM, and platform teams running self-hosted Postgres or Kafka fleets in production.

Top 10 picks for 2026

Categories (6)

Databases thumbnail
Databases
Databases is the foundational layer underneath every persistent application. The category here covers the breadth of…
Elasticsearch thumbnail
Elasticsearch
Elasticsearch is a distributed, RESTful search and analytics engine capable of tackling real-time data. Developed by…
Messaging & Streaming thumbnail
Messaging & Streaming
Messaging & Streaming is the backbone of asynchronous communication between services, enabling scalable and reliable…
MongoDB thumbnail
MongoDB
MongoDB — NoSQL Document-Oriented Database MongoDB is a source-available, cross-platform document-oriented database…
Redis thumbnail
Redis
Redis is an open-source, in-memory data structure store, used as a database, cache, and message broker. Developed by…
Sql thumbnail
Sql
SQL (Structured Query Language) is the lingua franca of databases. It was standardized in 1986 and has stayed…

Courses (114)

Showing 1 – 30 of 114 courses

Related topics

Frequently asked questions

Which database should I learn first?
PostgreSQL — it's the default mature RDBMS, runs on every cloud, has the strongest feature set (JSON, full-text, pgvector, partitioning, robust transactions), and the SQL skills transfer to MySQL or any other relational engine. Pick up Redis next for caching and queues, then DynamoDB or another wide-column store once you've hit real-world scaling problems.
SQL vs NoSQL — which to pick for a new project?
SQL by default, NoSQL when you have a specific shape of problem that maps cleanly to it. Postgres handles JSON, search, geospatial, and time-series well enough for most teams; reaching for DynamoDB, MongoDB, or Cassandra makes sense once access patterns are predictable, write volume is huge, or horizontal scale is a hard requirement.
How important are indexes really?
Critical. The difference between a system that scales and one that collapses at modest traffic is almost always whether the team understands indexes — composite indexes, covering indexes, when an index is ignored, and how to read EXPLAIN output. Most slow queries in production come from a missing or wrong index, not a fundamentally bad design.
Do ORMs prevent me from needing to learn SQL?
No, and treating them that way is the most common cause of production slowness. ORMs save typing for simple queries but hide what's actually running. Plan on learning enough SQL to read EXPLAIN, write the tricky reporting queries by hand, and recognise N+1 patterns. The ORM is a convenience layer, not a substitute.
What about vector databases for AI?
pgvector inside Postgres is the lowest-friction option and covers most production needs through millions of vectors. Dedicated stores (Qdrant, Weaviate, Pinecone, Milvus) make sense when you outgrow that scale, need hybrid retrieval features out of the box, or want operationally managed services. Embeddings, chunking strategy, and reranking matter more than the storage choice.