Snowflake is a Table Game; Google Cloud is a Casino
There are these two young cloud data engineering fish swimming along and they happen to meet an older cloud data engineering fish swimming…

There are these two young cloud data engineering fish swimming along and they happen to meet an older cloud data engineering fish swimming the other way, who nods at them and says, “Morning, boys. How’re the cash flows?” And the two young fish swim on for a bit, and then eventually one of them looks over at the other and goes, “What the hell are cash flows?”
I stole this fish tale from David Foster Wallace’s This is Water. The point of the story is that the most obvious realities are often the ones that are hardest to see or talk about.
The graph, the pipeline on the cloud, these are all just sets of cash flows. When you create processes among, between, over, under, around, and through various systems and graphs, you make cash flows for various storage or compute centers.
Investors in the cloud will talk about ‘workloads’ shifting to different storage and compute centers. It’s the whole ballgame. It’s the reason cloud vendors have 500 page documentation manuals and why they give out free socks and Patagonia vests.
As America’s top data consultant I am often asked about what is better, Snowflake or Google Cloud Platform’s BigQuery.
I usually just start laughing.
What problems do you want to solve? What type of business are you? What is in place today? Are you operating at the scale where this question even matters? Do you have existing spend commitments with anyone?
I usually get blank states when I ask these questions. Rarely is any of this considered before the question is asked.
Snowflake vs. Google BigQuery doesn’t really matter.
Snowflake is a table game, and the Google ecosystem is a casino.
Do you want to play a table game, or are you already at the Google casino?
The Google Ecosystem is a Casino

Let’s run through a basic scenario I’ve gotten a few times in my career as America’s top data consultant.
Let’s say you’re a business that sells physical goods online to consumers — a typical online DTC e-commerce business. You have a website with Google Analytics for events. You have Google Firebase set up for your loyalty app that was made to engage all of your high value customers. You spend a lot of money on Google Ads, as well as on Facebook, and you have a consultancy doing SEO to improve your visibility and presence on Google Search. You may even have various software in your stack that helps your brand and individual SKUs get preferential ranking on Google Search.
Well, times are tightening. Now you want to get everything humming along better. Because you are a consumer business, you are getting hosed on CAC. All of the platforms are competitive across all types of audiences because there are so many consumer brands competing for limited mindshare. You want to improve CAC, which means analyzing your Google Ads spend and potentially reducing it. You may even divest in your Firebase app (did you really need that app?) or on other Google product lines.
Uh oh, as you’ve scaled-up and matured you may be spending less on the Google products you use to run your business. This is a potential threat to Google.
But to know where to tinker with margins and reallocate spend and create new and better audiences and segments, you need to crunch some numbers. You need to do some analytics and maybe even some machine learning.
So what do you do as your business scales up, becomes more complex, and you hit a point where Google may actually start making less money on you?
You hire a data team to help optimize. Because Google’s ecosystem is tight, most of their product lines plug right into Google Storage and Google BigQuery seamlessly. You don’t even need to buy ETL middleware to help connect everything. All of your Google Ads and Google Firebase and Google Analytics data is right there for you — right in BigQuery! You can start crunching away and learning more about how to tinker with margins and reallocate spend and build incrementally better audiences and segments.
After a few months — wow — the data Holy Grail has been reached!
As it turns out, your optimal marketing mix should not be 70% Google Ads and 30% Facebook. Instead, it should be 64% Google Ads and 36% Facebook. The marketing team makes some adjustments and claims a big win. CAC improves in the tens of cents.
The data team is hailed as victors over Google Ads. Look at all that money the company was lighting on fire before the data function arrived to save the day. With better marketing mix modeling and some machine learning serving up better audience retargeting and creating better customer experiences, plus a suite of bespoke BI dashboards now in place, no longer will marketing waste a few extra million dollars a year on Google Ads.
But wait!
The company is saving a few extra million on Google Ads. But to figure that out, they used Google Cloud Platform’s BigQuery and storage and a few other services, and wow, they’ve started spending $60k a month there, and it doesn’t seem to be growing linearly, it’s a tad exponential even as the team makes more DAGs and makes more dashboards and volumes of data ingested and stored increase.
Plus, now the business has five data employees — the director, two analytics engineers, a data engineer, and a machine learning engineer. Altogether, with benefits, insurance on the employees, and salaries, that’s coming out to just over $1M a year.
So wait a minute.
The business wanted to improve CAC. They cut some Google Ads spend and gave less money to Google there. But to figure this out, they used Google Cloud Platform storage and compute consumption to crunch the numbers because Google’s products all plug into GCP well. So they gave more money to Google there.
And they realized the Google Firebase app never really accomplished much. It hardly had any usage that materially impacted returning customer sales. However, the website needs to be invested in even more. So the business will wind down Google Firebase, but invest in Google Analytics 360 to get even more and better data off the website. So they’ll spend less on Google Firebase, but more on Google Analytics.
Congratulations.
You’re at the Google Casino. All you’ve effectively done is move from the blackjack table to the roulette wheel. You swapped out budget at your own company from one team to another and you’ve swapped out spend on a few Google products for a few other Google products.
The casino always wins.
Snowflake is a Table Game in the AWS Casino

To truly understand why Snowflake is a table game, you have to understand the supply chain of the cloud, which behaves like almost any other supply chain.
As Jeff Bezos has said, when describing Amazon’s e-commerce business: “Your margin is my opportunity.”
The promise of Amazon.com is that with their scale and technology advantage, they can remove all sorts of rent-taking middlemen along the process. Instead of retailers selling brands via Amazon, Amazon wants the brands to do it directly. It’s one fewer middleman taking margin. In fact, instead of brands sourcing from China and South Asia, Amazon welcomes manufacturers to sell direct. Boom. Now the brand is a middleman. This middleman is removed too.
Amazon came into the supply chain, made its own rules, and can now shake down any party listing items on Amazon.com with pay-to-play ads, control of page placement, and control over search and category definitions. Amazon sets the rules because they control customer attention and their logistics network controls the full last mile. They have significant mindshare on the demand side and can leverage this across the value chain.
However, the AWS and Amazon e-commerce businesses couldn’t be any more different from a supply chain perspective. AWS gets leverage from controlling supply, where Amazon.com gets leverage from controlling demand.
AWS doesn’t sell robust business suites and business productivity applications like Google and Microsoft, its two nearest cloud rivals. You want a spreadsheet? What are the two most obvious solutions? MS Excel or Google Sheets. You want an email suite for your business? Outlook or Gmail. Business intelligence tool? Microsoft has the widely distributed PowerBI and Google has Data Studio and Looker, now wrapped up under one brand. The list goes on. These two businesses can sell from the front, distributing these applications in year one of a customer relationship, then upselling to more compute-driving solutions in years two and three.
So what is poor AWS to do? Well, they sell from the back. They even have services like Redshift among many others that are built on other lower-level services. By controlling the lower level services and then charging both their own higher level services and external vendors and customers, they always get paid back and the money always trickles back to the lower levels, especially S3 and EC2.
This is important because it is why companies like Snowflake exist, taking on the risk of distribution and getting margin as reward for their risk. AWS gets paid back no matter what back to their lower level services. Sure, the Redshift group at AWS may not like Snowflake very much, but other teams getting paid back do not care, and when the internal transfer prices at AWS seem to have parity with external transfer prices they definitely do not care all that much.
This separation of services into their own P&Ls and of services charging back other services is also what makes Snowflake exist at its scale. Snowflake has to take margin because they are a distributor, a middleman.
Taking a supply chain example, Snowflake can open new markets that AWS’ Redshift could not penetrate on their own. By removing the need for DBAs and DevOps skills that Redshift may require, thus lowering the bar to adoption, Snowflake is able to sell to two groups where Redshift has historically seen friction: LOBs in large businesses and consumer startups.
For LOBs in large businesses, it’s often a huge endeavor to get developer resources needed to set up and configure Redshift. A VP of Marketing who wants to or has been told to use Redshift as the compute center for a CDP initiative would have to budget for developer time upfront and as ongoing maintenance to help manage Redshift. This developer time could be from an internal team or perhaps an outside consulting firm. Time will be spent figuring all this out and budgeting for it. This creates friction. With Snowflake, this friction is largely removed. A project that would have taken 9 months to even scope and budget and plan out can be reduced to 3–4 months with Snowflake, at least in theory. This puts revenue on the books for Snowflake and, more importantly, it puts revenue on the books earlier for AWS.
For startups, especially consumer startups and especially in retail/e-commerce, Snowflake is an attractive option. It’s notoriously hard for retail startups to hire engineers (these companies often don’t pay as well as software and infra) and by using Snowflake they don’t have to expend as many engineering resources.
The result here is that Snowflake’s entire business is a) margin and b) unlocking compute for AWS, which ends up reflected in what Snowflake calls on their disclosures Remaining Performance Obligations, or the amount of booking commitments they have sold net of what has actually been used.

This is also why many who have worked with Snowflake in engineering capacities over time can recognize all of the rent-seeking behavior on this platform. Overriding a number of default settings is key to shaving off unnecessary spend. Don’t even get me started on default “micro partitioning” which at any reasonable scale will likely have to be overwritten because performance can suffer.
Just like a restaurant has to buy alcohol from a distributor at scale for the distributor to play ball and offer unit discounts and other sweeteners, Snowflake customers too need to operate at scale — usually in a few hundred thousand a year — to get their distributor to play ball and meaningfully discount credits. For everyone else, you better be reading documentation and treading carefully. If you don’t know the game you are playing, the house edge only increases.
So if Snowflake is a Table Game, and BigQuery is Part of the Google Casino, What Do You Do?

- Learn basic Big O as a concept. I’ve never seen this brought up once around any of this “OLAP on the Cloud” or Modern Data Stack world. Gee, I wonder why. Whether you like it or not, when you write SQL on a cloud OLAP you are creating an algorithm and a cash flow. The longer it takes to run a SQL statement, the more “out of date” the data is on a dashboard and the more compute you exhaust. If you are creating exponentially ridiculous cash flows out of your business by creating n² SQL on high cardinality joins, you are gambling your salary and if you’re an American, likely your health insurance. When you’re at the craps table, stick with betting the Pass Line/Don’t Pass. Don’t worry about playing all of the shiny prop bets they put on the table for you that give the house an extra edge.
- Realize that when you make DAGs and “chained SQL CTEs” and other scary things on the cloud you are just making cash flows out of your business. If these can be offset by your business getting value out of your ML model, analysis, insights, dashboard, whatever, then you might be up on the house here. Maybe. But if not, you’re just paying out to the house.
- Do an analysis of what part of your cloud data warehouse costs are eaten by ETL/ELT vs. BI/ML. Monitor this ratio regularly. Or put another way, split out what is eaten up by reads and compute and writes. If you are spending lots on ETL but low on BI/ML usage spend, likely your data team has a large rat nest of SQL compiled to more SQL. dbt Labs is probably the biggest culprit of this these days at certain companies, but it can be a variety of things. Similarly, if your costs are getting eaten up on BI/ML it’s possible that you are not denormalizing or materializing views or tables properly, or you’re not cacheing where this can be strategically leveraged to save mad bucks. It’s best to know what your breakdown is and where costs are getting eaten, then address.
- Become a drywall installer or plumber. These are great jobs that pay six figures without all of the BS.