How this session works
Sessions a1-a3 built the why: analytics needs its own copy of the data, shaped as a star schema, with one agreed set of definitions. Today is the shopping trip. We compare the three storage estates, then walk the 2026 engine landscape - Snowflake, BigQuery, Redshift, Databricks, and the humble free tier - the way a buyer should: by pricing shape and failure mode, not by feature checklists. You leave with a vendor-meeting script.
Warehouse, lake, lakehouse: three estates 8 min live
Think of your company's data as property. A warehouse is the finished office building: structured, modeled, governed, every desk labeled - dashboards plug straight in. A lake is the cheap land next door: raw files of any shape, stored for pennies, order optional. A lakehouse is the newest build: warehouse-style tables constructed directly on lake files, one estate trying to serve both crowds.
LiveWhich estate does Daybreak actually need?4 min▶
Daybreak's questions are revenue by month, churn by cohort, subscription health - structured questions about structured data. That is warehouse work, full stop. A lake earns its keep when you have data that will not fit tables: clickstream logs, support-call audio, product photos for a future ML model. A lakehouse earns its keep when both of those are true at real scale and you have engineers to run it.
- Warehouse first: if your pain is "reports are slow and numbers disagree" (a1-a3), the warehouse is the cure. Every dashboard question in this course is warehouse-shaped.
- Lake when raw piles up: cheap parking for data you cannot model yet. Without governance it quietly becomes the "data swamp" - IBM's course names this failure mode.
- Lakehouse when both crowds are real: analysts and ML teams sharing one governed estate. Genuinely good technology - and more moving parts than a young data team should own.
The lakehouse bought too early. A 200-person retailer bought a full lakehouse platform because the demo was dazzling. Eighteen months later, 95% of usage was plain SQL dashboards - warehouse work carrying lakehouse operational overhead. The board asked what the extra spend had bought. Nobody had a good answer. The right sequence was a warehouse now, the lakehouse conversation at the next scale-up.
Self-studySay each one in a sentence2 min read▶
Board-meeting definitions, no jargon debt:
- Warehouse: "the structured, governed copy of our data that answers business questions fast."
- Lake: "cheap storage for raw data we have not modeled yet - useful, but not answers."
- Lakehouse: "warehouse-style tables built directly on lake files, so one system serves analysts and ML."
- The trend to know: the estates are converging - warehouses read lake files, lakehouses add governance. Session a6 returns to this. The labels matter less every year; the discipline (modeling, definitions, governance) matters exactly as much.
The engine landscape, buyer's cut 9 min live
Five names cover most shortlists in mid-2026. Do not memorize features - they converge within a year of each other. Learn each engine's pricing shape and its watch-out, because that is what still differs when the feature war is a tie. One health warning before the table: pricing moves fast - treat this as the shape of each deal, and re-verify numbers the week you buy.
| Engine | Best for | Pricing shape | Watch out |
|---|---|---|---|
| Snowflake | Multi-cloud enterprise default; separated storage and compute | Credits per second of compute; storage billed separately | Warehouses that never auto-sleep burn credits around the clock |
| BigQuery | Serverless, near-zero ops, Google Cloud shops | Pay per TB scanned, or flat slot commitments | One careless SELECT * over a huge table is real money |
| Redshift | AWS-committed estates, deep AWS integration | Cluster (provisioned) or serverless | Provisioned clusters bill while idle; sizing is on you |
| Databricks | Lakehouse-first: analytics plus serious ML, Delta Lake native | Compute units (DBUs) on top of your cloud bill | A power tool - assumes engineers who can hold it |
| DuckDB + Postgres | Laptop-scale analytics; a small company's first warehouse | Free, open source | Single node - Postgres strains as a warehouse near ~100 GB |
LiveIBM's four selection criteria - your scoring sheet4 min▶
IBM's fundamentals course boils system selection down to four criteria. Use them as columns in a scoring sheet and the vendor conversation becomes yours, not theirs:
- Features and usability: can your actual team - not the demo engineer - use it day one? Weight usability over feature count; unused features cost money anyway.
- Compatibility: does it plug into your BI tool, your sources, your cloud? A cheap engine that needs six custom connectors is not cheap.
- Scalability: not "can it handle petabytes" but "can it grow smoothly from where WE are" - and shrink in a quiet quarter without a contract fight.
- Total cost of ownership: license plus compute plus storage plus the people to run it plus the cost of leaving. The sticker price is the smallest of those numbers.
LiveCloud vs on-prem in 2026: a short conversation3 min▶
A decade ago this was a real debate. Today the default is cloud: elasticity, zero hardware, and pay-for-use fit warehouse workloads almost perfectly - warehouse demand is spiky (month-end, board week) and the cloud lets you pay for the spike only.
- Default cloud: for most companies, most workloads. All five engines above are cloud-first or cloud-only.
- On-prem earns its place for data sovereignty and regulatory regimes that require data on national soil or your own metal - banking, defense, some healthcare and public sector.
- The honest middle: regulated firms often run hybrid - sensitive data on-prem or in-region, everything else in cloud. That is a design choice, not indecision.
The sovereignty question that saved a deal. A Singapore financial-services CDO was two weeks from signing a US-region warehouse contract when compliance asked one question: "where does the data physically sit?" The answer forced an in-region deployment - available, but priced and scoped differently. Asking in week one instead of week eleven would have cost nothing. Put "which region, and who can access it?" on your ten-question list. It is there.
Self-studyWhy DuckDB and Postgres are on a buyer's table2 min read▶
The free row is not a joke - it is a calibration. DuckDB is a real columnar engine (it powers the builder track of this course, live in a browser tab), brilliant for laptop-scale analysis. Postgres runs fine as a small warehouse until roughly 100 GB. If your data fits there, a five-figure platform contract is solving a problem you do not have yet - and knowing that changes your negotiating posture on day one.
Ten questions, red flags, and the pilot 8 min live
Vendors answer the questions you ask. These ten force the answers that decide the next three years of your data budget. Print them; the goal is not to be hostile, it is to be un-surprisable.
LiveThe ten questions to ask any warehouse vendor5 min▶
- Am I paying per scan, per compute-second, or per seat? The shape of the meter decides which of my team's habits get expensive.
- What does a paused warehouse cost me? Idle should be near zero. If it is not, ask why.
- What does it cost to get my data OUT? Egress fees are the quiet lock-in. Get the per-TB exit price in writing.
- Show me the bill for my workload, not your demo. Give them your real query volume and data size; make them price that.
- Which region does my data sit in, and who can access it? The sovereignty question, before compliance asks it for you.
- What happens when we 10x - and what happens when we shrink? Scaling up is the brochure; scaling down is the contract fine print.
- Do purchased credits or commitments expire? Expiring credits are a discount that becomes a donation.
- What in this proposal is proprietary format vs open format? Open formats (like Parquet) keep the exit door unlocked.
- What does support actually cost at the tier we would need? The listed price often assumes a support tier no serious company runs on.
- Which reference customer looks like us - and can I call them? Not their biggest logo. Their customer at your size, in your industry.
LiveRed flags in the proposal3 min▶
- Credits that expire: a large upfront credit purchase with a 12-month expiry is a bet against your own adoption speed - and the house wins.
- "Unlimited" with fine print: unlimited queries at a fixed price usually hides a throttle, a "fair use" clause, or a compute class too small to matter.
- Discounts that require 3-year commitment before a pilot: a price that is only good today is a pressure tactic, not a price.
- TCO comparisons the vendor made for you: always check whose assumptions fill the spreadsheet. Rebuild it with your numbers.
- No straight answer on egress: if the exit cost takes three follow-up emails, that is itself the answer.
The credits that vanished. A scale-up pre-bought a year of warehouse credits at a handsome discount. Migration slipped two quarters; 40% of the credits expired unused. The "discount" made the effective price higher than list. The fix in the renewal: smaller commitment, rollover clause, price locked for growth. The vendor agreed - because the buyer finally asked.
Self-studyThe pilot-before-commit playbook3 min read▶
Never buy from the demo. The demo runs the vendor's data on the vendor's tuning. The pilot runs yours:
- Shortlist two engines using the four criteria - not five engines, two. Real pilots are work; spread thin they prove nothing.
- Pilot 2-4 weeks with a real slice: one genuine subject area (Daybreak would pick orders + subscriptions), your five most-used dashboard queries, your actual BI tool on top.
- Measure three things: cost of the pilot workload extrapolated to a year, query speed on YOUR queries, and how much help your team needed - the team-fit number predicts TCO better than the price sheet.
- Negotiate with exit doors: shortest commitment that gets an acceptable price, rollover on any credits, egress terms in the contract, data in open formats where the platform allows.
- Then commit properly: once chosen, stop re-litigating for a year. Switching costs are real; serial pilots are their own waste.
Take this back to your desk ◐ 20 min
- Find out what your company runs today - warehouse, lake, lakehouse, or "a big Postgres and hope". Ask your data lead which estate it is and whether they agree with the label.
- Ask for last quarter's warehouse or analytics-platform bill. You are not auditing - you are calibrating. Session a5 teaches you how to read it.
- Score your current platform against IBM's four criteria (features/usability, compatibility, scalability, TCO) from memory, then ask your data lead to score it too. Compare notes.
- If a vendor conversation is live anywhere in your org, forward yourself the ten questions and check how many the current proposal already answers in writing.
- Ask one deliberately naive question this week: "what would it cost us to leave our current platform?" The quality of the answer tells you a lot.
Official sources covered
The leader track distills the buyer-relevant half of the major warehousing curricula - concepts and selection judgment, without the hands-on labs. This session covers:
Three questions before you go 🎯 ◐ 90 seconds
1 · A lakehouse is best described as...
The lakehouse merges the two estates: lake economics underneath, warehouse structure and governance on top. Powerful - and more moving parts than a first warehouse needs.
2 · Your team lives in SELECT-heavy dashboards over one very wide table. Which pricing shape deserves the hardest look before you sign?
Match the meter to your habits. Scan-priced engines are wonderful for disciplined queries and expensive for SELECT * cultures - a5 turns this into a full cost playbook.
3 · The vendor offers a deep discount on pre-paid credits that expire in 12 months. The buyer's move is...
Expiring credits bet against your own adoption speed. Commitments are fine - sized honestly, with rollover, after a pilot on your real workload.