Foundations

A map of where data actually lives — from one table in a database to data warehouses, lakes, and lakehouses — and which layer fits which job. The overview that ties the whole storage stack together.

OLTP runs your application — many tiny reads and writes of whole rows. OLAP runs your analytics — huge scans of a few columns. They pull database design in opposite directions, which is why you end up with two systems and a pipe between them.

Schema-on-write enforces structure at ingest (warehouses); schema-on-read stores raw and applies structure at query (lakes). Flexibility vs guarantees.

SQL databases are relational, schema-enforced, and strongly consistent. NoSQL is a grab-bag of non-relational stores built for scale and flexible schemas. Pick by access pattern.

A lakehouse puts a database-style table layer on top of cheap object storage — warehouse guarantees (ACID, schema, time travel) over data-lake files. How the layers stack, and why the architecture exists at all.

A database is software that stores data and answers questions about it safely and fast — schemas, indexes, transactions, a query language. Why it beats a pile of files, and the OLTP/OLAP split that divides the whole field.

A data warehouse is a database built the opposite way from your app's — columnar, massively parallel, tuned for huge scans and SQL over the whole company's history. What separates it from an OLTP database, and what you pay for the speed.

A data lake is your data as open files in object storage — cheap, open, readable by any engine. Done right it is organized and governed, not a swamp. How it differs from a warehouse, and where a table format fits in.

ACID is the four guarantees a database transaction makes — Atomicity, Consistency, Isolation, Durability — and why they get hard in distributed systems.