Jul 12 • 12M

[db] Warehouse-native Apps - Part 2

With Luke Ambrosetti from MessageGears

1
 
1.0×
0:00
-12:19
Open in playerListen on);
Episode details
Comments

What is a warehouse-native app and what are its benefits over a managed app?

Luke Ambrosetti (who was at MessageGears and is now at Snowflake) not only has first-hand experience, but is also deeply knowledgeable and passionate about the warehouse-native architecture. I learned a bunch from his answers and am pretty sure you will too.

And if you're about to get started with a data warehouse, Luke has some useful tips for you.

Or learn more about the middleware and the separation of the system of record and the system of engagement.

Enjoy the beats! 🥁

You can also subscribe to the show on Spotify or Apple Podcasts.


Prefer watching the interview? Here you go:

🤔 Have questions?

Leave a comment


Prefer reading? Here you go:

Q. Please tell us what is the Warehouse-native app?

A. Yeah, so a Warehouse-native app is effectively a SaaS, you know, application that is going through and doing a data-intensive process for you, and connects directly to the data warehouse.

Q. All right. So are connected apps or data apps the same as warehouse-native apps?

A. That's a good question. Kind of, it depends on who you ask, right? The definition of a connected app or a data app could be very different, you know, to people. And in my view, you know, I'm seeing connected app as kind of a good definition of a warehouse-native you know, SaaS app. Whereas data app could be, you know it could be a SAS, it could be that thing, but maybe data app is actually a larger term that incorporates, you know, maybe an internal app that you create at your, you know, at the company you work for, you know, could be a data app. Right? It doesn't have to be some sort of external tool that you, you buy and or use

Q. Oh yeah, that makes sense. So please tell us what is leading to such a paradigm shift in the way B2B SaaS tools are being built.

A. Yeah, and it's very exciting, right? Lots of new companies are taking this new approach. Like this, you know, it's called warehouse-native, warehouse-centric, warehouse first right approach. Lots of terms for it. But it honestly, it comes from this idea of the separation of compute and storage. Right? And then specifically kind of in the industry that I work in, which is more marketing, is this idea of that I've seen, it explained very well, is this idea of the, you know the separation of the system of engagement. Right? Of how you're reaching out to, in this case the marketing's case, your customers, right? And the system of record of, and where, you know what is the state of that customer? You know what they're doing, you know, where they are. You know, the Customer 360 as it's called. So with those two things separated, or you know, traditionally, I should say you've had to get your data to your system, whatever your system of engagement is. Right? And sometimes, you know, companies like Salesforce have traditionally tried to be both the system of record and the system of engagement. So, you know, now it's with a separation of compute and storage. Right? You know, you can now have those two things, you know, the system of engagement and the system of record separated as well.

🤔 Have questions?

Leave a comment

Q. So besides cost savings, what are some key benefits of using a warehouse-native engagement tool over a traditional one?

A. Yeah, so yeah, and again the cost savings aspect right here is the idea that you don't have to sync that data right to whatever, you know, your other platform is of of where you want to, you know, do either that that in whether it's, if it's marketing, it's engagement, maybe it's analytics, you don't have to sync that data there either whatever it might be. Right? So that's where the cost savings comes from, but there are so many other, you know, benefits as well right? So it's, you know, you have few data silos, you do it this way. Right, you know, instead of shipping your your data out to 10 different SaaS companies. If all 10 could connect your data warehouse and use that system of record, you know, you don't have to duplicate data, I guess, is you know what I'm trying to say, right? So it's single source of truth, of course, as well. And that's gonna be better, especially for like things like data absorbability or analytics, right? Being able to attribute, you know different events that happen, you know, back to again where you have all of your data setting, instead of it, again, being in a silo you have to then extract with an ETL tool. You get to bring, you know many of these warehouse-native cases you get to bring your own data model. So instead of having to force your data model into kind of how they view the world or how they think your data should be modeled. You get to bring your own, which is great. Also it's onboarding time, right? Instead of having, again, same thing with the the bring your own data model, you know you don't have to spend days, or not days, months honestly, sometimes years, wrapping out, you know how the data should be modeled in that destination system. Again, on the time saving, you have, you know speed of change, right? You wanted to add a specific field, right? To you know, whatever you're trying to do. It's easy. It shows up in, in the data warehouse or the database it's right there for you to use. And then lastly, from a security and compliance point of view, you know your data is safe in the data warehouse. Right? You're not having to rely on these task providers to keep your data safe. So if you have, you know, PII data, especially on on customers, you know, I come from a marketing you know, space. That data is much more safe at home.

Q. Right. That makes sense. So are warehouse-native apps making reverse ETL workflows redundant?

A. Yes. Kind of, yeah. I mean, so the answer of course is yes and no. Right? I would say it breaks reverse ETL redundant and ETL. Because again, you're not having to kind of sync data in between the you know, the source system and the destination system, right? Your source system is your system of record. That's what you get to use. So both the reverse ETL and the EL or ETL tools can be, you know, get replaced. That said, I think it's, you know, is that gonna replace them forever? No, I don't think so. I think that, you know, this approach is really cool and great, but there are, you know, some companies like when I think again, in marketing, you think about like like Facebook conversions API, or Google ads. Right? I don't think they have any reason to take this approach. Right? They're, you're gonna, you're still gonna have to use their APIs cause that's what they need, right? To do their business. So I don't think, you know, those, you know reverse ETL and El tools are gonna be completely gone.

Q. So can you, can you tell us about the segmentation capabilities of a warehouse-native engagement tool and are there any limitations here?

A. Yeah. Yeah. And so again, I work at MessageGears and MessageGears is you know, traditionally an email service provider and that's kind of been our core, you know feature is connecting directly to the data warehouse. Right. So, you know, with this type of, you know architecture or design, the limitation is that you do have to have a data model, right? In marketing, you know many companies rely on their ESPs or sometimes, you know their traditional CDPs to do that for them. Right? So you need to have a data model because you know, and you can't just take, you know these tools like data ingestion tools, like a snow plower rubber stack and, you know and just throw data into a data warehouse right? You need those resources, you need those people. Right? To go through and intelligently design models for your, you know, customers or marketing in this case, maybe sales to use, right? So, you know, when the data team does that right. For their end customers, again, the marketing team it gives those data adjacent teams the ability to use that data and kind of, you know do that last mile transformation that they need to do to to run, you know what they need to run in their programs. So it's, you know, for, you know lower or no code tools, right? It's gonna be very much a challenge to take this approach. Right? Because again, you have to basically say, okay bring your, you know, here's your data model, bring your data model and now make it work with you know, the solution we have, you know the big reasons, some of those, you know, Cloud SaaS are so popular is because they make it really easy, and they provide that data model for those, you know those low code tools to use.

Q. Cool. Yeah. So why don't you tell us about the visual segmentation capabilities? Can the visual segmentation capability eventually replace the need to build data models in SQL?

A. Yeah, that's, that's a good question. Maybe. I think, you know, we'll get there, but right now you still need, you know some base SQL, right? Or some sort of base model to work from. You know, again, those data adjacent users can go through and use those tools to do segmentation and do some really cool segmentation, honestly, at least in in our platform to do some, you know very complex segments and in groups and labeling to go through and you know, target their customers or their users. You know, at the same time, you know, it's again, it's more of that last mile approach where they're kind of, you know adding in the things that they need, but they need- For now, they need to start from somewhere, right? They need to have a, what I would call like a base model to work from. And from there they can go through and then, you know create kind of, you know, do some, some kind of, I guess additional modeling on top of that.

Q. So if warehouse-native apps don't store any customer data, won't marketing campaigns sometimes break when there's an issue connecting to the customer's warehouse?

A. Yeah, I've got this question a couple times now from some more of the, you know, technical you know, users or, you know, prospects. And the answer is yes, but at worst it's the same as or better than your typical SaaS model. Right? So with your typical SaaS model, you have to have you know, pipelines and again, and now, you know reverse ETL makes it a lot easier in getting your data synced. But, you know, for example, right, as a as a easy example here, let's say you're gonna send, you wanna send the email campaign to all the users who subscribed yesterday. If that, you know that pipeline breaks, then you could, if you don't if your SaaS company isn't looking at the freshness of that data. Every day, you could be sending that message to the exact same users again. Right? And the same kind of thing works here whereas, in this method, you know, if it breaks, you know it breaks and nothing's gonna be going out, right? Whereas if your SaaS company is not looking at data freshness, right? Something could break and then you're gonna be sending, you're giving a bad experience to customers because you're sending them the exact same content twice.

Q. That's really interesting. I never thought of that, Luke. So thanks for sharing. So last question for you Luke. What is the one piece of advice you have for companies that are looking to just get started with a data warehouse?

A. Yeah. I would say start slow. Right? Don't try and just jump in, you know, head first. There's so many tools. The modern data stack is so cool. It's, you know, lots of functionality, lots of cool features that people are doing today. You know, at the same time you have to start slow. It's a crawl, walk, run approach. Right to this shutting with one of our enterprise clients who was talking about their move into BigQuery and took them three years. Three years, I think from Teradata. Kind of, you know, on-prem. And so it's, it can take a long time. So you have to have, you know, before you start doing the really cool IML stuff, you have to have you know, your ingestion, you know, your modeling, your transformations figured out. So yeah. Start slow and yeah. Have fun with it.

🤔 Have questions?

Leave a comment