If you’re planning to build a warehouse-native app or support this growing architecture for your existing SaaS, then you definitely don't want to miss this conversation between two leading minds in the warehouse-native domain.
In this episode of the data beats show, Luke Ambrosetti hosted Abhishek Rai, the Co-Founder and Head of Product at NetSpring.
🥁 This episode is brought to you by NetSpring, a Warehouse-native Product Analytics tool. 🥁
Luke has spent more time working on warehouse-native solutions than anyone else I know. He was formerly at MessageGears and is now at Snowflake where he helps partner organizations adopt the warehouse-native architecture for their joint customers.
Luke is also a two-time guest and now a two-time host on the data beats show.
Abhishek, who was also a Co-founder at ThoughSpot and has spent over a decade building analytics products, shares some hard-won lessons that are super valuable for companies considering the warehouse-native approach to building B2B apps.
In just 12 short minutes, you'll get answers to questions like:
What does the architecture of a warehouse-native app look like?
What’s the biggest engineering challenge in building a warehouse-native app?
What are the benefits of going warehouse-native only instead of hybrid?
You can also watch the full episode on LinkedIn.
Or keep going if you prefer to read the key takeaways from the conversation
Luke:
Let's get into the specifics of warehouse-native apps and their architecture on a cloud data platform or as some say — a cloud data warehouse.
In the simplest terms, what does the architecture of a warehouse-native app look like?
Abhishek:
The architecture of a warehouse-native app starts at the highest level with the translation of user intent into workflows or SQL to access the data in the warehouse (cloud data platform).
And the most fundamental property of a warehouse-native architecture is you never copy data out of the warehouse in order to operate on it — all the data stays in the warehouse and all the computation that you do on the data takes place in the warehouse.
Luke:
From an engineering point of view, what has been the biggest challenge for your team to adopt this deployment model in the way B2B software is built?
Abhishek:
The warehouse-native architecture is very promising but the biggest challenge that we faced from an engineering point of view is the lack of a standard data model.
In the pre-warehouse-native days when most of these analytical applications were full-stack, there was a standard data model that these applications would enforce at the time of data collection.
However, a warehouse-native architecture allows you to bring data from a whole bunch of disparate data sources, join the data, and draw insights from it — but this architecture also leaves you with the problem of a missing standard data model.
A related challenge has been that while SQL is a great standard to work across data warehousing solutions like Snowflake, BigQuery, Redshift, and Databricks, there is much less standardization when it comes to data science workflows. Therefore, providing a single application experience across different warehouses becomes more of a challenge as you start leaning more on the data science side of things.
Luke:
In my experience at Snowflake, and even before Snowflake at a company offering a warehouse-native product (MessageGears), many customers aren’t ready for this deployment model — some may not even have a data warehouse or a concept of a data warehouse internally.
And oftentimes those who do, don't have their data together — they don't have it modeled properly or don't have the right schema for a warehouse-native app.
What are your thoughts on this and why did NetSpring decide to be warehouse-native only?
Abhishek:
That's a great question and if you would've asked me that a few years back, I would've probably said that warehouse-native doesn't make sense.
However, what I've seen over the past couple of years of building NetSpring is that even though not everyone has fully embraced the cloud data warehouse, there are enough organizations that already have embraced it and have put their mission-critical data in the cloud, making it feasible to build a completely warehouse-native solution.
In terms of building out the company, there are a couple of additional things that supported the decision to be completely warehouse-native:
We have been able to build a significant competitive moat around this architecture which has brought in a lot of focus in terms of execution, the messaging, and our customers knowing exactly what to expect from us.
From a product perspective, we've been able to imbibe the analytical power of business intelligence (BI) into product analytics. BI thrives on a warehouse-native architecture and we're able to offer a solution that combines the best of product analytics with the power of BI.
Luke:
Is NetSpring an evolution of ThoughtSpot or can they both coexist for a customer?
Abhishek:
NetSpring is actually completely complementary to ThoughtSpot and both can absolutely coexist.
ThoughtSpot, as you know, is BI on the warehouse and is powered by NLP (natural language processing) — there's a lot of kind of goodness there. Whereas with NetSpring, the primary emphasis is on product analytics in a warehouse-native architecture.
There’s a lot of depth in the product analytics space and in fact, we're realizing that the first-generation product analytics tools — by being these fully integrated vertical silos — have left a lot of value on the table, which one can harness with a warehouse-native architecture.
And that's what we are excited about — product analytics with the power of BI.
Luke:
What is the one piece of advice you have for startups as they consider taking this new approach to building B2B apps?
Abhishek:
My biggest recommendation is to go full warehouse-native — this is our foremost learning.
By building a fully warehouse-native application, you’ll be surprised how much it simplifies your product, your stack, and your messaging — and how much it allows you to focus on your core competitive moat instead of moving around data, dealing with data duplication, ETL pipelines, and so on.
Just go full warehouse-native. That is the one piece of advice I would give to anyone starting in this space.
Have questions for Luke or Abhishek? They’d love to hear from you on LinkedIn.
Share this post