Our research and analysis point to a new modern data stack that is emerging where apps will be built from a coherent set of data elements that can be composed at scale.

Demand for these apps will come from organizations that wish to create a digital twin of their business to represent people, places, things and the activities that connect them, to drive new levels of productivity and monetization. Further, we expect Snowflake Inc., at its upcoming conference, will expose its vision to be the best platform on which to develop this new breed of data apps. In our view, Snowflake is significantly ahead of the pack but faces key decision points along the way to its future to protect this lead.

In this Breaking Analysis and ahead of Snowflake Summit later this month, we lay out a likely path for Snowflake to execute on this vision, and we address the milestones and challenges of getting there. As always, we’ll look at what the Enterprise Technology Research data tells us about the current state of the market. To do all this we welcome back George Gilbert, a contributor the theCUBE, SiliconANGLE Media’s video studio.

A picture of the new modern data stack

The graphic below describes how we see this new data stack evolving. We see the world of apps moving from one that is process-centric to one that is data-centric, where business logic is embedded into data versus today’s stovepiped model where data is locked inside application silos.

There are four layers to the emerging data stack supporting this premise.

Starting at the bottom is the infrastructure layer, which we believe increasingly is being abstracted to hide underlying cloud and cross-cloud complexity — what we call supercloud.

Moving up the stack is the data layer that comprises multilingual databases, multiple application programming interfaces and pluggable storage.

Continuing up the stack is a unified services layer that brings together business intelligence and artificial intelligence/machine learning into a single platform.

Finally there’s the platform-as-a-service for data apps at the top of the picture, which defines the overall user experience as one that is consistent and intuitive.

Here’s a summary of Gilbert’s key points regarding this emerging stack:

The picture above underscores a significant shift in application development paradigms. Specifically, we’re transitioning away from an era dominated by standalone Web 2.0 apps, featuring microservices and isolated databases, toward a more integrated and unified development environment. This new approach focuses on managing “people, places and things” – and describes a movement from data strings to tangible things.

Key takeaways include:

• A new development paradigm: It centers on the transformation of the technology landscape. It’s moving from a more disjointed world where applications were built as standalone entities using independent microservices and databases to a more cohesive ecosystem where applications are tightly intertwined, catering to more holistic management of entities and objects of interest.
• The complexity of existing platforms: In the current Web 2.0 model, developers often must curate hundreds of services that were not originally designed to work together (such as 200 Amazon Web Services Inc. services). This fragmented ecosystem poses a significant challenge for developers who are expected to stitch together these disparate services into a coherent application.
• Snowflake’s role: Snowflake’s ambition, we believe, stands out in this context. Its goal is to streamline this complexity by offering a unified development environment capable of managing all workloads and data types. Since we believe the future of applications is data apps, this positions Snowflake as a powerful platform for developers, particularly in ecosystems where development services are fragmented, like on Amazon.

This suggests a compelling trend for stakeholders to watch. The advent of a more unified and integrated development environment is a game-changing evolution. It encourages stakeholders to consider solutions like Snowflake, which simplifies and enhances the development process, thereby promoting efficiency, reducing complexity and driving new levels of monetization.

The key question is: Can Snowflake execute on this vision and can they move faster than competitors including the hyperscalers and Databricks Inc., which we’ll discuss later in this research.

Listen to George Gilbert describe the new modern data stack.

North star: Uber-like applications for all businesses

Let’s revisit the Uber analogy that we’ve shared before.

The idea described above is that the future of a digital business will manifest to a digital twin of an organization. The example we use frequently is Uber for business where, in the case of Uber Technologies Inc., drivers, riders, destinations, estimated times of arrival, and the transactions that result from real-time activities have been built by Uber into a set of applications where all these data elements are coherent and can be joined together to create value, in real time.

Here’s a summary of Gilbert’s take on why this is such a powerful metaphor:

We believe the paradigm shift in application development will increasingly focus on applications being organized around real-world entities such as people, places, things and activities. This evolution reduces the gap between a developer’s conceptual thinking and the real-world business entities that need management.

Key points include:

• Real-world coherence: There’s always been a need for building applications that  manage all the entities and activities in an enterprise and its ecosystem. But we’ve never been able to connect to everything and “instrument” it. Data, in the form of transactions, interactions, observations and other telemetry finally gives the digital world an API to the real world.
• Orchestrating real-world activities: In this new era of applications, developers need to orchestrate interactions that aren’t as hard-coded as traditional back-office applications. Analytics has to inform or automate many of these interactions. When less planned interactions and analytics are the objective, all the data and application logic in an enterprise has to be harmonized in a semantic layer. Only then can developers compose applications and inform processes using contextual data from across the enterprise. That’s how AI-based digital operations can match drivers as digital products with riders as digital customers..
• Integrated data management layer: Beneath the semantic layer, there needs to be an integrated data management layer that supports all types of workloads by hiding the complexity of managing different data types, including operational and analytic. Integrated data management enables analytics to inform activities in real time by reducing the need for pipelines to transport and transform data. Calculating a route and a price can’t be a batch process.
• The power of digital twins: This highlights the power of organizing enterprise data so that it represents a high fidelity digital twin of the business. Carefully curated data becomes an enterprise’s API by which it can inform and automate products and processes in ways never before possible.

We believe the vision presented by Gilbert has profound implications for those involved in application development. It’s important for stakeholders to realize that the new era of applications calls for a different kind of thinking – one that aligns with orchestrating real-world activities through a unified, coherent development environment. This has the potential to increase efficiency dramatically and enable more complex, autonomous operations.

Watch and listen to George Gilbert describe the future of application development and the key enablers.

Simplifying application development for mainstream organizations

A major barrier today is that only companies such as Uber, Google LLC, Amazon.com Inc. and Meta Platforms Inc. can build these powerful data apps. Starting 10-plys years ago, the technical teams at these companies have had to wrestle with MapReduce code and dig into TensorFlow libraries in order to build sophisticated models. Mainstream companies without thousands of world class developers haven’t just been locked out of the data apps game, they’ve been unable to remake their businesses as platforms.

To emphasize our premise, we believe the industry generally and Snowflake specifically are moving to a world beyond today’s Web 2.0 programming paradigm where analytics and operational platforms are separate and the application logic is organized through microservices. We see a world where these types of systems are integrated and BI is unified with AI/ML. And a semantic layer organizes application logic to enable all the data elements to be coherent.

In our view, a main thrust of Snowflake’s application platform strategy will be to simplify the experience dramatically for developers while maintaining the promise of Snowflake’s data sharing and governance model.

Here are the critical points from the discussion with Gilbert on this topic:

• Prototypical next-gen apps: We believe Uber-like applications are the prototype for the next generation of apps, which utilize analytics to orchestrate real-world processes. However, the challenge lies in the fact that these kinds of apps are currently predominantly within the purview of tech behemoths such as Uber, Google and Amazon.
• Complex development process:  In the past, building these applications required cobbling together dozens or hundreds of different low-level services. It was worse than the equivalent of assembly language programming. At least assembler code runs on the same processor. Integrating independent tools and services meant different extensibility and admin models, among other things.
• Democratization of app development: We believe a key goal is to bring this kind of advanced application development capability to mainstream organizations in a packaged platform. Snowflake and Databricks are attempting to do exactly this for data applications. Others will undoubtedly follow.
• Empowering mainstream developers: The primary goal here is to ensure that sophisticated data applications do not require world-class developers but can be created by mainstream developers using a packaged platform.

Our research points to a vital trend for observers to monitor. The democratization of app development capabilities through platforms such as Snowflake and Databricks. This is fundamental in our view and the shift has the potential to level the playing field, allowing a wider range of organizations to harness the power of sophisticated data applications.

Listen and watch George Gilbert explain today’s complexity challenge and the new model application development.

Snowflake will continue to support more data types

Snowflake bristles at the idea that it is a data warehouse vendor. Although the firm got its foothold by disrupting traditional enterprise data warehouse markets, it has evolved into a true platform. We think a main thrust of that platform is an experience that promises consistency and governed data sharing on and across clouds. The company’s offering continues to evolve to support any data type through pluggable storage and the ability to extend this promise to materialized views, which implies a wider scope.

We believe the next wave of opportunity for Snowflake (and its competitors) is building modern data apps. It’s clear to us that Snowflake wants to be the No. 1 place in the world to build these apps – the iPhone of data apps, if you will. But more specifically, Snowflake in our view wants to be the preferred platform, meaning the fastest time to develop, the most cost-effective, the most secure and most performant place to build and monetize data apps.

The following summarizes our view and the conversation with Gilbert on this topic:

One of the core principles of this new modern data stack is supporting all data types and workloads, with Snowflake being a key player in this regard. We believe Snowflake is essentially revolutionizing the data platform, providing a more simplified, yet potent tool for developers to work with.

Crucial points from our analysis include:

• All data types and workloads: Snowflake’s strategy centers on supporting all types of data and workloads, starting with online analytic processing or OLAP data and gradually incorporating online transaction processing or OLTP data through hybrid tables. The aim is to provide a unified platform to simplify the developer’s work.
• Pluggable storage: Snowflake is progressively opening up the DBMS to accommodate pluggable storage, enabling support for different types of data, such as streaming data, graph data, and vector data. The ability to handle a variety of data types through a single execution engine significantly simplifies the burden on the developer. One execution engine should be able to manage data without the developer needing to worry about moving, translating or caching the data. Snowflake appears likely to accomplish this even across different data types. That would represent significant simplication through unification.
• Materialized views: Materialized views can serve as a type of cache for frequently queried data. Snowflake can now manage this cached data so that BI tools or metrics layers are able to access live data. Previously, they had to periodically extract the data and materialize it outside the database. Once outside the database, the data was stale and ungoverned.
• Interoperability with different database types: The concept of pluggable storage, which refers to the ability to support various database types and formats, is fundamental. We don’t fully understand the extent of support for cross-database joins and transactions, but the potential power to transform the way databases interact is clear to us. We will continue to probe in our research to come to some conclusions as to how far Snowflake can and will take this concept.
• Iceberg tables: Originally, Iceberg was an external data format. Snowflake support was one step above an import utility. Now Iceberg tables are considered native. That removes the last distinction between Snowflake and the lakehouse architecture. Lakehouses were distinguished by the ability of any compute engine to read and write tables directly in the file system. Many tools and libraries, especially those supporting data scientists, need to work with data sets but support a file system interface and not a SQL interface. That’s possible with native Iceberg tables. With all the additional services Snowflake can layer on Iceberg tables, the format should be an attractive target.
• Unified framework: The true value-add by Snowflake is its ability to manage multiple data types in multiple storage providers through a single execution engine. We’ll have to see to what extent it can hide that plumbing, for example executing joins or transactions across storage providers.

Bottom Line: Our research points to a transformative shift in data management. In the legacy era when everything was on-premises, Oracle managed the operational data while Teradata and others, including Oracle, managed separate analytic data. Snowflake aspires to manage everything from that era and more.  Snowflake’s pursuit of unification and simplification offers a considerable boon for developers and organizations alike, paving the way for a future where handling diverse data types and workloads becomes commonplace. This trend is one to watch closely, as it could profoundly shape the data management landscape.

Watch this five-minute deep dive into where we see the Snowflake platform architecture heading.

Unifying business intelligence with AI and machine learning

Unifying BI and AI/ML is a critical theme of the new modern data stack. The slide below shows Snowflake on the left hand side, Databricks on the right, and we see these worlds coming together.

The important points of this graphic and  the implications for Databricks, Snowflake and the industry in general can be summarized as follows:

The dynamics between Snowflake and Databricks, two key players in the field of business intelligence and AI/ML, are evolving rapidly. Snowflake has made strides in order to try and eliminate the need for Databricks in some contexts, while Databricks is attacking Snowflake’s stronghold in analytics.

To date, if a customer wanted the best BI and AI/ML support, they needed both Databricks and Snowflake. Each is trying to be a one-stop-shop. Customers should not have to move data between platforms to perform alternately BI and AI/ML.

There has been talk that it would be harder for Snowflake to build Databricks’ technology than vice-versa. The assumption behind that thinking seems to be that BI is old, well-understood technology and AI/ML is newer and less well-understood. But that glosses over the immense difficulty of building a multiworkload, multimodel cloud-scale DBMS. It’s still one of the most challenging products in enterprise software. As Andy Jassy used to say, there’s no compression algorithm for experience. While others are catching up with BI workload support, Snowflake has moved on to transactional workloads and now pluggable data models.

On the tools and API side, Snowflake is adding new APIs to support personas that weren’t as well-supported, such as data science and engineering.

The dynamics between Snowflake and Databricks, two key players in the field of business intelligence and AI/ML, are evolving rapidly. Snowflake has made strides in order to try and eliminate the need for Databricks in some contexts, while Databricks is attacking Snowflake’s stronghold in analytics.

Key points include:

• Scale-Out Python Pandas Support: Snowflake’s support for Python Pandas is a significant headline, as Python Pandas programmers might now outnumber SQL programmers. Traditionally, Pandas ran on a single core of a single CPU, necessitating a rewrite for large scale data analysis or pipeline production. However, a company called Ponder has re-implemented Pandas to run on scale-out compute execution engines and has implemented this on Snowflake. This allows Python Pandas code from a laptop to be scaled out directly to run on the Snowflake cluster with very high compatibility.
• LLM Access: Another analytical persona Snowflake is targeting is the end-user accessing data via natural language using an LLM. Large Language Models allow for natural language querying of data. Snowflake’s approach will likely offer LLM access not only to structured data but also complex information contained in documents, images, and videos. We expect their acquisition of vector search technology will enable them to query traditional BI as well as contextual information.
• Graph data: Much data is linked and the links contain value. Customer, security, operations, and other data can yield significantly more value if it is analyzed with all its links providing context. We believe Snowflake will be able to return a graph of data as query result. That would be a significant step in integrating graph data into mainstream applications.
• Blurring Boundaries: With direct access to Iceberg tables, traditional data science libraries such as PyTorch or TensorFlow are now first class citizens in a Snowflake shop. MLOps tools that don’t know how to talk to a DBMS can now also work with native Iceberg data.
• Operationalizing Data through Data Apps: Breaking the artificial distinction between BI and AI/ML will help developers apply whichever type of analytics is appropriate. Just the way the semantic layer will unify data and application logic, analytics has to be unified as a supporting building block.

Our research indicates that Snowflake is making significant strides towards becoming a one-stop solution that can cater to all data types and workloads. This paradigm shift has the potential to substantially alter the dynamics of the industry, making it a top level trend to follow for analysts and businesses technologists.

Basically you’ll be able to take your laptop-based, Python and Pandas data science and data engineering code, and scale it out directly to run on the Snowflake cluster with extremely high compatibility. The numbers we’ve seen are 90% to 95% compatibility. So you might have this situation where it’s more compatible to go from Python on your laptop to Python on Snowflake than Python on Spark. So that’s an example of one case where Snowflake is taking the data science tools that you used to have to go to Databricks for and supporting them natively on Snowflake.

Watch this four-minute deep dive into how Snowflake is unifying BI and AI/ML workloads.

Databricks’ presence in Snowflake accounts

We’re going to take a break from George’s excellent graphics and come back to the survey data. Let’s answer the following question: To what degree do Snowflake and Databricks customers overlap in the same accounts?

This is the power of the ETR platform where we can answer these questions over a time series.

This chart above shows what the presence of Databricks is inside of 302 Snowflake accounts within the ETR survey base. The vertical axis is Net Score or spending momentum and the horizontal axis shows the overlap. We’re plotting Databricks and we added in Oracle for context.

Thirty-six percent of those Snowflake accounts are also running Databricks. That jumps to 39% if you take Streamlit out of the numbers. And notably this figure is up from 17% two years ago and 14% two years ago without Streamlit.

The point is Databricks’ presence inside of Snowflake accounts has risen dramatically in the past 24 months. And that’s a warning shot to Snowflake.

As an aside, Oracle is present in 69% of Snowflake accounts.

 Snowflake’s presence in Databricks accounts

Now let’s flip the picture — in other words, how penetrated is Snowflake inside Databricks accounts, which is what we show below. As you can see, that number is 48%, but that’s only up slightly from 44% two years ago. So Databricks, despite the growth of Snowflake over the past two years, is more prominent in terms of penetrating Snowflake accounts.

Here’s our summary of the overlap between these two platforms:

We believe the maturity of organizations in terms of their data platform utilization is evolving rapidly. The increasing overlap between Snowflake and Databricks can be seen as a response to these companies’ realization that to extract maximum value from their data, they need to address both business intelligence and AI/ML workloads.

Key takeaways from this analysis include:

• Increasing overlap: As companies aim to maximize the potential of their data, they’ve realized the necessity of addressing both business intelligence and AI/ML workloads. This realization has led to an increasing overlap between Snowflake and Databricks.
• Snowflake’s progress: Snowflake has made substantial strides in addressing data science and engineering workloads, which were traditionally Databricks’ areas of strength.
• Databricks’ response: Databricks, while not static, still needs to evolve in the face of Snowflake’s advancements.
• Likely future outlook: Given the current trajectory, less account overlap between Snowflake and Databricks might be expected over the next 12 months.

Our research indicates a dynamic environment where data platforms are progressively diversifying their capabilities. With Snowflake making notable progress in addressing data science and engineering workloads, organizations may need to reassess their data strategy to maximize value from these evolving platforms. Databricks is not standing still and its growth rates, based on our information, continue to exceed those of Snowflake, albeit from a smaller revenue base.

The critical semantic layer

Let’s now jump to the third key pillar, which brings us deeper into the semantic layer.

The graphic below emphasizes the notion of organizing application logic into digital twins of a business. Our assertion is this fundamentally requires a semantic layer. This is one area where are research is inconclusive with regard to Snowflake’s plans. Initially we felt that Snowflake could take an ecosystem approach and allow third parties to manage the semantic layer. However, we see this as a potential blind spot to Snowflake and could pose the risk of losing control of the full data stack.

A summary of our analysis follows:

The semantic layer is starting to emerge as BI metrics. These metrics, like bookings, billings and revenue, or more specific examples like Uber’s rides per hour, were traditionally managed by BI tools. These tools had to extract data from the database to define and update these metrics, which was a challenging and resource-intensive process.

The First Step: Business Intelligence Metrics

Semantic layer implementation: Snowflake in our view intends to take on the critically demanding task of supporting these metrics. It will cache the live, aggregated data that will allow BI tool users to slice and dice by dimension. We believe it plans to support third parties, such as AtScale Inc., dbt Labs Inc. and Google-owned Looker, to define the metrics and dimensions. Previously, such tools typically had to cache data extracts outside the DBMSs themselves. This approach fits with Snowflake’s business model of supporting an ecosystem of tools.

In essence, we believe that that if Snowflake’s approach to handling the semantic layer within its platform is to leave that to third parties, it might be too narrow and potentially misses the broader implications and challenges of application semantics.

Watch this three-minute clip describing the importance of the semantic layer and the risks to Snowflake of not owning it.

Roadmap: Why Snowflake might vertically integrate the semantic layer

Let’s double-click on this notion of the semantic layer and its importance. Further, we want to explore what it means for Snowflake in terms of who owns the semantic layer and how to translate the language of people, places and things into the language of databases.

 

 

 

 

 

 

 

 

 

 

 

 

Implications for the full semantic layer

• BI metrics are not full application semantics: If Snowflake plans to let third parties handle the semantics of BI metrics, then it raises questions about the broader semantic layer in applications. We don’t believe Snowflake can take this same approach with full application semantics. It worked with BI metrics because they translate directly into a data element the database already manages, a view. Full semantics are far more complex because they included complex processes, sometimes including access to external applications.
• The need for an integrated stack: If Snowflake leaves this to 3rd parties, there will either be a jarring impedance mismatch for developers, or a layer that would enable to abstract away Snowflake’s core data management functionality. Snowflake’s vision is to deliver Apple-like full-stack simplicity to developers. Developers worry about “things,” Snowflake translates that and manages the “strings.” To achieve that, it needs to build this layer and the technology to map it down to its world-class data management platform.

In essence, we believe that if Snowflake’s approach to handling the semantic layer within its platform is to leave it to third parties, they may lose control of the application platform and their destiny.

Snowflake aspires to build a platform for applications that handles all data and workloads. In the 1990s, Oracle wanted developers to code application logic in their tools and in the DBMS stored procedures. But Oracle lost control of the application stack as SAP, PeopleSoft and then the Java community around BEA all built a new layer for application logic. That’s the risk if Snowflake doesn’t get this layer right.

Watch this two-minute riff on why Snowflake may want to vertically integrate the semantic layer.

The leading data platforms all want a piece of the action

Let’s examine the horses on the track in this race. The Belmont stakes is this weekend. It’s a grueling, mile-and-a-half race… it’s not a sprint. Below we take a look at the marathon runners in the world of cloud data platforms.

The graphic above uses the same dimensions as earlier, Net Score or spending momentum on the Y axis and the N overlap within a filter of 1,171 cloud accounts in the ETR data set. That red line at 40% indicates a highly elevated Net Score.

Microsoft just announced Fabric. By virtue of its size and simple business model (for customers), it is furthest up to the right in spending metrics and market presence. Not necessarily function but the model works. AWS is “gluing” together its various data platforms that are successful. Google has a killer product in Big Query, with perhaps the best AI chops in the business, but is behind in both momentum and market presence. Databricks and Snowflake both have strong spending momentum notwithstanding that Snowflake’s Net Score has been in decline since the January 2022 survey peak. Howeve, both Snowflake’s and Databricks’ Net Scores are highly elevated.

Here’s our overall analysis of the industry direction:

The big change is we believe the market will increasingly demand unification and simplification. It starts with unifying the data, so that your analytic data is in one place. So first, there’s one source of truth for analytic data. Then we’ll add to that one source of truth all your operational data. Then build one uniform engine for accessing all that data and then that unified application stack that maps people, places, things and activities to that one source of truth.

Here’s our assessment of the leading players:

1.  Snowflake: Is unifying both the analytic and operational data (and all its forms) under a single DBMS engine with multiple personalities. However, it’s still to handle the mapping of semantics of real-world entities (people, places, things, activities) to any data format they manage.
2. Microsoft and Databricks: Microsoft has standardized all of its analytic data on the Databricks’ data format. So there’s one source of truth at the storage layer in the Microsoft ecosystem, which is powerful. However, it has yet to integrate operational data, which is a challenge as the Delta table format is not conducive for operational data. There are workarounds using changed data capture, but there is latency involved.
3. Amazon: It still really has a separate data lake and data warehouse, which are distinct structures. Data is accessible from one to the other through connectors. Still, the data lake data isn’t natively supported for the data warehouse.
4. Google Cloud Platform: Although it maintains a full separation of compute and storage, data stored in Google BigQuery isn’t the same as a data lake. With a data lake data, users query it as if it were external data – that is, it has yet to unify all of its analytic data platforms in a single format and single data engine. However, our research suggests they’re working on it and making progress. We expect to hear more this summer at Google Cloud Next.

The overall theme of our analysis suggests that these major providers are working towards consolidating and streamlining their data architectures to facilitate a single source of truth, including both analytic and operational data, making it easier to build and manage data apps. However, each of these platforms has its unique set of challenges in achieving this goal.

Listen and watch this four-minute discussion where George Gilbert goes through the maturity model for each vendor with respect to unifying data.

Key questions to watch at Snowflake Summit 2023

Let’s close with the key issues we’ll be exploring at Snowflake Summit and Databricks events, which take place the same week in late June. We’re going to start at the bottom layer of the stack in the chart below and work our way up the stack down on this slide.

Before we get into the stack, one related area we’re exploring is Snowflake’s strategy of managing data outside the cloud. It’s unclear how Snowflake plans to accommodate this data. We’ve seen some examples of partnerships with Dell Technologies Inc., but at physical distances there are questions about its capacity to handle tasks like distributed joins. We wonder how it would respond if data egress fees were not a factor.

Moving to the stack:

1. Software layer and pluggable storage engines: The timeline and details for supporting features such as materialized views and cross-engine transactions are also unclear and something we’ll be watching.
2. Unified service layer: There are questions about which APIs Snowflake will support, when and how this will occur. There are also uncertainties about how companies such as dbt, Looker and AtScale Inc., which define metrics, will function within Snowflake’s environment.
3. Semantic layer and AI: Questions remain about Snowflake’s plans for the semantic layer and the impact of large language models and AI on their operations. Recent acquisitions seem to give Snowflake options to attack this opportunity.
4. PaaS for data apps: It’s somewhat unclear how Snowflake’s app store will handle discovery and monetization, and how this evolution will proceed.

We expect to get more clues and possibly direct data from Snowflake (and Databricks) later this month.

As well, we continue to research the evolution of cloud computing. We’re reminded of the Unix days, where the burden of assembling services fell on the developer. We see Snowflake’s approach as an effort to simplify this approach by offering a more integrated and coherent development stack.

Lastly, Snowflake plays in a highly competitive landscape where companies such as Amazon, Databricks, Google and Microsoft constantly add new features to their platforms. Nonetheless, we believe Snowflake continues be ahead and has positioned itself as a company that can utilize the robust infrastructure of the cloud (primarily AWS) but simultaneously simplify the development of data apps.

On balance, this will require a developer tools mindset and force Snowflake to move beyond its database comfort zone — a nontrivial agenda that could reap massive rewards for the company and its customers.

Keep in touch

Many thanks to George Gilbert for his collaboration on this research. Thanks to Alex Myerson and Ken Shifman on production, podcasts and media workflows for Breaking Analysis. Special thanks to Kristen Martin and Cheryl Knight, who help us keep our community informed and get the word out, and to Rob Hof, our editor in chief at SiliconANGLE.

Remember we publish each week on Wikibon and SiliconANGLE. These episodes are all available as podcasts wherever you listen.

Email david.vellante@siliconangle.com, DM @dvellante on Twitter and comment on our LinkedIn posts.

Also, check out this ETR Tutorial we created, which explains the spending methodology in more detail. Note: ETR is a separate company from Wikibon and SiliconANGLE. If you would like to cite or republish any of the company’s data, or inquire about its services, please contact ETR at legal@etr.ai.

Here’s the full video analysis:

All statements made regarding companies or securities are strictly beliefs, points of view and opinions held by SiliconANGLE Media, Enterprise Technology Research, other guests on theCUBE and guest writers. Such statements are not recommendations by these individuals to buy, sell or hold any security. The content presented does not constitute investment advice and should not be used as the basis for any investment decision. You and only you are responsible for your investment decisions.

Disclosure: Many of the companies cited in Breaking Analysis are sponsors of theCUBE and/or clients of Wikibon. None of these firms or other companies have any editorial control over or advanced viewing of what’s published in Breaking Analysis.

Image: Dennis/Adobe Stock