Snowflake cost optimization with Qrvey's embedded analytics

Alright. I think we'll go ahead and get started. Might be a couple more people coming in as we get a couple minutes past the hour, but I think we'll go ahead and get started. Wanna welcome everybody to today's webinar when a Snowflake becomes a blizzard. Talk about optimizing Snowflake cost with embedded analytics. Who am I? My name is Brian Dryer, and the head of product marketing at Qrvey. Today, what we're really gonna talk about and broke it down into three sections here. So why do Snowflake costs increase in an embedded scenario.

We'll talk about what that means too. Can I also look at why your typical BI pipelines fail in this embedded analytics scenario, and then we'll look at this, solution that Qrvey brings to the table that really helps you lower your cost as well? So we're gonna kinda get right into it. We'll start at section one. So let's do a little level set here. Right? So why are Snowflake costs increasing? Well, hopefully everybody on this webinar knows that Snowflake is a fully managed data warehouse and data platform. That really helps manage a lot of data projects, workloads, initiatives.

Right? It's a great tool. It's a great platform. It brings a lot to that sort of, data and analytics in their scenario. When we talked about embedded analytics today, we're talking about bringing the power of analytics tools, so the power of business intelligence inside SaaS applications. Right? That empowers users within different tenants, which means different companies. Really shape and make their analytics their own. So when we talk about embedded, it's bringing that into SaaS applications in that multi tenant environment. We'll kind of, you know, really look at that tone and that use case as to why this is an important challenge that people are facing.

So we can kind of break down these factors of usage cost increases. In a couple of different ways. Right? So there's a data volume, access control, and frequency of creation side. So when we talk about volume, we're talking about multi tenant applications here. So we're talking about just a sheer greater volume of people and users and companies creating data within a single platform here. So when we compare that to, internal usage on single companies, you know, you can kind of intuitively sense that know, the more people you have accessing a solution, the more data that's gonna be created.

Volume is just gonna go up plain and simple. User access control is another big part of this. In a multi tenant environment, which is where embedded analytics and a SaaS application is typically deployed and used. You're you're gonna have more needs and requirements around user access control. So that's not just as simple as, you know, I give one person one table and they're all on their own. You're talking about row level security within different tenants, and that tenant structure really adds another layer of complexity to that.

And we'll kinda touch on, you know, and and we'll bring that theme back around in a few other places throughout this webinar too, but that user access controls one big piece of it. You know, and then again, data's being created far more frequently. Right? And that just comes with greater usage. The more people are interacting with the system, the more often that they're gonna create new data that eventually you're gonna want to feed through an analytics solution and you're gonna want to analyze, plain and simple. So let's kind of think about that. Right? So why do they even create cost? And again, I kind of use this graphic to really kind of paint that picture between why selling, you know, the SaaS platform, you know, to set, you know, through SaaS companies a multi tenant environment really is fundamentally different than selling, you know, a single point solution to one company, maybe a couple internal groups, but fundamentally one company.

Right? When you think about SaaS companies, you know, they're not necessarily selling directly to the hospital. Right? They're the software system that they're gonna sell to individual hospitals or really gonna, you know, you're gonna have a whole system, rather, hospital systems, big corporations on one particular SaaS platform, simply gonna have more usage. And every single one of those rows represents a different company and different companies represent different needs. So people are gonna wanna look at data differently. They're gonna wanna analyze it differently. So you really do need that flexibility, to be able to adjust for all that.

Because when you're selling traditional BI to internal groups, it's a little Yeah, there's needs. Don't get me wrong. You know, it's not that you don't have different groups that want different things, but fundamentally you can funnel a lot of those requests through one group and it's all kind of self contained into one system from there. So there is a fundamental difference between the two solutions. Now you see companies trying to solve this in a few different ways. Right? So we've seen people that do a lot with, you know, compression, partitioning, you know, how can I split my data up? So I don't have to read at all.

It's memory as often. A lot of different ways that people will, you know, kinda try and test and experiment, you know, with making sure that certain people only have access to certain data. But the fundamental needs and use cases really just don't always line up with the solution itself. So that doesn't always work. Then you get people trying to scale compute. Okay. So maybe we are reading a larger amount of data every time. Can we throw some more compute resources out of it? Using that in kind of an on demand fashion, which is an area that Snowflake has released some tools on, which really do help, you know, me know my of those costs or help bring them down to a degree, but still not quite getting at that core problem that we're trying to solve here.

You know, and then the last thing we sometimes see people here is like testing different warehouse sizes. Obviously, Snowflake has different warehouses, which comes with different credit usage and cost. There's always that trade off between how high do you wanna go versus where's that point of diminishing returns on latency of the actual return of the data query. So It's a constant experimentation. Right? And they're I think you're finding that people constantly experiment because fundamentally, you know, you're not hundred percent matching up the right solution, the right tool with the right needs to create the right solution here.

So I kind of asked that question to you guys. Right? So what if you didn't have to worry about that? Right? What if your embedded analytics solution could actually optimize a lot of those data requirements for you. How awesome would that be? And what would that do to change the nature of what you're able to offer through a SaaS application? We'll come back to that one. So section number two, why do these pipelines you know, have troubles and why do sometimes they just bail in those embedded analytics scenarios?

Well, let's take our oversimplified data pipeline. Right? We know that we've got multiple different sources. Sometimes they're our own. Sometimes we're connecting to external sources to bring data in. There's some kind of know, ETL process. You're doing some transformation and eventually that has to get into your data warehouse. From there, there's obviously this this preparation layer. This is and aggregation layer. These are materialized views. This is how, you know, most companies are preparing their data to be read by some analytics software. Now, obviously, there can be more steps.

There can be more, you know, the the transformation layer alone can be as complex as you need it to be, but I think overall, this is the typical data pipeline that most of us are used to. So what are the five challenges that actually this sort of traditional pipeline creates for an embedded analytics scenario. Well, for one, you really are limited to SQL and structured data. The vast majority of AI tools out there that people try to use for embedded analytics scenarios really are not meant for anything except for a SQL database.

And I don't think it's a big stretch for us to realize that data types are changing fast, especially with the, you know, with all the momentum towards AI, Right? And that we're seeing a lot of right now, but when you wanna use AI to extract text from documents, sentiment analysis, extract, you know, content from images. Your your data formats are gonna change pretty fast, and the whole large language model analysis really adds a whole other layer to this. So one challenge is always gonna be this need to handle the structured and semi structured data, unstructured in semi structured data, excuse me.

Always gonna be one challenge. Another challenge, you're gonna have some efficiencies in batch processing and ETL. Again, you're typically building this for maybe one source or for one sort of kind of needs and solution within a company. When you try to expand that sometimes to a multi tenant solution here, you find is you end up doing a lot of custom development to accommodate what becomes a lot more one-offs based on what some of the tenant needs are. That multi tenant application here. So you get some inefficiencies in that step as well.

You sometimes have a dependency on third party tools. This is an area that SaaS companies really do try to stay away from as much as possible when it means sending your data to another platform. Right? So the last thing a SaaS company wants to do is have to vouch for somebody else's platform. And a lot times when you use a third party ETL solution, that's exactly what ends up happening. That you have to send your data to another platform and then get it back. On an internal analytics basis, that sometimes works because you're effectively, you know, your info stack and your IT team can kinda handle that one off.

But in a multi tenant space when you're dealing with other companies in Fosec, that's another layer of complexity and cost, to this process that really does a lot of times create blockers for companies to be able to offer a more advanced analytics solution within their own application. You know, and that kinda goes hand in hand, right? Because you do have flexibility. You need flexibility because you're obviously gonna have custom requirements from different users. Different companies because they wanna look at their data differently. It makes a ton of sense. So the more more rigidness you have early in that data pipeline more challenges you're gonna have at the analytics layer down the road here.

You know, and then lastly, right? Keep using this phrase multi tenant because multi tenancy is such an important part of why SaaS applications fundamentally have different reason, have different needs, it's kinda why we're, you know, we're here talking about this sort of scenario. Because we see this occur time and time again, where a lot of times you're trying to shove something that wasn't meant for multi tenant usage into a multi tenant application. And usually more often than not, it ends up failing somewhere down the road. Might not be within the first year.

It'd be in the second year. Somewhere along the way, typically people really struggle to the point where they kinda have to throw in the towel. So This whole user access control aspect of it is a really important part of it because the last thing you wanna do is have to build this custom. Into the application itself. It's more development. It's more times, more maintenance. It's one more thing you have to worry about. So this is an area that this typical pipeline just wasn't built for, you know, that multi tenant solution. Because really, you know, it leads to four primary points of failure here.

Right? Sometimes you have data quality issues. People may not be looking at the right data. If the ETL process doesn't quite match what maybe a couple tenants are expecting. Certainly have a security problem. Right? If you send data out to a third party solution, now you're responsible for that other platform. But if you don't, have the right access controls, or you have to custom build them all yourselves, you're fully responsible for the QA of that, you know, that whole layer, and that's another level that could be abstracted with the right solution. You got data silo problem potentially.

Now some of that might be by design, Some of that might also feed some limitations down the road as to what, you know, end users of an application are able to analyze. And then lastly, You just run the risk of data becoming out of date. I mean, the more custom development work you have to do, the higher your risk that you know, data is just not gonna be as relevant down the road. So this is something you're always trying to avoid. So leads me to my, kind of my next question. What if your embedded analytics software could actually simplify this pipeline?

What would that mean for your time to value and time to market? So let's look at section number three. How does Qrvey help? So let's take this data pipeline graphic and kind of explain this a little bit. So Qrvey is an embedded analytics solution specifically for SaaS companies. So Qrvey was grown and built specifically for this multi tenant environment. So when we look at this typical process that people are going through, Our job is to take the complex parts of this data pipeline and really consolidate this down into one solution as specifically built for a multi tenant SaaS application, all the way from ingestion, data storage to how it's prepared, and all the front end tools that people need within a SaaS application to be successful with an advanced analytics product.

So how does this relate to Snowflake specifically? So let's tie this whole theme together now. So if you think about the blue boxes on the screen represent data visualizations, charts that are sourced directly from Snowflake. The orange ones on the side are sourced directly from Qrvey. A typical environment, you're gonna source some whole dashboards no matter how many visualizations there are directly from Snowflake if that's your data warehouse. Then more often than not, you know, you've probably created, you know, multiple data warehouses for ETL for storage.

And then those materialized or some kind of aggregated views that an analytics software is gonna report from. So Whatever it is, the whole point is traditionally, people are going directly to snowflake for all their data. What Qrvey is able to do is actually mix data sources. And we're able to do that on a single pane of glass. So one dashboard can have multiple sources. You're not limited to one source per dashboard. And as soon as you start to enable that sort of feature, you start to open up possibilities of, well, what do I need right away that maybe I don't wanna go through a data syncing process for.

And what don't I need up to the minute? Up to the hour. What can I afford to report on yesterday's data, or maybe it's twelve hours old? You start to ask yourself some questions about how people look at data, and what are those needs? Because when it gets into a cost per query scenario, how do we reduce the more expensive queries and replace that with much more cost effective ones? So what Qrvey is able to do is we're able to offer a data store as part of our all in one embedded analytics solution.

So this comes natively into our solution, and this is all deployed into your AWS environment. So we are not a cloud ourselves. We are deployed solution into your environment, which means your data never has to leave your cloud environment, which is a really important part of how we're able to really simplify this process for SaaS applications. So because we can read from different sources, that means the application or the analytics layer really as platform owners, you can decide which data should come directly, you know, from Snowflake, and real time data is a great use case for that.

So when you want something that's up to the minute reporting directly from the source, you know, that makes a ton of sense. Right? You're not gonna go through a data's thinking scenario just for that. But because we offer this other data store that is a more cost effective way of creating data queries, you know, it makes a ton of sense to sync data seventy six hours, maybe twelve. Maybe it's an overnight job. You know, when you're really playing the cost optimization scenario game here, you get to really think about how recent do people need all of their data?

And it's an interesting question, but because we can mix data sources on a single pane of glass, this gives you that flexibility there. So that middle layer is all handled by the Qrvey platform with direct connectors to Snowflake, as well as a native internal, data store that we can read directly from, and all that data preparation and aggregation is handled natively into that solution. Without the customer having to do any custom work on that part. So why would you do that? Right? So let's think about some use cases as to where that could be important.

Let's say you're running an incident management system. It makes a ton of sense to have a real time, you know, view on what incidents are happening right this second. That's a great use case. Go right to the source. The second it's stored, you know, the second later shows up on your screen. Makes a ton of sense. You're analyzing those trends though, you know, then you have an opportunity to look at, you know, well, this could be historical data, but really anything, you know, past, call it yesterday, if you will. You know, is a great way of looking at sync data. When you're trying to find those trends and incidents, then you're gonna be doing complex filtering, gonna be looking at different views.

You know, different companies on the same platform are gonna wanna see their incidents in a different way. That makes a ton of sense. You're gonna do a lot more data queries. Actually on that sync data set and probably on that real time data set. So it makes a lot of sense to have a more efficient cost per query scenario. Same thing with something like an advertising system. Maybe you wanna look at live bidding data or some kind of live advertising data. Right? Soon as it hits your direct data warehouse, you wanna see it on that live screen. Makes a lot of sense. So when you start, you know, analyzing, you know, statistics and trends and trying to really optimize this, you know, optimize the recent past or maybe the next week or so.

That's gonna be a lot more data queries. Again, because you're gonna slice it a few different ways. It makes a lot of sense to use that sync data. And on the third, you know, kind of, use case here around resource management. Let's say you have a system that is looking at uptime and downtime on It could be IoT devices, could be something in manufacturing, could be something in logistics. But the point is when something goes down, you wanna know in real time. Right? Because a lot of times that means that could be lost revenue. That could be a cost to repair. There are real time reasons why you need to get you know, equipment or any kind of logistics component up and running as quickly as possible.

But when you're trying to look at trends on why things are going offline, That's a great use case for something of this thing data store. That lets you analyze it, it lets you slice it a few different ways, drill into data, again, filter data. And again, ten, it's gonna look at that a little bit differently. So you're gonna see a lot more queries on that data. So that's a great use case when you wanna find those offline trends. You can really get to a root cause. But using that against sync data is a great use case for that. So these are some kind of ways that you can start to think about why you would want something in real time, why it's okay to have something that has a little extra latency.

Call it, you know, twelve to twenty four hours. But in reality, that latency is completely up to you. On our website, we built an ROI calculator for anybody that wants to sort of play around with these costs. You know, a lot of times we see it's the warehouse size, you know, how much you're paying on a cost per credit basis. And then what's your current usage is what you want usage to be. So I ran a simple scenario and we took a screenshot from our ROI calculator on our website. You know, if you took an extra large data warehouse on Snowflake, call it a rate card list price of three dollars.

That's about, you know, twenty two days a month is roughly weekdays. Three hundred and sixty minutes. That's about six hours a day. So if you're using Snowflake about six hours a day, In production, only weekdays, you know, you're probably spending around seventy six k, give or take. Right? Trying to cut that down to only two hours a day. Right? Specifically for Snowflake, that's a sixty percent cost reduction. Now, you can go out here and you can play around with that. This is really targeted towards just that part of it. You're using Snowflake for for the analytics part of it.

We're actually not saying go replace your entire all of your warehouses on Snowflake that are maybe used for, you know, all just for ETL, maybe you have some specific rules around some initial processing when they come in, totally fine here. But the parts of Snowflake that you use specifically for analytics purposes. Think about how much of that usage has to be on Snowflake versus how much could be on another platform like Qrvey. You can bring that down, you know, by two thirds. That could mean real savings. If you have an application that is used across time zones and continents, six hours a day might be nothing.

I mean, you could have a platform that's used twelve hours a day. Especially if you're on multiple continents. Even if you're just on North America in Europe, you know, that's about nine time zones, you know, by itself. So you can start to think about what your usage is versus what you'd want it to be. If you can get it around that, that means real savings. Fundamentally, that's what this is all about. Right? This is about saving. This is about cost optimization. Everybody's tightening their belts these days. So companies have to be cost conscious. And if there are simple ways, that they can, you know, reduce some cost and offer a better solution to their end users, I think that's a win win for people.

Fundamentally, that's what we're out here for Qrvey to really try to do is to empower all of those end users of multi tenant SaaS applications with a better analytics experience. And that's the finish line. And everyone loves a nice hugging swirl when we cross the finish line here. So that was our our presentation. Hopefully, that helped here. We'll kinda just recap that real quick. So we talked about three parts. Right? Wire cost increasing with embedded analytics.

And again, it's really looking at that multi tenant use case on how much greater the usage levels really are in those scenarios. Section two, we looked at why those typical BI pipelines fail. Again, in an embedded analytics scenario, and we, you know, we kinda keep harping on this multi tenant usage really is different. So those needs for flexibility and customization really create, the requirements around looking at a solution that is a little bit different. And then lastly, how does Qrvey specifically help with that? You know, our ability to mix data sources opens up, how you actually can create templates, create reports, and then you can really think about, you know, using Snowflake a little bit more surgically around, how you use Snowflake specifically for data queries.

So that was our presentation in a nutshell right there. Hopefully, that helped shed some light on how Qrvey is helping tackle Snowflake cost optimization problems specifically. If there are Any questions? I'm gonna go pull up my Q and A right now. If we do have any questions, I'm happy to stay on for a few more minutes. Otherwise, if there are no, you know, if you don't have any questions, you're welcome to leave. That's gonna be the presentation. We'll send around the recording as well. I'll hang around here for a couple more minutes if we have any if we have any questions.

I do see one question around I did say something about Qrvey being deployed to individual environments. Does it run on any cloud? So I kinda glossed over that point a little bit here. Qrvey is a deployed solution, so we're not SaaS platform where you have to send data to. We're actually, we are a serverless software stack specifically for AWS environments. So we get deployed to your AWS environment. That means you get the benefits of security and scalability because we are serverless solution not renting EC two servers, you know, this is an on demand solution that scales with you, that really presents, you know, kind of that forward looking technological solution on serverless, technology there.

But you also get a lot of that scalability and security. So we are specifically for AWS environments, right now. And hopefully that answers your question. Okay. I think we're gonna wrap this up. We're gonna end the recording here. By all means, you're welcome to reach out to us at Qrvey dot com. If there's anything else that we can help you You can connect with me on LinkedIn. Again, my name is Brian Dryer.

I'm the product marketing team here at Qrvey. Happy to talk to anybody as well directly one on one. Wanna thank everybody for joining. You guys have a great afternoon.