February 1st, 2023


There’s a notion that data warehouses could be the next data platform, overtaking SaaS as a paradigm. The new SaaS will be little lamda functions running on tables in Snowflake or Databricks. This is entirely a marketing idea, built on the dreams of building the next great platform, like Windows or iOS, except for the enterprise cloud. Enterpise, cloud, platform. Three magical words to make any VC ready to invest.

Why did SaaS win over on-premise? Superior distribution economics? That’s part of it. SaaS apps pioneered freemium because they started out, as all startups do, as toys. Jira and Dropbox. But Adobe Photoshop could easily be downloaded over the Internet too. In fact, incumbents by default had superior distribution economics because they had virtually free CAC by virtue of their name recognition. SaaS adopted freemium because it arrived in an era of free, open source, and pirated software. Like iTunes releasing $1 songs, it saw that the incumbent pricing strategy left an opening at the bottom of the market. Freemium was a wedge into enterprise, not a religion, and over time, SaaS apps have migrated to more traditional sales models and even exceeded the prices of their on-premise counterparts.

What made SaaS so successful wasn’t its distribution, but it’s a superior means of production. Production means the process by which the end product or (in this case) service is produced. Just like JIT for cars, SaaS allows teams to move faster and more nimbly. You could deploy a dozen times a day, whereas traditional software would release once every few years. SaaS made continuous deployment the new default. New companies had little to no traditional QA. Their users were their QA teams and bugs could be fixed and deployed in an hour before 99% of the userbase even tried the new “version”.

The idea of running services behind VPCs is crazy. Literally the hardest thing about deployment is managing database migrations. The hardest thing about diagnosing a bugs is state. Imagine you’ve just deployed a change with a migration, but your entire database is a black hole. How do you repro without an onerous back-and-forth email thread with a distraught user and distracted admin? What happens when a database admin doesn’t want to upgrade your schema or let you drop a table? Are your apps eternally backwards compatible? Sure, you could have a system where vendors are given control over their schemas (silo’d off in separate, vendored databases), but such a system would inevitably offer that as an option to admins, an option that overwhelmingly would be ignored.

Software is still written by humans who are incredibly hard to coordinate. The more agency individual groups have to solve better defined problems, the more nimbly and quickly they can move. Unless security becomes fundamentally impossible to solve, SaaS’s benefits are not sufficiently negated. Data warehouses are a patch on the problem for back-of-the-house analytics and dashboards, not the app platform of the future.