More in Databases & Architecture — page 12
Fact Table: The Numbers in Your Data Warehouse
A fact table is the ledger of business events, recording what happened and how much. It's the core of a data warehouse, holding sales figures or page views. The footgun is storing descriptive text here; that belongs in linked dimension tables.
CRDTs: Syncing Data Without Locks or Conflicts
CRDTs are data structures where updates can be applied in any order and reach the same state, avoiding locks. They enable offline editing in collaborative apps and distributed databases.
Vector Databases: Searching by Meaning, Not Keywords
A vector database finds "what's most like this?" instead of "find me exactly this." It organizes data by semantic meaning, not just exact values, making it ideal for recommendation engines, semantic search, or finding similar images.
Polyglot Persistence: Use the Right Database for the Job
Polyglot persistence means using multiple, specialized data stores in one system. Instead of one database handling everything, you might use a relational DB for transactions, a document DB for profiles, and a graph DB for connections.
BASE: Trading Consistency for Availability
BASE is a database design philosophy that prioritizes availability over strict consistency, the opposite of ACID. It's used in large-scale systems like social media where uptime is key and slightly stale data is okay.
Time Series Database: A Logbook, Not a Filing Cabinet
A Time Series Database (TSDB) is a specialized logbook for data that happens over time, like server metrics or sensor readings. It's built for high-speed writes and fast range queries. The footgun: don't use it for relational data like user profiles.
Database Sharding: Splitting Data for Scale
Sharding splits a database across multiple servers, like dividing a phone book into A-M and N-Z volumes. It's used when a single server can't handle the data size or write load. The footgun is that querying across shards is complex and slow.
Graph Databases: When Relationships Are the Data
A graph database treats connections between data as first-class citizens. It's ideal for social networks or fraud detection where you query relationships by traversing links. The footgun is using it for simple tabular data where a relational DB is faster.
Wide-Column Store: Flexible Schema for Massive Datasets
A wide-column store is like a spreadsheet where each row can have its own unique columns. It's ideal for sparse data like user profiles or IoT readings. The footgun is thinking it's just a relational table with many columns—the flexibility is the point.
Eventual Consistency: Availability Now, Correctness Later
Eventual consistency prioritizes availability by letting replicas temporarily disagree. If updates stop, all nodes will eventually converge on the same value.
Document Databases: Store Data as Flexible Objects
A document database stores data as self-contained objects, like JSON, instead of rows and columns. It's ideal for user profiles or product catalogs where each item might have different attributes. The footgun is treating it as a schema-less free-for-all.
Key-Value Store: The Simplest Database Model
A key-value store is a giant dictionary. You give it a unique key, like "user:123", and it returns the associated data. It's the foundation for caching and session management. The footgun is trying to query by value—it's built for key lookups only.
NoSQL: Databases Beyond Rigid Tables
NoSQL databases trade rigid tables for flexible models like documents or key-value pairs. This allows them to scale for massive, unstructured datasets from social media or IoT.
Query Rewriting: Your Database's Unseen Optimizer
A database's query rewriter is like a smart GPS, finding a faster route (execution plan) to the same destination (your query result). It happens automatically to speed up joins and filters. The footgun: your handwritten query isn't what actually runs.
External Merge Sort: Sorting Data Bigger Than RAM
External merge sort handles datasets too big for RAM. It sorts the data in memory-sized chunks, writes them to disk, then merges the sorted chunks back together. It's crucial for database indexing, but its speed is limited by disk I/O, not CPU.
Sort-Merge Join: The 'Line Up and Walk' Join
A sort-merge join is like merging two sorted lines of people. It's efficient when tables are already sorted on the join key or memory is tight. The footgun: if data isn't pre-sorted, the initial sort can make it slower than other join methods.
Hash Join: Faster Database Joins with Hash Tables
A hash join speeds up database joins by building an in-memory lookup table (a hash table) for the smaller table, then streaming the larger one past it to find matches. It's ideal for large, unsorted equijoins.
Nested Loop Join: The Brute-Force Database Join
A nested loop join is the brute-force way to match two tables. For each row in the first table, it scans every row in the second. It's simple and effective for small tables but its performance degrades quadratically on large datasets.
PostgreSQL's Free Space Map: Finding Room to Write
A Free Space Map is a table of contents for empty space in a Postgres table. It lets Postgres quickly find a page with enough room for a new row or index entry, avoiding a slow scan. It's used on every INSERT/UPDATE.
ARIES Recovery Algorithm
ARIES is a widely-used database recovery algorithm, found in systems like IBM Db2 and SQL Server. It enables high performance by supporting a 'no-force, steal' policy, ensuring data integrity after a crash. The main footgun is not understanding this policy.