Databases
229 bites tagged Databases — interview questions with model answers, and 60-second explainers.
Database Pages: The Building Blocks of Your Data
A database page is the fundamental 8KB block for all storage. The database engine reads and writes entire pages, not single rows, for user data, indexes, and metadata. The key footgun: the physical order of rows on a page is not guaranteed.
Storage Engine: The Database's Filing System
A database's storage engine is its specialized filing system, handling how data is physically written to and read from disk. Different engines optimize for different tasks, from fast writes to complex queries.
Predicate Pushdown: Filter Data at the Source
Predicate pushdown tells the database to filter data at the source, not after fetching it. This speeds up queries in data warehouses and lakehouses by reducing network traffic. The main footgun: not all data sources can execute all types of filters.
Composite Indexes: One Index for Multiple Columns
A composite index is like a phone book sorted by last name, then first name. It's for queries filtering on multiple columns, like finding a specific person. The footgun is creating separate indexes, which is far less efficient than a single composite one.
Row Mode vs. Batch Mode Execution in SQL Server
Row mode processes data one row at a time, like a checklist. Batch mode processes chunks of rows together for vectorized speed. Row mode is classic for OLTP, while batch mode shines in data warehousing for large scans.
B-Tree: The Workhorse of Database Indexes
A B-tree is a self-balancing tree that keeps data sorted for fast lookups, generalizing a binary search tree by allowing nodes to have many children. It enables searches, insertions, and deletions in logarithmic time, making it ideal for large datasets.
Serializable Snapshot Isolation: True Serializability Without Heavy Locking
SSI upgrades Snapshot Isolation to true serializability. It optimistically lets transactions run, but aborts one if a dangerous read-write dependency arises. This prevents subtle data corruption in systems like PostgreSQL without heavy locking.
Write Skew: The Phantom Anomaly of Snapshot Isolation
Write skew is when two transactions read the same data, make decisions, and then update *different* data, violating a business rule. It's common in booking systems or when enforcing multi-row constraints under Snapshot Isolation.
Snapshot Isolation: A 'Photo' of Your Database
Snapshot Isolation gives a transaction a private 'photo' of the database from when it started, ensuring consistent reads. It's used in high-concurrency systems to prevent readers from blocking writers. The footgun is that it doesn't prevent all anomalies.
MVCC: Read and Write Data Without Blocking Each Other
MVCC avoids slow, traditional locks by giving each transaction its own consistent data snapshot. This allows readers and writers to work at the same time without blocking each other, boosting performance in databases like PostgreSQL.
Two-Phase Locking (2PL): Preventing Database Race Conditions
2PL is a database's pessimistic strategy for safe concurrency. A transaction acquires all necessary locks before releasing any, ensuring operations don't clash. It's used to guarantee consistency.
Shared & Exclusive Locks: The Read vs. Write Rule
A Shared (S) lock is like many people reading a library book at once; an Exclusive (X) lock is one person writing in it alone. Databases use S/X locks to manage concurrency, preventing writes from corrupting reads.
Database Transaction Log: Your System's Safety Net
A transaction log is your database's safety journal. Before changing data, it records the intended action in a durable file. This is vital for crash recovery, ensuring data isn't left corrupt. The footgun: its primary role is integrity, not just auditing.
Materialized Views: Pre-computing Slow Queries
A materialized view trades data freshness for query speed by storing the result of a slow query as a physical table. It's ideal for dashboards that run heavy aggregations, making them load instantly. The footgun is stale data: users see old results.
Denormalization: Trading Write Speed for Faster Reads
Denormalization speeds up database reads by intentionally adding redundant data, trading write-speed for read-performance. Use it for read-heavy systems like reporting dashboards where joins are too slow.
Surrogate Keys: Stable IDs for Unstable Data
A surrogate key is a meaningless, system-generated ID that never changes, unlike a 'natural' key (like an email) which can. Use it for stable joins between tables. The footgun is exposing these internal IDs in public URLs, which leaks data structure.
Junction Table: Connecting Many to Many
A junction table is a bridge between two other tables, enabling a many-to-many relationship. It's used to connect students to classes or tags to articles. The common footgun is forgetting a unique constraint, allowing duplicate connections.
First Normal Form (1NF): No Nested Data
First Normal Form (1NF) means every table cell holds one single value, not a list. It's the first rule of relational databases, stopping you from storing comma-separated strings. The footgun is stuffing multiple values into one field, which breaks SQL queries.
Codd's 12 Rules: The Relational Database Litmus Test
Codd's 12 Rules are a litmus test for whether a database is truly "relational." They demand that all data and operations be managed purely through the relational model, not through lower-level system access.
Relational Algebra: The Math Behind SQL Queries
Relational algebra is the formal logic behind SQL, treating tables as mathematical sets. It provides a grammar for operations like joins and filters, allowing a database to translate your declarative query into a precise, optimizable execution plan.
Database Views: A Saved Query That Acts Like a Table
A database view is a saved query you interact with like a real table. It simplifies complex joins for applications or restricts data access for security, showing only specific rows or columns.
Database Index: The Phonebook for Your Data
An index is like a book's index, letting you jump to the right row without scanning the whole table. It's essential for columns used in WHERE clauses, but over-indexing slows writes since every index must be updated on data changes.
Foreign Keys: The Glue of Relational Databases
A foreign key is a pointer from one table to another, linking related data like a user to their posts. It enforces referential integrity, ensuring a post can't exist without a valid user. The footgun is forgetting this blocks deletions of referenced records.
Database Normalization: Tidy Tables, Less Redundancy
Database normalization organizes data into smaller, related tables to eliminate redundancy, like separating addresses from orders. It's the standard for transactional (OLTP) systems where data integrity is critical.
Get Databases bites daily.
Five a day, five minutes, offline. With quizzes so it sticks.
Open testing — you’ll join as an early tester.