Cloud Data Warehouse: When You Need One and When You Don't

A 45-person software company signed a cloud data warehouse contract in January. By July they had a Snowflake bill, a Fivetran bill, a dbt Cloud bill, forty-one models nobody had reviewed in four months, and a single dashboard that finance did not trust because the revenue number disagreed with Stripe by about three percent and no one could say why. The head of ops, who had never written SQL before this project, was spending roughly a day a week on it. The original question that started the whole effort was "how many of our trial accounts convert by source," and it still had no reliable answer.

Nothing went wrong technically. Every vendor delivered what it promised. The company simply bought infrastructure sized for a problem it did not have, and the ongoing labor to keep that infrastructure honest quietly became someone's second job. Almost no vendor page will tell you where the line sits, because the vendor's answer to "do I need this" is always yes.

This guide gives you the threshold test instead: the three numbers that decide whether a warehouse pays for itself, the real total cost once you count the humans, and the honest alternative for teams below the line.

What a cloud data warehouse actually does

A cloud data warehouse is a columnar analytical database, separated from the storage it reads, that scales compute independently and charges you for the seconds it runs. Snowflake, BigQuery, Redshift, Databricks SQL, and Microsoft Fabric are the platforms most teams evaluate. Underneath the marketing differences they solve the same three problems.

Scan speed on wide tables. Row-oriented databases like Postgres or MySQL read whole rows off disk. Asking for one column out of eighty across two hundred million rows is enormously wasteful. Columnar storage reads only the column you asked for, compresses it aggressively because adjacent values are similar, and skips entire blocks using min and max metadata. On the right shape of query this is not a twenty percent improvement, it is two orders of magnitude.

Concurrency without contention. Separating storage from compute means the finance team's month-end crunch runs on a different cluster than the product team's exploratory queries, against identical data. Nobody's dashboard times out because someone else kicked off a backfill.

A single join surface across systems that do not speak to each other. Your billing system, CRM, product events, and ad platforms each hold part of any interesting question. A warehouse is the one place where they become tables that join on a common key.

Note what is not on that list. A cloud data warehouse does not clean your data, define your metrics, move data into itself, or tell you when a number looks wrong. Those are separate categories of work with their own tooling, failure modes, and labor cost. Confusing the warehouse with the outcome is the most expensive mistake in this space.

The threshold test: three numbers

Run these three checks before you evaluate a single vendor. If you fail all three, buying a warehouse means buying a maintenance obligation with no payoff attached.

Volume: are your largest analytical tables above roughly 50 million rows, or growing past that within a year?

Modern Postgres on a decent managed instance handles analytical queries over tens of millions of rows perfectly well, with the right indexes and a read replica. Below about 10 million rows in your biggest table, a warehouse buys nothing you cannot get from a replica and some patience. Between 10 and 50 million it depends on query shape: wide aggregations over many columns start to hurt, point lookups do not. Above 50 million with regular full-table aggregations, columnar storage stops being a preference and starts being the reason queries finish.

Concurrency: do more than about ten people or scheduled processes query the same data at overlapping times?

This is the number teams forget. Separated compute is worth real money when a nightly transformation, a BI extract refresh, three analysts, and an embedded customer-facing report all want the same tables at 9am. If your reality is two analysts and one nightly job, contention is a hypothetical problem and you are paying to solve it.

Sources: do you need to join four or more independent systems to answer your most important recurring questions?

One or two sources rarely justify a warehouse. The reporting most companies need from a single CRM or billing system already exists inside that tool, built by people who understand its data model better than you will. The warehouse earns its keep when the question genuinely spans systems: ad spend by campaign joined to signups joined to paid conversion joined to twelve-month retention, each fact living somewhere different.

Here is how the three combine in practice.

Two rows in that table say "borderline" on purpose. Borderline means the deciding factor is not the data, it is whether you have a person whose actual job includes this work. Which brings us to the part the pricing calculators leave out.

The total cost nobody puts on the slide

Cloud data warehouse pricing pages quote compute credits and storage per terabyte. For a mid-sized company that line is often the smallest number in the total. Here is the honest inventory.

Compute and storage. Predictable once you tune it, and genuinely cheap at small scale. Storage is close to free. Compute is where surprises live: an unpaused warehouse, a badly written incremental model that does a full scan every fifteen minutes, or a BI tool refreshing extracts hourly against raw tables can multiply the bill without changing a single business outcome.

Ingestion. Something has to get data in. Managed connectors from Fivetran, Airbyte, Stitch, or a native service charge by rows or by monthly active rows, and the pricing curve tends to be unpleasant exactly where your data is largest and least valuable, for example event streams and email logs. Building it yourself is cheaper in cash and much more expensive in attention. ETL Tools Compared: How to Pick One Without Overbuying walks through those pricing models, and teams still running on-premise pipelines will recognize the tradeoffs in SQL Server Integration Services (SSIS): A Practical Guide.

Modeling. Raw source tables are not analyzable. Someone has to declare what a customer is, what an active account is, what counts as revenue, and how to reconstruct last quarter's territory assignments after the CRM reshuffled them. This is real intellectual work with a real learning curve, covered properly in Data Warehouse Modeling: Star Schemas, Kimball, and Grain. Underestimating it is the most common reason warehouse projects stall: the infrastructure works fine, the semantics were never agreed.

Ongoing operations. Pipelines break. A source API changes a field type, a connector silently drops rows, a schema migration renames a column, a model fails at 3am and nobody notices until 10am when the dashboard is empty. Someone has to be on call for that, or accept that numbers are stale on an unknown schedule.

Governance. Once the warehouse holds customer records from four systems, access control stops being optional. Who can see what, how long it is retained, and how a deletion request propagates all become your problem. Data Governance Tools: What Small Teams Actually Need covers the minimum viable version, which is smaller than the enterprise catalogs suggest but is not zero.

Consumption. A warehouse produces no output on its own. You still need a BI layer and someone to maintain the dashboards in it. For calibration on what a genuinely useful set looks like rather than a wall of charts, see Power BI Dashboard Examples That Are Worth Copying.

Add the labor honestly. The recurring commitment tends to land somewhere between a quarter and a full analytics engineer once the platform is live. If your plan is "our ops lead will pick it up," you have not budgeted for the warehouse, you have transferred an unfunded liability onto someone who already has a job.

Comparing cloud data warehouse platforms without getting lost

If you cleared the threshold, platform choice matters less than most evaluation matrices suggest. The major cloud data warehouse platforms have converged: all separate storage and compute, support semi-structured data, offer auto-scaling and auto-suspend, and have acceptable SQL. The differences that change outcomes are narrow.

Existing cloud commitment. If your infrastructure and identity management already live in one cloud, using that provider's warehouse removes an entire category of networking, billing, and access problems. This is usually the strongest single argument and it is boring, which is why comparison articles underweight it.

Pricing model shape. Per-second compute with auto-suspend, as Snowflake and Databricks bill, rewards bursty interactive workloads and punishes always-on polling. Per-byte-scanned, as BigQuery bills by default, rewards well-partitioned tables and punishes SELECT * habits brutally. Provisioned clusters give you a flat bill and no protection from your own idle time. Pick the shape that matches how your team queries, not the lowest headline rate.

Team skills. A team fluent in Spark and Python will be more productive on Databricks. A team of SQL analysts will be faster on Snowflake or BigQuery. The data warehouse systems you can staff beat the ones that benchmark better.

Ecosystem fit for your BI layer. Check the connector between your chosen warehouse and your chosen BI tool before signing. Live-query performance, incremental refresh support, and pass-through authentication vary more than the vendors admit.

Ignore synthetic benchmarks. Every vendor publishes numbers where it wins, and none of them run your query patterns on your data distribution.

What to do when you are below the threshold

This is the section most articles on cloud based data warehouse selection skip, so here it is concretely. If you failed the threshold test, one of these four data warehouse solutions is almost certainly a better fit than a warehouse.

Use the reporting inside the source tool. Stripe's revenue reports, HubSpot's pipeline dashboards, and Google Analytics explorations are built by people who understand those data models deeply, and they answer single-system questions faster than anything you will rebuild. Teams abandon them not because the reports are bad but because no single tool answers cross-system questions.

Add a read replica of your production database. If most of your important data already lives in one application database, a read replica plus a BI tool gives you real analytics with no pipeline, no sync lag, and no second copy of the truth to reconcile. This carries you further than people assume.

Sync a handful of sources into a single Postgres instance. Not a warehouse, just a database with four or five tables landed by a lightweight connector. You get joins across systems without the credit model, the modeling layer, or the on-call rotation. For many companies this is not a stepping stone, it is the permanent answer.

Connect the source tools to an AI workspace and ask questions directly. For a large share of recurring questions the underlying need is not a dashboard, it is an answer with a source attached. That is a genuinely different architecture, and it is where we should be explicit about what our own product is and is not.

Where Skopx fits, and where it does not

Skopx is an AI workspace that connects to nearly 1,000 tools a company already uses, including Gmail, Slack, Stripe, HubSpot, QuickBooks, and Google Analytics. You ask a question in chat, it queries the connected tools and answers with cited data. It sends a morning brief, runs an insights engine that surfaces risks and anomalies across those tools, and lets you build automations by describing them in chat. It is bring-your-own-key for any major model, at zero markup, and it costs $5 per month for Solo or $16 per seat per month for Team. Full details are on the pricing page.

Here is the honest boundary. Skopx is not a data warehouse and cannot become one. It does not store your data in a columnar store, it does not model it, and it will not replace a warehouse for a company that genuinely cleared the threshold test above. If you have 400 million event rows, twenty concurrent analysts, and customer-facing embedded reporting, you need a warehouse and the team to run it. Nothing here changes that.

Skopx is also not a BI tool: it does not build dashboards. It is not an ETL tool: it does not move data into a destination on a schedule for someone else to model. It is not a CRM. Those distinctions matter because the failure mode this article describes, buying infrastructure for a problem you do not have, applies just as much to buying an AI layer as to buying a warehouse.

What Skopx does address is the gap that pushes under-threshold companies toward a warehouse in the first place: questions that span four systems, where the honest answer today is that somebody exports three CSVs and joins them in a spreadsheet. "Which customers had a failed payment last week and also have an open support thread," "how did the accounts from last quarter's campaign actually invoice," "what changed in pipeline since Monday" never needed 50 million rows or a modeling layer. They needed the systems reachable from one place. If your recurring need is a few dozen questions like these rather than a metric store powering embedded reporting, the warehouse is the wrong shape of solution.

The same logic runs through adjacent categories. Email tooling gets oversold the same way, which AI Email Assistant: What to Expect Beyond Draft Replies treats honestly, and vertical buyers hit an identical threshold question in How to Evaluate Retail Analytics Software: Buyer Checklist.

One thing worth automating even below the threshold is the recurring reconciliation that eats an afternoon each month.

Monthly cross-system revenue reconciliation

First business day

Runs monthly at 08:00 local time

Pull billing totals

Charges, refunds, and failed payments for the closed month

Pull accounting totals

Recognized revenue for the same period

Pull closed-won deals

Deal values and close dates from the CRM

Compare and flag deltas

Any line differing by more than one percent gets listed with the source values

Post summary to finance channel

Includes citations back to each source record

That pattern, described in chat and turned into a scheduled automation, is what workflows are for. It is not a substitute for a warehouse. It is a substitute for the spreadsheet the warehouse project was supposed to eliminate three quarters from now.

Signals that you have actually crossed the line

Thresholds move. Watch for these, because they are the honest triggers for revisiting the decision:

• Routine analytical queries take long enough that people avoid asking, or you are adding indexes purely for reporting and they are slowing writes.
• Reporting load is measurably affecting application performance, or you schedule analysis for off hours to avoid that.
• More than two people maintain conflicting definitions of the same metric, and reconciling them has become a recurring meeting.
• You need to serve analytics to customers inside your own product, where concurrency and latency are contractual rather than merely annoying.
• Your retention requirements exceed what source systems keep. Many SaaS tools expire detailed history, and once the source drops it, no amount of querying brings it back. This is the most legitimate reason to build earlier than the volume test suggests.
• You have hired, or firmly committed to hiring, someone whose job includes owning the pipeline. The practices in Managing Software Knowledge on a Growing Engineering Team apply to data models at least as much as to application code.

That last point deserves weight. The most reliable predictor of whether a warehouse project succeeds is not data volume, it is whether a named person owns it, with protected time, before the contract is signed.

A staged path if you are close to the line

You do not have to choose once and forever. A sequence that works:

1. Answer questions against the sources directly. Cheap, immediate, no infrastructure. This tells you which questions actually recur, which you cannot learn any other way.
2. Land three to five high-value sources in a plain Postgres database. Use a managed connector, do not model yet, write ad hoc SQL. You will learn your real join keys and where the source data is dirty, which is exactly the knowledge that makes a later warehouse project succeed instead of stall.
3. Add a transformation layer only when the same SQL gets copy-pasted for the third time. That repetition is the real signal, not before.
4. Move to a cloud data warehouse when Postgres shows strain, meaning query times growing superlinearly with data, or contention between scheduled jobs and interactive users. By then your models exist and your join keys are understood, so the migration is mechanical rather than exploratory.

Each stage is useful on its own and none of it is wasted if you stop there. That is what makes this a better plan than starting at step four, which is what most data warehouse services will encourage you to do.

Frequently asked questions

Is a cloud data warehouse the same thing as a data lake?

No. A data lake stores raw files, often in open formats, in cheap object storage with schema applied at read time. A cloud data warehouse stores structured, typically modeled data with schema enforced at write time and a query engine optimized for it. The lakehouse category blurs this by adding transactional table formats over object storage. For teams below the threshold test the distinction is academic: neither is the right purchase.

Can I just use Postgres as a data warehouse?

For a surprising number of companies, yes. Postgres with a columnar extension, or even plain Postgres on a read replica with sensible indexing, handles analytical workloads in the tens of millions of rows. It falls over on very wide aggregations across hundreds of millions of rows, on high analytical concurrency, and where you need to scale compute independently of storage. Until you hit those specific walls, Postgres is a legitimate answer and a much cheaper one.

How much does a cloud data warehouse really cost per month?

Platform spend for a small deployment is commonly the least significant line. Ingestion tooling frequently exceeds it, and the labor to model, monitor, and repair the pipeline typically exceeds both. Any evaluation that compares only credit rates across data warehouse platforms is comparing the wrong number. Estimate platform plus ingestion plus a realistic fraction of an engineer, then weigh that total against the value of the questions you cannot currently answer.

Do I still need ETL if I have a cloud data warehouse?

Yes. Warehouses do not pull data, they receive it. You need managed connectors, custom extraction code, or a native ingestion service, and you need someone to notice when it breaks. Modern practice pushes transformation after loading, which changes where the work happens but not whether it exists.

What is the difference between a cloud data warehouse and a database?

An operational database is optimized for many small reads and writes against individual records, with row-oriented storage and strong transactional guarantees. A cloud data warehouse is optimized for scanning and aggregating large volumes of columns, with columnar storage, heavy compression, and independently scaling compute. Using one for the other's job produces the classic symptom: dashboards that time out and applications that slow down when finance runs a report.

Should a 30-person company build a cloud data warehouse?

Usually not, and the exceptions are specific: it serves analytics to its own customers, its source systems expire history it needs to keep, or it has already hired a data person with capacity to own the platform. Absent one of those, a 30-person company gets more value from connecting its existing tools and asking cross-system questions directly. The warehouse will still be there when the thresholds are genuinely crossed, and the project will go better for having waited.