Database Fundamentals

A database is two jobs glued together: store data durably, and find it again quickly. Most of the topics here exist to make the second job fast without breaking the first. When you write a row, the database has to put it somewhere on disk, keep enough structure around it to find it later, and make sure a crash mid-write does not corrupt anything. When you read, it has to locate the rows you asked for among millions of others without scanning all of them.

The lessons start with the building blocks you touch every day. Database Indexing and B-Trees explain how a query finds 3 rows out of 50 million in milliseconds instead of reading the whole table. Database Normalization and Database Denormalization cover how you shape tables: splitting data to avoid duplication and update bugs, or deliberately duplicating it to make reads faster. Query Optimization teaches you to read the plan the database produces and understand why it chose a scan over an index.

From there the category moves into the parts of a database that hold logic and reduce repeated work: Database Views, Materialized Views, Database Functions, Stored Procedures, and Database Triggers. A view is a saved query you can treat like a table. A materialized view stores the result so you do not recompute it on every read. Triggers and stored procedures push logic into the database itself, which is powerful and also a common source of hidden behavior, so the lessons cover both the use and the cost.

One database server can only do so much. When read traffic outgrows a single machine, Read Replicas are the first move: copies that serve queries while writes still go to the primary. Database Replication explains the general mechanism, and Master-Slave Replication versus Master-Master Replication covers the two main shapes. Master-slave (one writer, many readers) is simpler and the default for most systems. Master-master lets multiple nodes accept writes, which buys availability but forces you to handle write conflicts, so reach for it only when you genuinely need it.

When the data itself is too big for one machine, you split it. Table Partitioning breaks one logical table into smaller physical pieces. Vertical Partitioning splits by columns, putting rarely-used or large columns in a separate store. Horizontal Partitioning splits by rows, and the lessons cover the strategies for choosing which rows go where: Range Partitioning (by value ranges, like dates), Hash Partitioning (by a hash for even spread), List Partitioning (by explicit categories, like region), and Composite Partitioning (combining strategies). The choice determines whether your queries hit one partition or all of them.

Database Sharding takes partitioning across separate servers and is the heaviest scaling tool here. It can take you to billions of rows, but it complicates everything: cross-shard queries, joins, transactions, and rebalancing all get harder. The lessons are honest that sharding is a last resort after indexing, replicas, and partitioning have been exhausted. Connection management matters too, which is why Database Connection Pooling is covered: opening a fresh connection per request is one of the quietest ways to overload an otherwise healthy database.