Reverse ETL has been the new cool kid on the modern data stack for a couple of years now, and deservedly so. But like many other technologies built around the modern data stack, the emergence of more modern technologies has now deemed the category redundant and legacy. In this blog, I’ll share my thoughts on why I feel Reverse ETL is yet another passing fad, the same way CDPs were referred to earlier.
What is Reverse ETL ?
But what about the other business functions of an organisation, like Sales, Marketing, Customer Success, etc., which have to interact with customers on a daily basis? If the data warehouse holds a 360-degree view of an organisation’s customer data, it is imperative that the customer-facing data-driven business functions also get first-hand access to this data. Now, it is not enough for the Sales and marketing teams to see the data in a dashboard; they would need the data in the tools they use everyday. Thus was born Reverse ETL.
Reverse ETL helps businesses derive value from the customer data lying in cloud data warehouses by syncing them to Sales, Marketing, and Support tools like Salesforce, Hubspot, Intercom, etc.
The Rise of Reverse ETL
It is estimated that SaaS tools account for around 75% of a company’s product stack. The continuing SaaS proliferation triggered the rise in the popularity of Reverse ETL towards the end of 2020. More and more businesses started realising the need to get warehouse data in their sales and marketing tools for more efficient and hyper-personalised customer interactions.
Hightouch and Census emerged as the flag bearers of the category. Open-source alternatives like Grouparoo also sprung into action by providing an option to self-host Reverse ETL on-prem. The sudden rise in popularity of Reverse ETL saw EL(T) providers like Airbyte and Hevodata offering Reverse ETL capabilities. Recently we are also witnessing traditional CDPs trying to provide Reverse ETL as an offering in addition to their native data collection and activation features.
There is no doubt that businesses need to make warehouse data actionable to power their business functions. But do they have to move the data out of the warehouse to derive value from it ?
Enter Warehouse-Native Apps
Instead of moving the warehouse data to the business tools, the existing business tools, like Salesforce, Hubspot, etc., can be rebuilt with the data warehouse as the backend. Such applications are called Warehouse-Native applications. They solve some of the major pain points of traditional business tools out of the box.
- Empowers the business tools with the enormous horsepower of the data warehouse, not just the data.
- Bypasses the data storage restrictions enforced by traditional business tools, for example, Data Retention restriction of 3–6 months by the existing Customer Engagement tools.
- Removes the need to buy and maintain a data pipeline solution like Reverse ETL.
- Eliminates the tedious grind of getting started. All the data needed to interact with customers is already in the cloud data warehouse. Warehouse-Native apps enable businesses to get started with their tools in minutes instead of months with no dependency on engineering teams.
What applications can be built on top of the Data Warehouse?
While considering the Data Warehouse as the backend for a SaaS application, it should be able to support the workloads that the application demands. For example, an application like a CRM needs to run predominantly transactional queries on the data layer. Hence, data warehouses, at the moment, might not be the right choice for a backend for such applications at this stage.
But there are other categories where a warehouse-native approach makes sense even now. For example, Marketing Automation Platforms execute just the batch operations on a segment of customer data in the warehouse. In such cases, Data Warehouse becomes a more cost-effective and robust backend compared to a transactional database. Castled is an example of a Warehouse-Native Customer Engagement Platform.
However, this does not mean warehouse-native apps do not deploy a transactional database internally. For example, warehouse-native apps might optionally use a transactional database to store configurations and other metadata associated with the different entities. But they never keep a copy of the customer data in the warehouse.
The Future of Data Activation
The existing restriction of not being able to build every type of application(like CRMs) on top of the data warehouse is just temporary. Technologies like Snowflake Unistore solve the problem by consolidating transactional and analytical workloads within the same platform. So, very soon, applications built on top of data warehouses will be able to run both transactional and analytical workloads on the same table.
Snowflake is laying the foundation for warehouse-native apps by actively providing the infrastructure required to support different workloads within the same store. It’s just a matter of time before the other warehouses follow suit and build a unified platform to enable warehouse-native SaaS and production applications.
We envision a future where the Cloud Data warehouse becomes the central operating system around which all production and SaaS applications will be built; this deems Reverse ETL as a category redundant.
Marketing is one of the widespread use cases of Reverse ETL right now. However, as mentioned above, Warehouse-Native marketing automation platforms like Castled are already solving the same problem more robustly and cost-effectively, without having to move the data out of the warehouse. In addition, Castled also provides the capability to sync the customer segments in the warehouse to third-party social media Ad platforms like Google Ads, Facebook Ads, etc.
However, Reverse ETL is still needed to solve the use cases of verticals like Sales, Customer Support, etc. But this is again temporary. With the support of the Data Warehouses’ infrastructure, Warehouse-Native apps will eventually be able to span across these verticals as well.