Database Types and Storage

Every database sits on top of a storage primitive, and the primitive shapes what the database can do. File storage gives you a hierarchy of named files and directories, which is why shared file systems back content pipelines and home directories. Block storage hands you raw fixed-size blocks with no notion of files at all, which is what database engines actually want when they manage their own pages and write patterns. Object storage drops the hierarchy entirely and stores immutable blobs addressed by a key, with metadata attached, which is why it underpins almost every modern data lake and backup system. Blob storage is the same idea expressed in cloud vendor terms.

The trade-off line runs along latency, mutability, and scale. Block storage is the fastest and most flexible per byte but the hardest to scale and the most expensive. Object storage scales to effectively unlimited capacity at low cost but has higher latency and treats objects as write-once. File storage sits in the middle and is the most familiar to applications but the least elastic. A system design answer that says "store the user uploads in object storage and put the hot operational data on block storage" is already showing it understands the layers underneath the database.

On top of these primitives, the storage engine decides how data is laid out on disk. Row-oriented storage keeps a whole record together, which is ideal when you read and write entire rows in transactional workloads. Columnar storage keeps each column together, which is what makes analytical scans over billions of rows fast because you only read the columns you need and they compress beautifully. Knowing whether a workload is row-shaped or column-shaped is the first fork in almost every storage decision.

The honest answer to "which database should I use" is usually "more than one." Polyglot persistence is the deliberate practice of using a different store for each part of the system: a relational database for orders, a key-value store for sessions, a search engine for the catalog, a time-series database for metrics. Database federation puts a query layer in front of several stores so they look like one, and multi-model databases try to support several data models in a single engine to reduce operational sprawl. Each of these is a trade between operational simplicity and using the best tool for each job.

The SQL world has been catching up to the scale that NoSQL once owned. NewSQL databases keep the relational model and ACID transactions while scaling horizontally, and distributed SQL extends that across many nodes and regions. Global tables replicate a single logical table across regions so users everywhere read locally, accepting the consistency trade-offs that come with geo-replication. When you need transactions and scale together, these are the families to study, because the old assumption that you must give up SQL to scale is no longer true.

Underneath all of this sit the data structures that make storage engines work, and understanding them explains why each database behaves the way it does. LSM trees buffer writes in memory and flush sorted runs to disk, which is why write-heavy stores like Cassandra are fast on writes but pay a read and compaction cost. Bloom filters let an engine skip reading a file that definitely does not contain a key, cutting wasted disk reads. Skip lists give in-memory stores ordered data with simple, fast inserts, and merkle trees let replicas detect and repair differences efficiently. These are also the topics that show up most in senior interviews.