Why a warehouse

The industry names are OLTP and OLAP, and you only need the shapes, not the acronyms. Transactions (OLTP) are narrow and urgent: one customer, one row, right now - "show Ava her subscription", "take this order". Analytics (OLAP) is wide and patient: every customer, all of history, but only two or three fields - "average order value by month for two years". Same data, opposite access patterns.

• The app database is tuned for the first shape: fast, safe, one-row surgery. That is exactly what running a business needs.
• Your questions are the second shape: big scans that summarize. Boards, budgets, and forecasts all live here.
• The conflict is physical, not organizational: no amount of process fixes a machine being asked to do both at once.

When the dashboard is slow, the first engineering reflex is "add an index". Worth understanding why that reflex is wrong here, because it is the cheapest-looking option on the table. An index is like a book's index: brilliant for jumping to a few specific rows. But analytics does not want a few rows - it wants all of them, summed up. There is no index for "read everything and add it up"; the data's physical layout itself has to change, and that means a separate, restructured copy.

• Indexes find needles. Analytics wants the whole haystack, weighed.
• Every index also taxes the app: each new order now has to update the index too. You slow checkouts to speed a dashboard - the worst trade available.
• The honest fix has a name: get analytics off the app database. That sentence is the birth certificate of every warehouse.

Three terms your team will use interchangeably in front of you. They are not interchangeable:

• Data warehouse: the structured, governed copy of your data, modeled for analytics. The center of gravity, and of this course.
• Data mart: a slice of the warehouse served to one team - a finance mart, a marketing mart. Marts come from the warehouse, not instead of it.
• Data lake: cheap storage for raw files of any shape - useful, but ungoverned by default. The "lakehouse" hybrid appears in session a4's landscape tour.

Handy test: if someone proposes "a lake instead of a warehouse" for your KPI reporting, ask who is responsible for making the numbers in it trustworthy. The silence is the answer.

Executives often flinch at "we will maintain a second copy of all our data" - it sounds like waste. Reframe it: the copy is where every property analytics needs but the app cannot afford gets added.

• The copy can be restructured for scanning without slowing a single checkout.
• The copy can keep history: the app overwrites a customer's plan when it changes; the warehouse remembers what it was last quarter - which is the only way "how did upgrades trend" is answerable.
• The copy can be governed: tested, documented, access-controlled. You cannot bolt audit discipline onto a live production database; you can build it into the copy.
• The copy is safely behind live - minutes to hours, by design. For "how did June go", that lag costs nothing.

The number that surprises leaders in both directions: storing the copy is nearly free - cloud storage is pennies per gigabyte per month. The real bill is elsewhere.

• Compute: modern warehouses charge when queries run. A well-run setup costs little; an unmanaged one - dashboards refreshing every 5 minutes, analysts scanning everything - burns quietly. Session a5 covers the levers.
• People: the pipelines that feed the warehouse need building and tending. This is usually the largest line item and the one most often left out of the pitch.
• The honest framing: you are not buying a product, you are standing up a small capability. Budget for the team, not just the tool.

If this describes your company, a warehouse is premature:

• One analyst, modest data: a read-only copy of the app database - or a single-file tool like DuckDB on an export - answers every question you have, today, for almost nothing.
• Questions are still ad hoc: nobody is checking the same number weekly. Warehouses shine when questions repeat; one-off curiosity is cheaper served by hand.
• No one owns definitions yet: if "active customer" means three things in three meetings, a warehouse will faithfully industrialize the confusion. Fix the vocabulary first (that is session a3's agenda).

Three signals, any two of which mean the conversation is overdue:

• Dashboards are timing out or - worse - slowing the product, like Daybreak's frozen checkout. The physics has arrived.
• Metric disputes are recurring: two teams bring two versions of the same number to the same meeting, monthly. You are paying a truth tax in executive hours.
• Compliance or audit asks for lineage - "show us where this number came from" - and the honest answer is a chain of spreadsheets and one analyst's memory.

Once "do we need one" becomes yes, the next meeting is "which one" - and that is a landscape of cloud platforms (Snowflake, BigQuery, Redshift, Databricks and friends) plus a build-it-lean open-source path. Session a4 walks the landscape properly. For now, three anchors to resist vendor gravity:

• The concepts in this track transfer everywhere: every vendor sells the same core idea you just learned - a governed, scan-shaped copy.
• Your leverage is highest before a contract is signed, not after. Arrive at a4 with your requirements, not their demo script.
• Migration is expensive; concepts are portable. Bet accordingly.