Data Storage
PedalCity keeps rides in three places, and that is deliberate. The app needs to fetch one rider's current ride in milliseconds. Finance needs to add up a year of fares. The data team wants to keep every raw sensor reading for years without a huge bill. No single kind of storage is best at all three.
The rule
Store by how data is read: rows for lookups, columns for scans, objects for bulk.
Row-oriented databases (such as PostgreSQL or MySQL) keep all the columns of a record together on disk. Fetching "ride 88121, every column" is one quick read. This suits apps that read and write single records all day.
Column-oriented stores (analytical warehouses, and file formats such as Parquet) keep each column together. To total a year of fares, the engine reads only the fare column and skips the rest. Values in a column look alike, so they compress very well, and that means even less to read.
Object storage (such as Amazon S3, Google Cloud Storage or Azure Blob Storage) holds files of any kind, cheaply and in almost unlimited amounts. It is not a database: you read and write whole files. It is the natural home for raw copies and archives.
-- row store: one record, all columns
SELECT * FROM rides WHERE ride_id = 88121;
-- column store: millions of rows, one column
SELECT SUM(fare) FROM fact_rides WHERE ride_date >= '2025-01-01';Cost follows temperature. Hot data is read often and sits on fast, pricier storage. Cold data is rarely read and can move to cheaper, slower tiers.
The shortcut
Look at the access pattern. One entity with many columns, read or written often → row store. Many rows but few columns, mostly read → column store. Keep everything, read rarely, lowest cost → object storage.
"Show the rider their ride in progress"
One record, all columns, many times a second. Row store: the app's PostgreSQL.
The trap is running a year-long analytical query on the app's row store. It works, but slowly, and it steals capacity from riders trying to unlock bikes.
Drills
Answer fast — trust the rule.
The app shows a rider their current ride. Which storage fits best?
Finance sums the fare column across all 2025 rides. Which storage fits best?
Why is SUM(fare) fast in a column store?
Where should three years of raw sensor readings, rarely read, be kept?
Remember
- Store by how data is read: rows for lookups, columns for scans, objects for bulk.
- Check the access pattern: one entity, many columns, or keep everything cheaply.
- Hot data on fast storage, cold data on cheap storage.