It seems one of the two words above applies to Snowflake’s (NYSE:SNOW) IPO action, depending on your point-of-view. When I wrote my first article on the company a few days before the IPO (and while the original IPO range was still “intact”) I never imagined trading well above $200/share. I am still flabbergasted.
Post-mania, a number of bears have expressed their doubts about the company. Rightfully, many have questioned the company’s valuation (currently ~$63B). Others have made arguments against the technology itself, suggesting – among other things – weak differentiation and uncertainty around its long-term viability. I concern myself with these technology-centric arguments in this report, as they are worthy of discussion. As usual, there are counter-arguments to be considered.
A quick note on valuation: I tend to agree with those analysts who believe the company’s current capitalization to be a bit frothy. That being said, I do not delve into any detailed (quantitative) commentary on that point in this report. Several other Seeking Alpha authors have tackled the subject head-on, so I encourage readers to review those articles on the site.
After having the opportunity to read a few bearish articles, I consolidated 10 attack-lines, along with their key themes. These are listed below. As Google (GOOGL), Microsoft (MSFT), and Amazon (AMZN) are mentioned a number of times – as they simultaneously serve as Snowflake’s cloud infrastructure providers and most significant threats – I will, on occasion, simply refer to them as the “Big 3”.
1. Google, Microsoft, and Amazon have competing solutions that are only going to get better. Google BiqQuery, Amazon Redshift, and Microsoft Azure SQL Data Warehouse have been mentioned quite a bit since Snowflake hit the public market. Google BigQuery, based upon the company’s Dremel technology, can provide incredibly fast ad-hoc analysis of massive (petabyte-scale) datasets with compute and storage layers that can scale independently. The company is now pushing to extend its capabilities beyond its native storage infrastructure to both Amazon AWS and Microsoft Azure via BigQuery Omni; thus allowing customers to perform queries across large datasets that exist in multi-cloud environments. Microsoft Azure SQL Data Warehouse, which is now being bandied around as Microsoft Azure Synapse Analytics (“Synapse”), is another powerful offering – as it should be based on Microsoft’s legacy in data management technology. Synapse also supports massive scalability via decoupled compute and storage. While not exactly on par with Google’s BigQuery Omni offering, Microsoft has recently provided certain data lake capabilities that allow customers to link to data external to Azure, and query / analyze that data within a Synapse environment. Amazon Redshift, which Amazon claims is in use by “tens-of-thousands” of customers, ranging from startups to Fortune 500 companies, can also operate at petabyte-scale; and its new RA3 instances decouple the storage and compute layers providing matching flexibility in regard to scaling alongside BigQuery and Synapse. I am in full agreement with the bears that these 3 platforms are becoming “stronger, faster, better” with each passing day, and collectively represent a potent threat.
2. As a small fish in a big ocean, Snowflake will eventually be drowned out. In aggregate, Google, Microsoft, and Amazon account for nearly 60% of all cloud spend.
Figure 1: Cloud Spend by Provider
In my previous article on Snowflake, I estimated the company could close its fiscal FY ’21 with $600M+ in revenue, a respectable achievement for such a young company. Even so, it is easy to “see” that this result when quartered is just a drop in the bucket compared to the total multi-billion dollar cloud spend in the previous figure. Moreover, the figure shows the share among the Big 3 increasing as the overall market increases. That dynamic certainly could serve to throw Snowflake’s budding trajectory off-course.
3. Google, Microsoft, and Amazon could raise their prices, pressuring Snowflake’s ability to compete. Snowflake acknowledges this specific risk in their S-1 in a more comprehensive evaluation of their overall risks as a consumer of the Big 3’s infrastructure:
“There is risk that one or more of these public cloud providers could use their respective control of their public clouds to embed innovations or privileged interoperating capabilities in competing products, bundle competing products, provide us unfavorable pricing, leverage its public cloud customer relationships to exclude us from opportunities, and treat us and our customers differently with respect to terms and conditions or regulatory requirements than it would treat its similarly situated customers.”
4. Snowflake’s ability to innovate is partially governed by its infrastructure providers. The quote above elicits this point as well. Indeed, the advantage that Snowflake offers its user base in terms of a fully managed environment is also a disadvantage in that the company does not control it.
5. There are open-source alternatives. Greenplum Database and Altinity Clickhouse are two such offerings, the latter stating that it “...is the first open source SQL data warehouse to match the performance, maturity, and scalability of proprietary databases like...Snowflake”. Open source technologies can, of course, be cheaper to implement, operate, and maintain in certain circumstances; and they provide the benefit of community-driven development. Organizations concerned about data management vendor lock-in will naturally consider solutions like these over proprietary solutions such as Snowflake.
6. Other offerings are more specialized. Some bears have suggested that specialized data management platforms, such as MongoDB’s (MDB) document storage engine, will also cut into Snowflake’s market opportunity as they themselves continue to grow. As a preview into one of my counter-arguments, I am a bit less convinced by this suggestion. But, it is not an unreasonable point, and thus I state it here.
7. Competing solutions can separate compute from storage. One of the advantages Snowflake offers its customer base is to only pay for what they use in terms of computational processing and data storage. This ability to “scale up” and “scale down” is cost-efficient, and the model is contrary to legacy platforms such as Teradata (TDC) and Oracle (ORCL). However, as already stated in the first point above, this capability is not at all unique to Snowflake.
8. Elements of Snowflake’s architecture are not innovative. I saw mention of the company’s hybrid shared-disk / shared-nothing design, which is one component of the platform’s overall architecture, helping to enable its decoupling of compute and storage resources. It is a valid observation that this design is not a radical innovation, but merely a technical choice.
9. Elements of Snowflake’s architecture are not defensible. As I read this bearish argument, the thrust – as it struck me – was that Snowflake’s major architectural components could be replicated as they were not necessarily innovations per se, but rather features of an overall technical design that in-and-of-itself was not necessarily innovative. And therefore, such a design could be easily duplicated by new market entrants.
10. Snowflake appeals to small and mid-size companies. In my previous article on the company, I estimated an average trailing-12-month revenue value of $100K for Snowflake’s “lower-spend” customers. This amount may strike some readers as rather paltry, and therefore supportive of the bear theme that the company’s platform is better suited to smaller organizations
As some of the bear arguments above are correlated to one another, I consolidated my response to multiple points where appropriate and as indicated.
In response to points 1 and 2, market dynamics are favorable to Snowflake making it unlikely they will simply be sidelined in the future. Additionally, their focus on large scale analytics gives them an advantage over their larger competitors. It is impossible to dismiss the potential of any or all of the Big 3 to advance their data management platforms to an extent that Snowflake (and other players) becomes more or less irrelevant. Really, this argument could be extended to major data management players in general.
Figure 2: Q1 2020 Forrester Wave of Data Management for Analytics Players
But, as they are the cloud heavyweights, let’s stick with the Big 3 for now. Given their market presence and technological capabilities, how does Snowflake even exist? Shouldn’t the Big 3 have already captured the lion-share of the cloud data warehousing market by now? For example, Dremel (again, the technology underlying BigQuery) has been in production since 2006, years before Snowflake was even founded. Reiterating an earlier point, Amazon RedShift – which was beta-released in 2012 when Snowflake was just getting started – is now in use by tens-of-thousands of organizations. So, how exactly did Snowflake gain entry into a market that is dominated by 3 organizations, each of which is a leading data management technology provider and has enjoyed a much longer runway to develop their offerings? Consider:
So, without question, BigQuery, Synapse, and Redshift will continue to get better and better, making a competitive market even more competitive. But, the idea that Snowflake has no long-term competitive basis against the Big 3 does not completely resonate with me. I, in fact, made a similar assertion against Splunk (SPLK) a couple years ago in one of my older Seeking Alpha articles, suggesting that Amazon would simply destroy them over time. This, of course, has not happened; and Splunk has arguably become something of a “standard” tool for most companies, particularly in regard to security operations. Accordingly, I don’t expect the Big 3 to make things easy, but Snowflake almost certainly has a lot of runway ahead.
In response to points 3 and 4, the Big 3 need to be somewhat cautious using heavy-handed tactics to gain a competitive advantage, as such behavior could alienate other 3rd-party vendors that are bringing value to their platforms. While increases in infrastructure cost will always remain a concern, the economics of the cloud market and Snowflake’s multi-cloud approach help to alleviate the risk. As large as Google, Microsoft, and Amazon are, they still rely upon an ecosystem of 3rd-party vendors to add value to their respective platforms, including Snowflake. Remember that Snowflake is bringing business to these cloud vendors while they are simultaneously competing. If one of the Big 3 were to “attack” Snowflake – for whatever reason – such an action could have much broader repercussions, perhaps pushing other vendors to consider their options lest they too be attacked. The suggestion that Google, Microsoft, or Amazon could introduce valuable platform features which are made available to their native offerings, but deliberately withheld from consumption by 3rd-party vendors is certainly possible. But, again, that approach could backfire in the long-run, and actually drive business to a competing Big 3 vendor who is not resorting to such tactics. Increases in infrastructure pricing will remain a risk. However, Snowflake’s current design helps to mitigate the threat through its multi-cloud strategy. Further, future cost increases are likely to reflect market-wide dynamics. For example, if AWS were to increase the pricing of a set of its compute instances, it is likely that costs for the analogous machine instances for the other major IaaS vendors have also gone up for one reason or another; as AWS would certainly not price itself to be at a disadvantage to its peers. The economics of the cloud market are somewhat self-governing: costs for similar, commodity cloud services tend to rise and fall together across the major providers. Therefore, if Snowflake were, at some point, subjected to a major increase in the cost of its infrastructure services, more than likely all 3rd-party vendors relying upon that infrastructure would recognize cost increases as well. From my point-of-view, it is reasonable to think that increases in infrastructure cost could be passed on to Snowflake’s customers because it would be reflective of market-wide economics.
In response to point 5, open-source alternatives may not be suitable for many organizations as their “hidden” costs could prove to make them more expensive over time than a commercial offering such as Snowflake. While open-source technologies can appear cheaper due to the absence of license and subscription costs, their total cost of ownership (“TCO”) over time can easily exceed commercial solutions. For example, organizations can find themselves investing heavily in development resources to implement and customize such systems, as well as support resources to “keep the lights on”. Such skilled labor usually does not come cheap. In terms of a commercial data management platform like Snowflake, they “release” their customers from such technical burdens, allowing them to focus on their business initiatives rather than managing technology. In my humble opinion, this is one of the main reasons for the rapid market adoption of Snowflake’s platform – they make things “easier, faster, better” for their customers. I, at least, am not convinced that any of the existing open-source alternatives represent a significant threat to Snowflake. Of course, as the broader market matures, new open-source players could emerge with offerings that present a more substantial risk.
In response to point 6, specialized solutions will always exist to support use cases that demand specialized solutions. But this does not necessarily represent a major threat to Snowflake. Some data management technologies are designed for particular data management needs. MongoDB, which was mentioned earlier, is optimized for document-based storage. If you need to store and analyze a lot of social graph data, neo4j is a leading platform. Building on these examples, if a hypothetical organization needed to design a system to accommodate one or both of these data structures, they will naturally seek out tooling – like MongoDB or neo4j – that is optimized for their use case. Conversely, if an organization is looking to establish a data warehouse to support company-wide business analytics needs, they are probably not going to do that with either MongoDB or neo4j because that is (arguably) not the use case that either platform was designed for. This is not to say that there is absolutely no overlap between a technology like MongoDB and Snowflake. However, generally speaking, the use cases that these specialized platforms are geared towards are not necessarily in Snowflake’s “sweet spot” in the first place.
In response to points 7, 8 and 9, there are aspects of Snowflake’s architecture utilizing existing technical concepts, and therefore not individually special. However, the combination of technical design choices has resulted in a unique offering that does stand upon certain innovations. Snowflake offers the 3-tier diagram below to describe their overall architectural model. I have added “simplifying” labels in italics next to each tier.
Figure 3: Snowflake 3-Tier Architectural Model
Snowflake’s underlying storage (database) architecture is columnar, not relational. Columnar data structures lend themselves toward online analytical processing (“OLAP”) use cases – in contrast to online transactional processing (“OLTP”) use cases – as they reduce disk input-output (“I/O”) overhead. In simpler terms, columnar data structures can make the analysis of data much faster, as related data is physically stored closer together on disk making the retrieval of such data less I/O intensive. This, however, is an example of an individual feature that does not, by itself, make Snowflake special. BigQuery, Synapse, Redshift – and a host of other competing solutions – are all columnar. (However, as will be discussed momentarily, Snowflake’s implementation of its columnar storage design is innovative.) Similarly, Snowflake’s decoupling of the compute and storage layers is not unique, as all of the Big 3 offer the same advantage. But, it is worth noting that Snowflake has established its business around this design pattern which is not the case for legacy players such as Teradata or Oracle. Remember that the separation of compute and storage resources in a cloud environment allows customers to scale up or scale down their requirements as needed; which is to say they only pay for what they use. Now, if you are a new market entrant (like Snowflake), you can establish the operations of your business to accommodate the revenue variability in this model: a customer that is spending X dollars per year today may only spend X – Y dollars tomorrow. The operational characteristics of Snowflake’s business must be able to absorb this revenue elasticity. The business operations of legacy competitors, again like Teradata or Oracle, were built around inelastic pricing models that effectively assume steady growth in customer revenues over time. Accordingly, the technical design pattern itself may not be unique to Snowflake; but the combination of the pattern plus the operational characteristics of the business are novel as compared to many competitors who are not just trying to retro-fit their technology to cloud-driven computing, but also trying to retro-fit their business models as well. The bear argument that Snowflake’s overall design could be simply copied by a competitor is somewhat misleading, and the company’s implementation of its columnar storage layer is perhaps a strong example in this respect. Snowflake utilizes an innovative architecture whereby customer data loaded into a virtual warehouse is split into “micro-partitions” (utilizing Snowflake vernacular). Snowflake captures certain information about the data stored in each of these micro-partitions; and this metadata is stored internally at its cloud services layer – “The Brain” layer as I labeled it above. When a customer seeks to run a query against the warehouse, Snowflake interrogates the metadata to determine which micro-partitions contain the requested data; it “prunes” its mapping of data within the system to determine where the data of interest resides. In doing so, the platform can directly scan the relevant micro-partitions, improving the performance of returning a result to the user. So, could a competitor simply copy this scheme? Presumably, Snowflake’s various patents governing its data pruning and storage architecture models would throw a monkey-wrench into that plan. Of course, a vendor could come along with a solution that matches Snowflake’s performance utilizing a completely different approach to optimize query performance. However, the view that Snowflake’s platform can merely be duplicated does not seem accurate.
In response to point 10, Snowflake’s appeal to small and mid-size companies is not a weakness, it is a strength. Of all the bear arguments, I think this one is the weakest. Perhaps Amazon says it best on their landing page for Redshift:
“Redshift powers analytical workloads for Fortune 500 companies, startups, and everything in between. Companies like Lyft have grown with Redshift from startups to multi-billion dollar enterprises.”
Small companies today will become the large companies of tomorrow. Wouldn’t you want to be their enabling data management vendor now, helping to establish a competitive moat for yourself as these smaller customers grow? Furthermore, Snowflake already noted in their S-1 that their customer base “...[includes] seven of the Fortune 10 and 146 of the Fortune 500”, many of which presumably comprise their 50+ customers who spent more than $1M in the trailing-twelve-month period at the time the S-1 was recorded. By my estimation, Capital One – which accounted for 11% of the company’s revenues in FY ’20 – is a $40M+ account. I think it is unquestionable that the number of $1M spend customers is going to increase significantly moving forward. Thus, the company’s ability to “play” at both ends of the sales spectrum is hardly a disadvantage; it is a competitive strength.
At least one analyst has suggested a violent selloff of Snowflake may be the cards. That may be so. Yet, if there is validity to my arguments in the preceding section, the company’s durability may be well-rooted even if its current share price is not.
I had the intention to purchase shares upon writing my first article on the company, when the original IPO range was still on the table. I backed off as the range was steadily increased: it was always clear to me this would be a popular issue, but I think the market got a bit “over its skis” on the stock. So, I personally would welcome a “violent selloff”. Again, I hesitate to attempt to pinpoint a specific “fair” valuation for the company – or even a fair range – but I stand by my original assessment that the long-term prospects for the company appear strong.
This article was written by
Disclosure: I/we have no positions in any stocks mentioned, and no plans to initiate any positions within the next 72 hours. I wrote this article myself, and it expresses my own opinions. I am not receiving compensation for it (other than from Seeking Alpha). I have no business relationship with any company whose stock is mentioned in this article.
Additional disclosure: I am looking for an entry point into SNOW, but I doubt that will appear in the near-term.