26:01 Webinar
Click. Configure. Run. Presets and Workload Setups for Consistent Database Environments
As database estates scale, DBAs spend an increasing amount of time re-validating the same storage constructs, compliance, and more—rather than improving database reliability and recoverability.
This webinar first aired on March 24, 2026
The first 5 minute(s) of our recorded Webinars are open; however, if you are enjoying them, we’ll ask for a little information to finish watching.
Click to View Transcript
Good morning, everyone, and thanks for joining us for Presets and Workloads: Consistent Database Environments. I'm your speaker today, Melody Zacharias, Technical Evangelist at Everpure. Let's start with a reality check. In a recent survey, eighty percent of respondents admitted that database
administrators are spending more time re-evaluating infrastructure than actually driving innovation. That's a striking signal, and it tells us something really important about where time and energy are actually going. Because the true bottleneck isn't what we often assume.
It's performance tuning. It's not scaling challenges, it's the repetition, the constant cycle of verifying the sna- same snapshots, rechecking QoS policies, confirming naming conventions, and running compliance checks over and over again.
These are necessary tasks, but they're not really high value, and yet they quietly consume a significant portion of a DBA's day. And this is where the stakes become real. What if, instead of continuously reproving what already works, we could make it prescriptive?
In this session, we'll explore how presets for static database workloads can transform the way teams operate. Think standardized configurations for snapshots, QoS, volume naming, compliance, governance. Instead of fragile manual setups, you get fast, repeatable automation.
Wouldn't that be awesome? The outcome is powerful. Less revalidation, consistency, and most importantly, time back, time that DBAs can reinvest into innovation, optimization, and the initiatives that actually move business forward. So what does that really mean?
Now let's take creating outcomes. Think about it this way. We don't manage every gear in a car. We focus on where we're going, how fast we need to get there, and under what conditions. Right? It's complexity that's abstracted so we can
focus on the actual outcome. And for DBAs, that same mindset shift is long overdue. It means stepping away from managing backup infrastructure piece by piece. It means no longer treating storage as just a passive dumping ground, and instead starting to manage data recovery as a policy-driven outcome.
Something predictable, repeatable, and really aligned to the business needs. So what does that transformation actually look like in practice? It's a complete shift from manual tuning to policy-driven orchestration. Policies instead of scripts, templates instead of one-off heroics. You get the consistent protection without constant intervention, without relying on
tribal knowledge. It's a reframing of conversation itself. It's the transformation that matters. Fewer knobs, fewer scripts, less babysitting. Because when mistakes become a thing of the past, it becomes a strategic capability, and this is important.
So let's get to the meat of it. With the presets built into Pure1, workload deployments like snapshots become fully automated and repeatable. You start by defining a preset once, covering everything per- performance needs to protection policies.
Then when it's time to b- deploy, it's as simple as choosing the preset and naming the workload. The orchestration is automatically handled. Volume creation, QoS, performance settings, snapshot schedules, replication targets, no matter or And no manual setups, no missed settings, and no inconsistencies.
You can deploy one workload or a thousand with the same level of speed and precision. This transforms storage from a bottleneck into a self-service on-demand resource. From a DBA's perspective, so this is 'cause we're not infrastructure people. So what does this m- why does this matter to us as DBAs? This isn't about new storage platforms.
It's about removing that friction from everything around databases. So let's address the obvious concerns that we as DBAs have.And this isn't about force change. Okay? The Pure Data Platform is included with Purity, so there's no extra licensing cost, no separate control plane, no rip and replace.
If you're already running Pure, this layer is on top of what you know and already trust today. And we know backward compatibility matters to DBAs. So your existing SQL Server workflows, backup jobs, scripts, operational patterns So what change i- what changes is how much manual effort it takes to keep
things consistent as your environment grows. So where DBAs really feel the impact is thin provisioning and protection. So instead of configuring volumes, snapshots, and replication over and Pure Fusion lets you define these behaviors once and apply them consistently.
This means the right performance characteristics every time. That's important. No drift. The right protection policies every time. No one-off databases that behave differently during recovery. This dramatically reduces risk, especially in large SQL estates where
inconsistencies are usually discovered during that restore when it's already too late. You know who I'm talking about, right? I mean, we've seen this happen, and this is the key DBA benefit. Automation here isn't about speed for speed's sake. It's about confidence and knowing it's going to work.
When configuration is enforced automatically, we have fewer human errors, fewer missed snapshot schedules, fewer surprises during failover or a restore, which is really when it counts, right? We know that it's not about the backup, it's really about the restore. So instead of storage being another dependency DBAs have to coordinate, chase, or
double-check, it becomes workflow driven and predictable. The outcome for DBAs is faster provisioning when new databases show up. Consistent behavior across all of your environments, not just production, but consistency across dev test too, and most importantly, reliable recovery when the business is watching.
That's why Pure Data Platform matters to DBAs. Not because it's new, but because it finally makes storage behave like the rest of the modern SQL Server stack: automated, repeatable, and boring in the best possible way. That's my favorite part. So let's take a look at the demo.
The demo on presets and workloads. Let's start by opening up our Google Chrome. I'm gonna log into three different FlashArrays here. This will allow me to quickly add the arrays to the fleet. Starting on the first FlashArray, I'm gonna go to Fleet.
Now, I can either create a new fleet, join or join in an existing fleet. I'm gonna start with a new fleet. Because this is for databases, I'm gonna call it DB Fleet, and simply create a fleet. You can see here that my fleet is created.
It-- my FlashArray one has joined it. But what I wanna do is click this at the top where it says at the top line here says Fleet Members. I have the option here to create a This fleet key is good for an hour. You can see the ti-timer already starting.
I'm gonna copy this, and this will allow me to add my FlashArray two. So again, I go to Fleet. This time I'm gonna join an existing fleet. I need to use the exact same name, but here I use the fleet key.
This is a one-time use key. So for the FlashArray three, we'll have to create a new key. However, I can do that from FlashArray two. I don't have to go back again to FlashArray Pure1. You could do it from any FlashArray that is in the fleet.
So I can do it from here. I can create another key. Create a fleet key. Copy and close. Go to FlashArray three. Join. Here it remembers my fleet name.
Don't use the remembered key 'cause that's gonna be different. Add in the fleet key and join my fleet. If the time runs out on your key, not a problem, just create a new one. Timer will start all over again. Simple as that. Now I'm gonna go back to my FlashArray one,
and instead of Fleet, I'm gonna go to my storage, and we're gonna set up a preset.This is my first preset. So let's create this preset. We're gonna call it SQL Dev Test. SQL Server volume.
Oops. For dev test. Let's see, workload for MS SQL. Storage class is gonna be a FlashArray//X. And we need some storage resources here, so let's name it Data Vol.
Oops. Fat finger typing, of course. And let's get two of those. Provision that with ten GB. And add those to the preset. You can see those that are listed here.
You can review it. And we'll create that. Now that preset is created. You can see that it says DB Fleet at the beginning of the preset name, and you have one for the revision, which is nice. So you can see every time that that is changing.
Now we go to Workloads. Make sure that we're gonna click on the Fleet view. And you see that we have no workloads here, but if we click on this plus side, gives us the option to add workloads. Make sure that we're choosing the right preset.
It will populate to show us the details. Click Continue. And we can add in our workload name here. So let's add our first new workload. And it's a SQL workload, so we'll call it SQL Workload one. The option here is to get recommendations if you wanna choose the different recommendations,
but of course, we at the moment just have a couple of FlashArrays, so let's FlashArray//X one. We're gonna create a workload here for placement on that target. So let's go back to Presets.
Edit the preset for a snapshot. We're gonna call this Hourly Retain One Day. So Create Every Hour, One Day. We're gonna add that rule, and then add that rule to the preset.
We need a storage resource. If we spell it right. We need to choose a storage resource for this preset workload. Choose the snapshot configuration.
Add it to the preset. And upload-- update the preset. Now this preset is up. So over in Workloads, ensure that we're in the Fleet View. And the last thing I want to show you is updating the preset for quality of
service.So let's do that. So again, under Presets, let's update quality configuration. We want, we wanna add in here 5, 5K, and 100.
Add that to our preset. Update. So we now are at three revisions. We're gonna configure a new workload. Go over to Workloads, add a new workload.
Click on this one, where this shows us our preset details. We're gonna continue. We're already at two, so we're just gonna update this to three. And we've got our QOS and our snapshots, and I'm gonna create that workload.
Now we've got all three, all three set up. Take a look over at our volumes. And you can see that we've got all of them, all of them set up, all three FlashArrays. And that's the end of the video. That's the end of our demo. If you haven't already, please register for
our Pure//Accelerate event. Scan the QR code on your screen and it will take you to our website to register. Our Pure customer community is a great place for collaboration, and to continue the conversation for this webinar, please scan the QR code for the screen to join. And next we have questions with Pure's very own Mike Nelson.
Thank you for joining us. Hey, Melody. Hey. Thanks for joining us, Mike. Sure. I appreciate it. So for those of you who don't know Mike, he is our resident expert on Pure Fusion. So I've asked Mike to join us, to help us out with questions because as much as I know
about databases, I don't know near as much about Fusion as Mike is. He's been involved with Pure Fusion since the very beginning, and he definitely than I do about Fusion. So get those questions coming in. So our first question is, for organizations currently relying on a large library of custom-built scripts or provisioning, what would you recommend
migration path to transition to policy-driven templates? Well, you have to look at it from the standpoint of, you know, what the goal is. So you already have If you're talking about the question in, in general, you already have those custom-built scripts. You put a lot of effort into those scripts.
You probably did a lot of debugging, a lot of mistakes were made. A lot of maybe, you know, things broke maybe, which, you know, would've been a bad thing, but, it happens. So what we really need to do is we need to take a look at how complex those are because, in the ever-serve world, of the automation, and especially dealing with Pure1 and Fusion,
is you're trying to make things really simple. But what we want to do is take what and be able to put them inside of a preset type of environment, as easily as we can. Now, that, that doesn't mean we can solve everything, currently today with the presets, but we can sure try. And, there's a lot of different things that we
can do with that, and you can actually take a preset and you can export it to a JSON format, and we can manually edit it from there, adding our own, you know, nuances and naming conventions and all that kind of stuff to it. But from a, a simple standpoint of taking what you have, really, needs to apply to a preset, and you can easily do that through the, the GUI by, you know, creating the basic preset,
and then being able to, mold it as you need, for what you, what you're trying to accomplish. Maybe exporting it, to create another preset that's identical and be able to, you know, maybe I, you know, change that, a couple things within that preset, rename it something different, and now you have another preset that you can use. So there's a lot of flexibility there.
And, you know, if you wanna work with us, we can certainly help, help you out there with the, you know, our, our field folks, for, you know, even up to, the technical, evangelists like myself. Oh, that sounds great. I like that. Particularly the JSON, if people already have things that are written that way.
Yeah. That, that's super handy. Excellent. Okay, so our next question, while presets provide prescriptive configuration for well-defined environments, how does the platform handle outliers, like databases that might require unique performance or capacity overrides, while still remaining within the overall governance and compliance framework?
Great question. Great question, because what we do with Fusion is we actually offer two types of presets. We have a, what we call the prescriptive preset, which is pretty much locked down. It The creator of the preset, the sysadmins, will go in and create a preset that doesn't have a lot of flexibility to it.
They want it a certain way. They want things that are, that are set a certain, you know, do certain QoS, do certain snapshot schedules, do this or that. Then we have ones that are called customizable, which allows the user to go ahead and select from options that, the original preset creator can give them.
So it allows for more flexibility in what they're allowed to do. It even allows for freeform, type of configuration. So if there were specific things around resource naming or something like that you were like, "I want the user to decide what this is gonna be," there's really no guardrails around it or anything like that, they can go ahead and do what they want, then
you can actually allow that. So that's, that's on the customizable end. So we try and offer that flexibility to, you know, work with all types of different scenarios. That's fantastic. Yeah.
I really, I really like that for, for because there's n- not everything that as a DBA really fix, fits into a box, right? Right. And there's always those outliers, so it's important to have that flexibility. Right. Absolutely. Yeah. So that's fantastic. Well, that's all the questions we have for
today, Mike. I really appreciate you taking the time to, to help us out here- Sure and, answer those questions. Thank you for your time, and thank you to our audience for joining us. Hope you all have a great day.
Melody Zacharias
Technical Evangelist Director, Everpure
As database estates scale, DBAs spend an increasing amount of time re-validating the same storage constructs, compliance, and more—rather than improving database reliability and recoverability. This walkthrough demonstrates how workload-aware presets encapsulate these requirements into reusable, prescriptive configurations for well-defined database environments.
By decoupling database intent from underlying storage mechanics, DBAs apply consistent protection, performance, and governance policies without per-database tuning or scripting. The result is deterministic behavior across the estate, faster deployment, and reduced operational risk as environments grow.
Join us to learn about:
- Repeatable configuration at scale: Presets enforce consistent snapshots, QoS, naming, and retention across all databases.
- Policy-driven orchestration: Database workload intent is applied through templates, not scripts or manual configuration.
- Predictable recovery behavior: Consistent workload delivers reliable, high-performance restores with less risk.
We Also Recommend...
Personalize for Me
My Updates
No updates at this time.