First things first, what is a warehouse-native app?
As usual, letâs start with a definition:
A warehouse-native app is any SaaS tool that can run on top of a customerâs cloud data warehouse, without the need to ingest and store any data.
In other words, a warehouse-native app vendor enables its customers to bring their own data warehouse (or cloud data platform) to the vendorâs application which then performs tasks using the customerâs data.Â
The data doesnât need to be synced from the customerâs data warehouse to the vendorâs application, which is typically the case with traditional SaaS solutions.
This new software development paradigm, being popularized by Snowflake, is being fueled by the proliferation of the cloud data warehouse.
Whatâs leading to the rapid adoption of the warehouse-native architecture?
The core idea is very simple:
Customers should be able to bring their own data stores to use alongside functionality built by a SaaS vendor so that customers donât have to pay for their own data twice.
Besides cost, there are also security and privacy concerns due to which enterprises donât want their data to leave their environment.Â
Similar to enterprises earlier seeking on-prem solutions, enterprises now want to bring their own cloud platform to the SaaS (not the same as deploying software in a private cloud environment).
Snowflake refers to warehouse-native apps as âconnected appsâ and their traditional counterparts as âmanaged appsâ.
Besides offering a set of functionality, managed apps also manage their customerâs customer data. (I am of the opinion that we need to replace the term âcustomer dataâ altogether).
But thatâs not allâŠ
Besides storing a copy of every customerâs customer data, managed apps also store the data generated as a result of their own product being used by their customers. On the other hand, warehouse-native apps automatically load this data back into the customerâs data warehouse.Â
Letâs break this down using an email marketing tool as an example.Â
Example: Managed Email Marketing App
Before creating a segment or activating a campaign using a traditional email tool, you must either upload CSV files with data about your customers or sync data from your first-party app to the email tool using their API.
The diagram above depicts the flow of data to a managed email marketing tool such as Mailchimp or Customer.io.
The fact that such companies have to store a copy of every customerâs data explains why their pricing model is based on subscribers/profiles â basically, customers have to pay for their own data to be stored at the vendorâs end.
Additionally, all usage data like campaign metrics, subscription status, etc is also stored by the vendors in their own databases, which customers can later download as CSVs or extract and load into their data warehouse using an ELT tool.Â
Example: Warehouse-native Email Marketing App
With a warehouse-native or connected email app, you donât need to upload or sync any data to start using it â you just need to connect your data warehouse to start building segments and campaigns.Â
As you can see above, a warehouse-native app or connected app is like a component that sits on top of a data warehouse and offers certain functionality, which in this case is email marketing.
Connected apps are able to read data from a warehouse, enabling its users to select appropriate tables from the warehouse and then build segments and campaigns using data from those tables.
In terms of sending emails, connected apps either have their own infrastructure or allow customers to connect to yet another email service provider like Sendgrid. Either way, the connected app vendor loads usage data (campaign metrics, etc) back into the customerâs warehouse, doing away with the need for an ELT pipeline.Â
Reverse ETL vs. Warehouse-native Apps
Itâs worth mentioning that thereâs some overlap between reverse ETL tools and warehouse-native apps â both sit on top of a data warehouse but donât store any data while allowing customers to perform certain actions on top of the data.
However, even though reverse ETL tools offer features like sending Slack alerts based on changes to your data, moving data from the warehouse to downstream managed apps remains the primary use case for reverse ETL.
Instead of uploading CSVs or using the managed appâs API to sync data, one can move data from the warehouse to a managed app using reverse ETL as middleware.Â
Similarly, as depicted below, one can move usage data from the managed app back to the warehouse using an ELT tool (or the managed appâs API).
Summary and closing thoughts
Iâd like to conclude this post with a quick summary followed by some thoughts.
A warehouse-native app is any SaaS tool that can run on top of a customerâs cloud data warehouse (or cloud data platform), without the need to ingest and store any data.
Warehouse-native apps are also referred to as connected apps (since theyâre connected to the customerâs own data platform). Their traditional counterparts are referred to as managed apps.
Warehouse-native apps (should) automatically load usage data back into the customerâs data warehouse.
Thereâs some overlap in the functionality of connected apps and reverse ETL tools â both sit on top of a data warehouse but donât store any data at their end, while allowing customers to perform certain actions.
While unlikely to happen anytime soon, connected apps can become more like reverse ETL tools by building destination integrations, allowing customers to also move data downstream to other third-party tools.
On the other hand, reverse ETL tools can potentially enable traditional SaaS companies (managed apps) to embrace the warehouse-native architecture.
To dig deeper into the warehouse-native paradigm, I recommend the following articles from Snowflake:Â
I think there's an additional important difference and that's optimization and query cost. Warehouse-native apps owned by other teams run queries directly on the warehouse, owned the by the data team. With additional queries comes a price, absorbed by the data team. If this doesn't have oversight, it's easy to rack up a pretty hefty Snowflake bill. The optimization of query efficiency and cost is up to the vendor, but most warehouse-native tools are very early and aren't talking about it yet. It remains to be seen if there is an additional cost, and if so, if there's a savings that will make an organization come out net-positive.
Thanks for this post.
When we first moved from on-premise to SaaS, the analogy was it's like plugging your appliance into a socket vs running your own electricity generator at home. SaaS was compelling
Today, indeed, it does feel like each appliance is powered it's own fully integrated electric companies. And those electric companies are sharing data (ELT - RETL) to get 360 view of your house. Now that Warehouses are SaaS, it feels like warehouse native apps are compelling with a singular backend (also in the cloud)
Which are the top Warehouse native apps you're tracking?