Why Snowflake is expensive (they're marking up EC2s) | GreybeamNew launchGreybeam's free Snowflake cost observability tool - Greysight<br>Back to BlogKyle Cheung/August 4, 2026/15 min read/Snowflake<br>Why Snowflake is expensive (they're marking up EC2s)

When Amazon Redshift went generally available in 2013, a data warehouse was a fixed set of machines. Each compute node came with a set amount of CPU and local storage bundled together. If you wanted more compute, you had to pay for storage you might not need, and if you wanted more storage, you probably took on CPUs you might not have used. Back then it wasn't uncommon for a single cluster to serve every workload, so queries competed for resources and a heavy transformation may have slowed down dashboards.

Snowflake's 2015 architecture separated those resources and bundled it into a slick SaaS experience. Compute ran independent of storage, which meant you could resize one warehouse, isolate another, or switch either off without moving the tables underneath. Storage capacity and compute capacity no longer had to be purchased together.

Snowflake's original philosophy for the user experience (source).Snowflake is expensive eventually became a common saying. While it's not entirely inaccurate, it helps to remember how much infrastructure a data team had to think about over the years.

Where the warehouse came from#

Before Redshift, most analytical data of any real size lived in Hadoop, which generally meant that the data team also had to manage the actual machines underneath it.

Hadoop stored files in HDFS, the Hadoop Distributed File System. HDFS divided a large file into fixed-size blocks and distributed those blocks across the machines in a cluster, keeping a few copies of each block so a failed disk did not mean lost data. Each worker machine ran a DataNode, the process that held and served its assigned blocks, while a NameNode kept the directory of which block lived where in memory on a single machine.

Those worker machines also supplied the compute. In a typical Hadoop setup, each machine ran a TaskTracker for MapReduce, Hadoop's batch execution system. When a job needed to process a block, the scheduler tried to place the work on the machine that already held that block on its local disk; otherwise, the cluster had to copy the block across the network first. Keeping work close to the data is called data locality, and the design reflected a period when network transfers were slow and expensive enough to avoid whenever possible.

Hadoop 1.x architectureThis arrangement tied storage and compute to the same fleet of machines. A team could not add query capacity without also paying for more storage, and could not expand storage without also taking on CPUs that might sit idle. The cluster had to be sized for its busiest hour and kept online around the clock because the data lived on those machines, and turning the cluster off took the data offline with it.

Redshift removed much of that operational work. Instead of buying servers and standing up a cluster, a team could provision a managed, columnar, massively parallel warehouse from the AWS console in minutes.

Queries used SQL over JDBC or ODBC, allowing analysts to connect existing BI tools directly. Hadoop offered SQL layers such as Hive, but these commonly compiled queries into relatively slow MapReduce jobs and often required substantial engineering and cluster administration. Redshift provided a more conventional, interactive warehouse experience without teams having to build and operate that stack.

AWS also handled the rest of the operational burden underneath: node failure, replication, backups, and upgrades. For teams struggling with Hadoop operations, this was a substantial improvement.

Redshift architecture.Underneath, though, the machine had the same basic shape as before. Each Redshift node still packed CPU and storage together, and every table was sharded across those nodes. Teams still planned storage and compute capacity together, and resizing meant rebuilding the cluster.

Sharding splits a table's rows across multiple machines so each machine stores and processes only part of the data. Requests are routed to the shard that owns the relevant rows, spreading storage and work across multiple machines.

Physical layout also shaped query performance. Joins ran fastest when matching rows already lived on the same node, so teams chose a distribution key for each table and accepted the tradeoffs that followed. A single cluster still served every workload, with contention managed through workload management queues that defaulted to five queries at a time. Redshift was considerably easier to operate than Hadoop, but the work still had to be organized around the cluster.

Splitting storage and compute#

When Snowflake became generally available in 2015, it placed data in object storage rather than on the compute workers. Independent groups of workers would have to fetch the data they needed over the...