Optional: Modern Big Data Economics

Reading Time: 5 mins

This is an optional exploration of how Big Tech pays for scale. Recommended after completing the SQL Introduction.

Beyond the Syntax: The Economics of Scale

Once you can write SQL, the question shifts from how to write a query to how to pay for it at scale. Four trends shape that bill today.

Trend 1: Scaling Economics (2020s - now)

  • Startup: Use basic Postgres, managed for $10 to $100 a month by a provider like AWS, GCP, Supabase, or Neon, and add a JSONB column for any flexible, semi-structured data. One database handles the structured and the flexible alike, so there is no separate NoSQL system to run.

  • Big Tech: You pay a "Specialization Tax" for a whole hybrid stack (an OLTP database, an OLAP warehouse, an ELT pipeline between them, and NoSQL stores as needed), plus the managed services and custom engines to run it, because doing all of that by hand at their scale would bankrupt you.

The simple default (cyan): basic Postgres plus a JSONB column, one database holding typed columns and a JSON object in the row, managed for ten to a hundred dollars a month (AWS, GCP, Supabase, Neon). The specialization tax (grey): a hybrid stack of OLTP and OLAP databases, an ELT pipeline, and NoSQL stores as needed, plus managed services and custom engines, that scale eventually forces.

Figure 1. Basic Postgres plus a JSONB column supports typed columns and semi-structured fields in one row and keeps them queryable with SQL. A managed provider like AWS, GCP, Supabase, or Neon runs this setup for ten to a hundred dollars a month. Big Tech runs a hybrid stack: an OLTP database, an OLAP warehouse, an ELT pipeline, and NoSQL stores as needed, plus managed services and custom engines.

Trend 2: The Extract-Load-Transform (ELT) Flip (2020s - now)

The Concept: Load the raw data into cheap object storage (S3/GCS) first, then clean it with SQL later. The old way did the opposite (ETL), the flip you met in the big-tech data stack.

The Why:

  1. Raw data is your most valuable asset. If your cleaning logic has a bug, re-run the process from the raw source. Store first, ask questions later.

  2. The flip matters for the 2020s. It is only possible because the cost of storing and managing terabytes of data has dropped by orders of magnitude in the past decade. For example, in the 2020s BigQuery costs under $10/TB/month.

  3. Storing first also makes streaming data easier to handle, and you can process it in real time with SQL.

Two pipelines: old ETL (Extract, Transform to clean, then Load) cleans before storing; new ELT (Extract, Load raw into S3/GCS, then Transform with SQL) stores raw first and cleans later; enabled by storage at about ten dollars per terabyte per month.

Figure 2. ETL runs Extract, Transform, then Load. ELT runs Extract, Load raw data into object storage, then Transform with SQL. Storage at about ten dollars per terabyte per month makes it feasible to keep every raw row and re-run transforms after a bug.

Trend 3: Split Storage from Compute (Apache Iceberg, 2020s - now)

The Problem: Legacy architectures tie storage to compute: to hold 100 TB you pay for an always-on server cluster, even if you query it once a week. You pay a premium for RAM and CPU that sits idle. The Solution: Separating Storage from Compute.

The Why:

  1. Why rent an always-on cluster just to hold files? Split them: keep raw data in cheap object storage (like AWS S3), and spin up the expensive compute engines (CPU and RAM) only for the minutes a query runs.

  2. This decouples scale: storage grows almost without limit and cheaply, and compute scales on its own, sized to how fast you need answers.

  3. The raw data lands as columnar Parquet files in cheap object storage, structured only when you query it (schema-on-read). That is a data lake, the same store-first move as ELT. Add an open table format like Apache Iceberg on top, a metadata layer tracking the schema, which files belong to the table, and snapshots over time, and those raw files behave like real SQL tables, with schema evolution, time-travel, and ACID. Lake storage plus table semantics is a lakehouse.

Coupled architecture pays for an always-on 100 TB cluster billed 24/7; decoupled architecture keeps raw data in cheap object storage and spins up compute only per query.

Figure 3. A coupled cluster ties 100 TB to always-on CPU and RAM and bills 24/7, even with weekly queries. A decoupled system stores raw data in object storage and rents compute only for the minutes a query runs.

Trend 4: The ORM Scale Wall (A Trade-off)

The Concept: Many developers start with an ORM (Object-Relational Mapper) like SQLAlchemy. It lets you write Python objects that become database rows on their own, with no SQL required.

The Trade-off:

  • Startup Phase (The Win): ORMs are a good deal. They let you build features in minutes. They also hide a lot of details.

  • Scale Phase (The Disaster): As you get more users and machines (Distributed Systems), the "hidden details" can cause silent failures that corrupt data.

The Why: We focus on Raw SQL in CS145. When you know how it works, you can find the right balance of raw SQL and ORM. At scale, you need a lot more control.

An ORM saves time in the startup phase but at scale its hidden details cause silent failures that need raw SQL to fix.

Figure 4. An ORM maps Python objects to rows without SQL. In distributed systems, hidden ORM behavior can issue redundant queries and corrupt data without an obvious failure signal. Raw SQL knowledge supports a deliberate split between ORM code and handwritten queries.