Do you actually need a data warehouse?

Every data engineering conversation eventually arrives at the same fork. Data is accumulating, someone from the business asks for a dashboard, and the default answer is Snowflake. Or BigQuery. Or Redshift. The warehouse gets provisioned, connectors get configured, a transformation layer gets added, and a few months later there is a four-figure monthly infrastructure bill serving a relatively small reporting team.

Sometimes that is the right outcome. Often it is not. The problem is that the decision to adopt a cloud warehouse is rarely made on the basis of what the team actually needs. It is made on the basis of what the modern data stack looks like.

Data volume alone is a poor reason to introduce a cloud warehouse. The decision becomes more compelling when concurrency, workload isolation, governance, or operational complexity start to matter. The question worth asking before provisioning anything is whether those problems exist yet.

Postgres

Postgres is an OLTP database. It is optimized for transactional workloads: high-frequency small writes, row-level operations, concurrent application traffic. It is also a capable analytical engine when the workload is predictable and can be isolated using a dedicated analytical instance, a read replica, or a separately loaded database.

The key condition is isolation. Running analytical queries directly against a production application database creates resource contention that affects application performance. A read replica removes that contention and gives analysts a dedicated query target without adding infrastructure complexity.

For a team with predictable query patterns, a small number of concurrent users, and data that lives primarily in one relational system, Postgres often covers the full analytical surface without requiring a separate warehouse. Materialized views handle pre-aggregation. Indexes handle filtering. The operational overhead is minimal because the database already exists.

The case against Postgres emerges when query complexity grows, when multiple teams need concurrent access with workload isolation, or when data arrives from sources that are difficult to consolidate into a single Postgres instance. At that point, the coordination cost of making Postgres work analytically starts to exceed the cost of introducing a purpose-built analytical layer.

DuckDB

DuckDB is an in-process analytical database. It runs inside a Python process, reads Parquet and CSV directly from S3, and executes SQL without a server, a cluster, or a cloud account. It handles larger-than-memory workloads through spilling to disk for joins, aggregations, sorts, and window functions. Single-node DuckDB databases can exceed several terabytes.

The right framing is not data size. It is workload shape. DuckDB fits when the workload is analytical and file-oriented, execution can remain on a single node, and high multi-user concurrency is not a core requirement. For local and single-node workloads, it provides strong performance without provisioning a separate database service.

A practical setup for a small data team: raw data lands in S3 as Parquet files, DuckDB queries it directly, results materialize into a serving layer that a BI tool reads. No ingestion pipeline, no warehouse credits, no infrastructure to manage between runs.

A local DuckDB database does not provide the managed identity, workload isolation, central governance, and multi-user service model that an enterprise cloud warehouse provides. For a solo analyst or a small team doing internal analytics, those are not yet problems. For a company where multiple analysts need to share datasets, manage permissions, and audit query history independently, they are.

MotherDuck

MotherDuck is managed DuckDB in the cloud. It preserves the DuckDB execution model and adds persistent cloud storage, collaboration, and managed compute. It removes the primary limitations of using local DuckDB as a shared analytical platform: data lives in the cloud, multiple users can connect, and there is no local file to manage.

MotherDuck fits teams that like how DuckDB works but need a shared layer with managed compute. Its ecosystem and operational model differ from mature enterprise warehouses, and it is worth evaluating against the specific requirements of the team rather than assuming it slots in as a cheaper Snowflake. The right comparison is not cost per query in isolation but total operational fit: how the team works, what integrations are needed, and what the next twelve months are likely to bring.

Cloud warehouses

Snowflake, BigQuery, and Redshift solve a coordination problem. They separate compute from storage, isolate workloads across virtual warehouses, handle multi-cluster concurrency, and provide centralized governance across multiple teams and data sources. These capabilities become compelling when the cost of coordinating analytical workloads, users, and governance exceeds the cost of operating the warehouse itself.

That threshold arrives at different points for different organizations. It is not primarily a function of row count. A company with 50 million rows, five analysts, three source systems, and a finance team that needs row-level access control may have a stronger case for a cloud warehouse than a company with 500 million rows and one analyst running batch reports overnight.

The capabilities that most often justify the move: multiple teams running concurrent queries that need workload isolation, data arriving from sources that are difficult to consolidate otherwise, data sharing across organizational or partner boundaries, and governance requirements around access control, audit logging, and compliance.

A decision framework

The more useful set of questions is not about thresholds. It is about the nature of the problem.

1. Where does the data live today? A single Postgres database is a different starting point than a dozen SaaS systems, files in object storage, and feeds from external partners. The consolidation problem alone changes the answer.
2. What does the workload look like? Sporadic reports run overnight are a different problem than interactive dashboards refreshed every fifteen minutes by twenty concurrent users. The query pattern matters more than the data volume.
3. How many users and processes need the data simultaneously? A single analyst with a predictable query set is a different problem than multiple departments running independent pipelines against the same tables.
4. What are the operational requirements? SLA guarantees, workload monitoring, backup and recovery, cost controls, permission management. These requirements add operational overhead to any self-managed solution that a managed warehouse absorbs.
5. What changes are likely in the next twelve to eighteen months? A new market, a new ERP, an acquisition, external customers who need access to data. The decision that fits today may not fit in a year.

Mapping those answers to options:

• Postgres fits when the analytical workload is predictable, the number of concurrent users is small, data is primarily relational, and analytical queries can be isolated from application traffic.
• DuckDB fits when the workload is batch and file-oriented, execution can stay on a single node, and there is no strong requirement for a central multi-user service.
• MotherDuck fits when the DuckDB execution model is the right fit but shared cloud storage, collaboration, and managed compute are required.
• A cloud warehouse fits when multiple sources, teams, and workloads need to be coordinated, when governance and workload isolation are requirements, and when the operational complexity of the alternatives exceeds the cost of the managed service.

The actual mistake

The mistake is not choosing Snowflake. It is choosing Snowflake at the point where the answer was still Postgres, and then spending two years paying for infrastructure complexity that the data volume and team size do not justify. Once the ingestion pipelines, transformation layer, and BI connections are built around a warehouse, migrating to a simpler stack is expensive. The architecture locks in before the team has the data to know whether it was the right call.

A cloud warehouse should be introduced when it solves a coordination, concurrency, governance, or operational problem. Not simply because the company has started collecting more data.

Before you choose a warehouse

Choosing the right analytical layer is not about selecting the most powerful platform. It is about identifying the first problem your current stack can no longer solve.