Data warehouse sizing before you have production volumes is a planning exercise, not a guess at terabytes. Size from the questions you must answer, the grain of the facts, retention, concurrency, and how fresh those answers need to be — then pick an engine you can resize.
You cannot size a warehouse from a slide
Vendors will ask for "expected data volume." You do not know it yet. Pretending you do produces a cluster that is either idle or on fire.
What you can know is the work. You can name the decisions that need a number by 9am, the events that must stay at transaction grain, and the dimensions that change. You can name concurrency and how long a failed load may take to replay.
Those answers bound compute, storage, and cost better than a fictional row count.
Start with jobs, not tables
List the jobs the warehouse must serve in the first two quarters: close the books, weekly growth review, operational exceptions, and product analytics. Each job has a grain, a freshness need, and a failure cost.
A finance close that restates history needs strong consistency and replay. An operational board that can tolerate last hour's batch does not. Sizing as if every job were the close is how teams overbuy.
Write the jobs on one page. If a requested dataset does not serve a job, it is not in the first warehouse. It can wait.
Grain is the hidden multiplier
Transaction-grain facts grow with events. Daily snapshots grow with time and with the dimension they snapshot. Both can be correct. Mixing them without noticing is how a "small" warehouse becomes a large one.
For each fact, name the grain in business words: one row per invoice line, per shipment, per user-day. If two teams want different grains, that is two facts, not one wide table.
Do not store clickstream at full fidelity in the same service that serves the close unless you have a separate reason. Hot analytical jobs and cheap historical storage are different sizes.
Retention and replay beat raw volume
Ask how long each grain must remain queryable at full detail, and what can roll up after that. Ninety days of detail plus monthly rollups is a different warehouse from "keep everything forever at event grain."
Ask how you will replay. If bronze (or the equivalent landing zone) holds the raw files, the warehouse can be rebuilt. That lets you size compute for the current model, not for every future column you might add.
Citi Global Wealth's eighteen-month move off five regional datacentres onto one cloud platform, reported by Computer Weekly on 8 September 2026, is a reminder that platform consolidation changes reporting speed more than a bigger box does. Size for a model you can rebuild, not for five copies of the same events.
Field notes on unifying data, governance and getting analytics teams to one source of truth.
Every Monday, five minutes.
Concurrency and freshness set the compute shape
A warehouse that serves two analysts overnight looks nothing like one that serves embedded dashboards all day. Count concurrent queries you must not queue, and the largest scan you will allow those queries to do.
Freshness is the other axis. Nightly batch can use a small warehouse that scales up for the load window. Sub-hour freshness needs either incremental models or a more always-on compute pattern. Do not buy always-on for jobs that are happy at 8am.
Google Cloud's borderless Lakehouse cross-cloud caching preview on 18 September 2026 is aimed at teams who do not want to recopy data just to query it. Treat that as a direction, not a sizing number: cache and incremental compute often beat a second full copy.
A sizing worksheet you can fill without production data
For each job, fill in: grain, expected keys (not rows), retention at that grain, freshness, concurrency, and whether history restates.
Translate that into three capacities you can actually buy: storage for landing plus modelled tables, compute for the transformation window, compute for query. Keep them separate in the plan even if one vendor bundles them.
Add headroom as a policy, not as folklore. You want room to replay a bad week and to onboard one more source. You do not want a cluster sized for a company you have not become.
What to defer
Do not size for every SaaS tool in the stack before anyone has queried the data. Land the sources that feed the first jobs.
Do not lock a five-year hardware plan. Elastic warehouses exist so you can be wrong cheaply. Your job is to be wrong in a direction you can reverse: too little storage is easier to fix than an unmodelled swamp.
Do not confuse warehouse sizing with lake sizing. Files in object storage are cheap. Modelled tables that are scanned all day are not.
How LensAIght changes the plan
LensAIght is a unified data intelligence platform, so documents, SQL sources, and dashboards can live under one tenancy. That does not remove sizing. It does mean you should size the analytical store for the modelled jobs, and treat document retrieval as a separate capacity with its own retention.
If chat and dashboards share silver-style modelled datasets, you avoid a second extract that you forgot to size.
Frequently asked questions
How do I do data warehouse sizing with no production data?
Size from jobs, grain, retention, freshness, and concurrency. Skip fictional terabyte forecasts. Buy an engine you can resize after the first sources land.
Should I size for peak event days?
Size transformation compute so a peak day can finish inside your freshness window. Do not keep that peak provisioned all month if your engine can scale.
Is object storage part of warehouse size?
Treat landing files as lake storage with its own retention. The warehouse you size for queries is the modelled layer people actually scan.
How much history do I keep at full grain?
Keep full grain for as long as a job must restate or audit it. Roll up the rest. "Forever, just in case" is how idle storage becomes an unowned archive.
Can I copy another company's size?
No. You do not have their jobs, grain, or concurrency. You can copy their worksheet, not their cluster.
When should I revisit the size?
After the first two sources are modelled and the first executive job is live. That is the earliest moment the plan can meet reality.
Book a demo to see a managed data platform running on your own sources
LensAIght
