Denver PUG Chapter Meetup
Connect, learn, and have some fun with your fellow IT pros. As your local Everpure User Group, PUG brings together IT professionals across the Denver area for education, collaboration, and real conversations with people who face the same challenges you do. We’ll start with technical content on the topics that matter most to your day-to-day work, along with time to swap ideas and lessons learned with your peers. Then we’ll wrap up with networking, bowling, and complimentary food and drinks. It’s a great way to spend your afternoon and meet more of your local tech community. RSVP now to reserve your spot! Agenda: 2PM: Registration 2:15 PM: Presentations 3:15 PM – 5 PM: Networking and BowlingWaddle on, federal friends. 🐧
We know the rush of federal busy season is behind us, but the work doesn’t stop. My kids gave me this little toy from their school's "Friday Shop" and it made me smile. Hope this spreads some encouragement for the week ahead. How are our federal folks doing? Drop a comment below. 👇Getting Started: 5 Steps to Get the Most Out of the Everpure Customer Community
Welcome! You've taken the first step and created an account here. What to do next you ask? Here's five simple steps to take after registering to ensure you're getting the most out of this community. Fill out your Profile: Let the community know who you are! Click on your avatar in the top right corner of this window and select 'My Settings' from that dropdown. Fill in your name, location, and bio information. Plus select from one of several default avatars or upload your own image. Write an Introduction post: Head over to the Social Space and write your intro post. Tell us about yourself, your role at your company, and your goals for participating in this community. What have you been thinking about a lot lately at work? (And we won't shy away from pictures of your pets either!) Follow a couple of Forum areas: Find the products you use most and solution areas you're most focused on in our Forums and be sure to click the bell icon in the upper right of those forums to be sure you get notifications on the latest activity in those areas. If you work in Finance, Healthcare, Public Sector, or Telco there's groups dedicated to the unique needs of your industry areas too. And if you're an open source or automation fan, Cloud Native and Kubernetes devotee, or a Pure Partner, there's dedicated group you can join for each of those areas too. Join your local User Group: Click on Groups in the top nav and select Pure User Groups. (fka FlashCrew) Select your region & find the group for your local area. Click on that group and then click 'Join Group'. This will ensure you hear about any Pure events happening in your local area, including when & where the next meetup is. Pick 3-5 tags to follow: This community makes heavy use of tags. As you browse a forum, you'll notice each thread has tags. That is because we require them for every post. Find the tags most relevant to your interest areas and click the bell icon on those pages so you can keep up to date with the latest posts in those categories, regardless of what forum or group the discussion happens in. Finally, feel free to ask questions! Your friendly admins (bmcdougall and Ludes) are here to answer any questions you have and take suggestions. And we have deputized experts across Everpure to be on hand to answer deep technical questions. So don't be shy, there's always someone around to help you out.AI Can Write Your Data Platform. Who’s Going to Keep It Running?
AI can write SQL, generate pipelines, build infrastructure, create database migrations, and even diagnose production problems. But what happens when it confidently does the wrong thing? As AI becomes part of how we build and operate modern data platforms, the key question is no longer just, “Can AI generate this?” It’s whether we can trust the result, deploy it safely, observe what happens, and recover when things go wrong. Join Hamish Watson for a practical session on bringing AI-assisted development into production reality. Drawing on experience across SQL Server, cloud platforms, Databricks, and database DevOps, Hamish will explore how version control, CI/CD, automated testing, drift detection, observability, and governance help keep AI-generated changes safe and recoverable. The session will include practical examples, lessons learned, and a live demo. And, because live demos rarely go exactly to plan, there may even be a surprise or two. AI might be able to write your data platform. The more important question is: who’s going to keep it running? Register for the sessionAI & Data Discovery
Would love your take on this GovLoop piece from my colleague, JimWeaver (former WA and NC CIO, ran NASCIO). One line that really stuck out to me: in a legislative hearing nobody asks if the model works. They ask where the data came from and who touched it. His first AI move in North Carolina wasn't buying a model. Instead, it was about data discovery. What do we have, where does it live, how clean is it. Has anyone here done similar data discovery efforts? How long did it actually take, and what surprised you? https://www.govloop.com/community/blog/building-an-ai-ready-data-foundation-for-state-and-local-government/
The Art of Sizing: How to Size an Exadata Migration Without Overbuying Storage
If you are moving Oracle databases off Exadata, the first sizing mistake is usually looking at only one database at a time. Exadata is not a traditional Oracle architecture. Some of the work that would normally happen on the database host is performed by the storage cells, including capabilities such as Storage Indexes, Smart Scan, and—depending on the database version and workload—vector offloading. That changes what the storage numbers mean. A successful migration therefore needs to answer two different questions: How much I/O is the current Exadata environment really performing? Which parts of that work will move to the database hosts, change shape, or disappear when the architecture changes? This installment of The Art of Sizing walks through a practical way to answer both questions. Why Exadata sizing is different In a conventional Oracle environment, it is common to begin with the database-level system statistics and identify the read and write workload for that database. That is still useful on Exadata, but it is not enough. Exadata is often a consolidated platform running multiple databases across multiple storage cells. The migration target must be sized for the estate as a whole, not just for whichever database happens to be easiest to measure. The other difference is architectural: Exadata reports include physical work performed by the cells. That work can include processing that a non-Exadata design may need to perform elsewhere. The implication is simple: Do not copy an Exadata number directly into a replacement-storage calculator and assume the result is equivalent. First, understand what the number includes. Then normalize it for the target architecture. Start with the familiar metrics—but use the global view For a normal Oracle workload, the starting point is the System Statistics (Global) view. The key measurements are: Read IOPS: physical read total IO requests Write IOPS: physical write total IO requests Read MB/s: physical read total bytes Write MB/s: physical write total bytes These measures establish the workload profile, but a per-database view can hide the scale of a consolidated Exadata environment. Figure 1: The Global Activity Statistics view provides the starting point for reading Oracle read and write activity. The detailed statistics show the specific physical-read and physical-byte measures that should be carried into the analysis. Figure 2: Example physical-read measures from the global statistics output. The important word here is global. If Exadata is hosting several databases, collect the workload across the full environment. A replacement platform must be able to absorb the combined demand, including concurrent peaks that may not be visible when databases are reviewed independently. Use the Exadata AWR Global RAC report to see the platform as a whole The Exadata AWR Global RAC report is valuable because it brings the consolidated environment into view. It shows the disk types, cell counts, disk counts, IOPS, and bandwidth associated with the Exadata storage layer. In the example from the source report, the cells are performing approximately: 615,244 IOPS 28,899 MB/s Those values come from the F/6.2T and H/20.0T disk groups shown in the report: 404,115 IOPS plus 211,129 IOPS equals approximately 615,244 IOPS 24,297 MB/s plus 4,602 MB/s equals approximately 28,899 MB/s Figure 3: Example Exadata storage-cell performance summary. These are useful sizing inputs, but they are not automatically the final requirements for the migration target. They describe the physical work being performed inside the Exadata architecture. That distinction matters because Exadata is doing more than simply storing blocks. Account for the work Exadata is doing for you When you leave Exadata, some of the platform behavior may need to be reproduced through database design, host resources, or application changes. The exact impact depends on the workload, database version, SQL mix, and target architecture, so the assessment must be validated with the DBA and application teams. Exadata capability or behavior Migration sizing question Storage Indexes Will equivalent filtering be provided by indexes, partitioning, clustering, or SQL changes? Smart Scan Will more data be returned to the host because the target platform does not perform the same cell-side filtering? Vector offloading Where will vector-related processing occur, and what CPU, memory, and I/O will it require? Consolidated storage cells Will the target platform handle the same concurrency and peak overlap across all databases? Large SGA requirements Does the target need additional host memory to preserve cache behavior and avoid turning cell-side efficiency losses into repeated reads? Table and index layout Do large tables need new indexes, partitioning, or access-path changes to deliver comparable performance? This is the part of the migration that is easiest to underestimate. The goal is not merely to reproduce the observed Exadata I/O. The goal is to understand the work behind that I/O and decide where it will run after the migration. Normalize ASM redundancy before sizing capacity The Exadata summary also shows how much storage is allocated and used through ASM. This is where capacity can be overstated if the redundancy model is carried into the new architecture without question. The source example uses ASM High Redundancy. In ASM, that means the database data is stored with three copies. If the target storage platform supplies its own protection and the design uses ASM External Redundancy, the database layer may need only one logical copy. Figure 4: Example ASM disk groups with High Redundancy and their allocated and used capacity. As a first-order capacity normalization, moving from three ASM copies to one logical copy reduces the ASM-replicated requirement by approximately 66.7 percent. For example, 600 TB represented under a three-copy ASM model could correspond to roughly 200 TB of logical database data before adding target-platform protection, snapshots, growth, recovery copies, and operational headroom. That is not a universal storage-sizing answer. It is a normalization step. Before using it in a purchase or design, confirm: Whether External Redundancy is appropriate for the target architecture How the storage platform protects data and handles failure domains Whether the design includes snapshots, replication, backup staging, or disaster recovery copies How much free space and growth headroom the environment requires Whether the capacity numbers are raw, usable, allocated, or actually consumed The key lesson is that database redundancy and storage redundancy should be evaluated together. Counting both without understanding the division of responsibility can lead to buying protection twice. Do not reduce performance by the same percentage automatically It is tempting to apply the same 66.7 percent reduction to IOPS and MB/s because the ASM model moves from three copies to one. That can be a useful initial hypothesis, but it is not a guaranteed performance result. Read and write behavior can change differently. Exadata cell processing may be removed. Host-side indexes or partitioning may add work. The target storage platform may also use a different protection scheme, data-reduction method, caching model, or concurrency profile. A better approach is to use the Exadata numbers as a measured baseline, then build a target model with explicit assumptions: Baseline physical read and write IOPS Baseline read and write bandwidth Peak and average behavior across the full database estate Expected change in host-side processing Expected impact of indexes, partitioning, and larger SGA requirements Target protection and redundancy model Growth, recovery, and availability requirements That model gives the migration team something it can test instead of a single inflated number or an overly optimistic discount. A practical Exadata migration sizing workflow The process can be summarized in six steps: Collect the Global RAC and Exadata AWR reports for the full environment. Record average and peak IOPS, bandwidth, storage utilization, disk types, and database concurrency. Separate database workload from Exadata cell-side processing and identify what may move to the hosts. Normalize ASM redundancy so database copies are not counted twice with storage protection. Add target-specific requirements for CPU, memory, indexes, partitioning, snapshots, replication, recovery, and growth. Validate the model with short-window performance data and a representative migration or proof of concept. The first four steps create the sizing baseline. The last two turn that baseline into a design that can survive real workloads. The sizing lesson Exadata migration sizing is not a matter of copying the largest number from an AWR report into a storage proposal. It is an exercise in separating three things: The work the current environment is performing The protection and redundancy that are being counted today The work and protection the target architecture will need tomorrow In the example discussed here, the Exadata cells show roughly 615,244 IOPS and 28,899 MB/s, while the ASM configuration indicates High Redundancy with three copies of the data. Those are important facts, but they are starting points—not automatic target requirements. The most reliable design is the one that measures the whole estate, understands the Exadata features behind the measurements, removes duplicated redundancy, and then adds back the host, protection, recovery, and growth requirements of the destination platform. That is the art of sizing an Exadata migration: not buying for the biggest number, but understanding what the number actually represents. Final thought When an Exadata migration is undersized, the problem usually appears after the architecture is already difficult to change. When it is oversized, the organization pays for capacity and performance that may never be used. The better path is disciplined normalization. Measure Exadata as a consolidated system. Identify which work will move. Separate database redundancy from storage protection. Then size the target for the workload you are actually building—not the architecture you are leaving behind. That is how sizing turns a migration estimate into an engineering decision.Accelerate 2026 - Part 1 - Everyone Wants Your Data
Back in February, I wrote that I had never been to Pure//Accelerate. This year, I still am not in Las Vegas. I watched the Everpure Accelerate 2026 opening keynote live from my home office, which turned out to be a different kind of vantage point. Not better than being there. Not worse. Just different. You do not get the hallway energy. You do not get the sponsor booths. You do not get the accidental conversations that happen while looking for coffee (or tea in my case). You do not get to read the room in the same way. You are not surrounded by the noise, the music, the badge lanyards, the customer reactions, or that strange conference feeling where everyone is tired and energized at the same time. A keynote viewed remotely has to work harder because the production does not carry you in the same way. If the speakers are just reading slides, you feel it immediately. If the story is thin, the distance makes it thinner. If the message is only a collection of announcements, you start checking email. But if the story is real, the distance does something interesting. It removes some of the theater. You are left with the words, the pacing, the ideas, and whether the people on stage actually believe what they are saying. This morning, the parts that landed with me were not the parts that felt the most polished. They were the parts where the keynote stopped sounding like a keynote and started sounding like people trying to explain a real shift in the industry. For me, the strongest moments came from Charlie Giancarlo, Chadd Kenney, Shawn Rosemarin, and the NVIDIA conversation. Not because they had the most slides. Not because they had the most numbers. They landed because they are storytellers. That matters more than we sometimes admit in enterprise technology. A slide reader can tell you what a product does. A storyteller can tell you why the product had to exist and why it matters to the customer or partner. There is a difference. And this morning, the difference mattered. Charlie’s most important line came early, and it changed the shape of the keynote. He said he was not going to talk about data storage. He was going to talk about data. For a storage company’s major customer event, that is not a small pivot. It would have been easy for Everpure to spend the morning celebrating the familiar things. Growth. Customer count. Market share. Flash leadership. Subscription run rate. Fusion adoption. Gartner recognition. Net Promoter Score. Performance numbers. Efficiency numbers. All of that was there, and all of that matters. But the real keynote was not about proving that Everpure is good at storage. The real keynote was about arguing that storage is no longer the highest-level conversation. Data is. That is where the rebrand from Pure Storage to Everpure starts to become more than a name change. A company called Pure Storage can be excellent at arrays, controllers, upgrades, density, performance, and simplicity. A company called Everpure has to earn the right to talk about the enterprise data cloud, and that is a much larger promise. It is also a much riskier promise. Because once you move north of storage, you are no longer talking only about where data lives. You are talking about who controls it, who understands it, who governs it, who protects it, and who gets to use it. That is where Charlie’s message became interesting. His argument was that the enterprise has spent decades living in an application-centric architecture. ERP had one version of the business. CRM had another. ServiceNow had another. HR systems had another. Analytics platforms copied data out of all of them. Data lakes were built to make sense of the mess. Now AI agents are being asked to reason across that same fragmented landscape. That is the problem. Not AI in theory. AI on top of fragmented truth. We have all seen some version of this. The definition of a customer changes depending on which system you ask. The data in one application does not quite match the data in another. A report is technically correct, but only according to one source. A copy was made for analytics, another for backup, another for a project, another for a data science team, and one more because someone needed it urgently two years ago and nobody knows if it is still being used. Now imagine asking an AI agent to act on that. That is where the phrase “Data Primacy” becomes more than keynote language. From what I understood this morning, Data Primacy is Everpure’s argument that data should no longer be trapped inside applications as a secondary object. The data itself, along with its context, relationships, governance, and sources of truth, has to become primary. Applications still matter. Workflows still matter. SaaS still matters. But the enterprise cannot keep allowing every application to define its own version of reality and then expect AI to make intelligent decisions across the pile. That is not sustainable. One of the strongest lines from Charlie was the idea that every vendor wants your data. Every SaaS vendor wants your data. Every analytics vendor wants your data. Every AI vendor wants your data. But what they really want is not just the data. They want the context. They want the meaning. They want to know how a customer in one system relates to a contract in another, a support case in another, an invoice in another, a shipment in another, a security policy in another, and a business outcome somewhere else entirely. In the AI era, context is the new land grab. That is the sentence I kept coming back to during the keynote. Everyone wants your data, but the bigger fight is over who owns the context. That is why this morning did not feel like just another AI infrastructure pitch. It felt like Everpure trying to move the conversation from managing arrays to managing truth. That is a big claim. It needs proof. And that is where Chadd Kenney’s part of the keynote mattered. Chadd is one of those speakers who can make infrastructure feel like an actual story instead of a list of capabilities. That is not easy. Storage features can get very technical very quickly, and if you are not careful, everything turns into a blur of replication, snapshots, policies, performance, controllers, and acronyms. But Chadd framed the platform in a way that made sense. First, the unified data plane stores the data. Then the intelligent control plane governs and operates it. Then the universal data intelligence layer helps understand it. Together, those pieces create a different operating model. That phrase, operating model, is important. Because the most interesting part of the demo was not just that Fusion can automate tasks. It was that Everpure is trying to change the relationship between people and infrastructure. The old world asks humans to be perfect by hand. Log into this array. Check that policy. Fix that snapshot setting. Compare it to the spreadsheet. Make sure the production workloads are covered. Exclude dev and test. Check compliance. Update the retention period. Open the change. Wait for the window. Hope nobody missed one. We have normalized that kind of work for years. Then we call it operational discipline. Sometimes it is. But sometimes it is just human beings being forced to compensate for systems that do not understand intent. The Fusion demos showed something better. Define the policy once. Attach intent to the workload. Let the control plane detect drift. Let it show violations. Let it recommend a fix. In some cases, let it act. In other cases, keep the human in the loop, but stop making the human do repetitive work that the platform should be able to understand. The ransomware snapshot example was a perfect illustration. A customer mandate changes retention from fifteen days to thirty days. In many environments, that becomes a manual chase across infrastructure. In the keynote demo, it became a policy problem, a compliance view, a remediation path, and an audit trail. That is what infrastructure teams actually need. Not another dashboard that tells them something is broken. A system that understands what “correct” looks like and helps keep the environment there. The workload mobility demo made the same point from a performance angle. If the platform can see that a workload is trending toward a service level violation, recommend a better placement, validate the move, and relocate that workload without the application owner noticing, that is not just automation. That is infrastructure keeping a promise quietly. And quiet matters. The best infrastructure usually disappears. Nobody sends a thank-you note because latency did not spike. Nobody opens a champagne bottle because a replication policy worked. Nobody celebrates the outage that did not happen. But those invisible wins are the difference between a team that spends its life firefighting and a team that gets to work on the next thing. That is why the Active Cluster for File demo also worked. Synchronous replication for file sounds technical, and it is. But the emotional value is simple. When something fails, the business does not want a heroic recovery story. It wants no story at all. The workload quietly packed its bags and moved. That line stayed with me because disaster recovery should be boring. Boring is the goal. Boring means the policy worked, the automation worked, the architecture worked, and the humans did not have to assemble on a bridge call at 2 a.m. to save the day. Then Shawn Rosemarin took the keynote into the AI conversation, and again, the strength was in the framing. The bottleneck stalling AI is not compute. It is not models. It is not tooling. It is data. That is the part of the AI conversation that I think many customers are starting to feel more clearly. For the last few years, the market has been obsessed with models and GPUs. That made sense. There was a lot to understand, and the infrastructure requirements are real. But most customers are not trying to build the next frontier model. They are trying to unlock the intelligence that already exists inside their own business. Their documents. Their contracts. Their transactions. Their support history. Their clinical records. Their policies. Their engineering files. Their internal knowledge. Their institutional memory. That does not become useful just because someone points a model at it. It becomes useful when the data is prepared, classified, curated, governed, indexed, vectorized, and delivered with the right context at the right time. That is why the Everpure Data Stream announcement with NVIDIA mattered. The message was not simply, “We can feed GPUs fast,” although performance absolutely matters. The more important message was that enterprise AI needs a way to make data AI-ready without creating another silo, another copy, another stale version of the truth. Shawn made the point clearly: other vendors want you to copy your data into their system. But a copy is always behind. That is such a simple sentence, but it carries a lot of weight. A copy has to be protected. A copy has to be governed. A copy has to be reconciled. A copy has to be secured. A copy can drift. If AI is going to answer questions, automate workflows, make recommendations, or support decisions, stale context is not just inefficient. It is dangerous. That is where the NVIDIA conversation added credibility. The point was not just that Everpure has a partner logo on a slide. The point was that AI has become a full-stack infrastructure problem. Data has to move efficiently. GPUs cannot sit idle waiting for bytes. Inference needs low latency and quick access to the right information. Agents need context. Networking matters. Storage matters. Hardware matters again. I liked the line about hardware being cool again. I liked it because it is funny, but also because it is true. For years, parts of the industry talked as if infrastructure had become invisible. Cloud abstracted it. SaaS hid it. Software ate the world, and many people acted as if the physical layer was someone else’s problem. AI ended that illusion. When customers are investing serious money in GPUs and trying to build real AI capability, storage is not a commodity. Networking is not plumbing. Metadata performance is not trivia. Power is not someone else’s concern. Operational excellence is not optional. The physical world is back in the strategy conversation. Maybe it never left. Maybe some people just stopped looking. That is why the keynote worked for me, even from my home office. Not because every demo was relevant to every customer. Not because every phrase was perfect. Not because I think one keynote answers every question. That is what the next two days are for. It worked because the best speakers were not just announcing things. They were connecting the dots. Charlie explained why the application-centric model is running out of room. Chadd showed what it looks like when infrastructure starts operating from intent instead of manual heroics. Shawn connected AI success back to data readiness instead of model worship. The NVIDIA conversation reminded everyone that AI is not magic. It is infrastructure, data movement, context, governance, and execution. That is a story. And in enterprise technology, the story matters because customers are not just buying features. They are buying a way out of the mess they are already in. The mess is fragmentation. AI did not create that mess, but AI is making it impossible to ignore. That may be the real takeaway from day one of Accelerate. The AI era is forcing enterprises to confront the data architecture choices they have been living with for decades. The old model was manageable when humans were the ones reconciling the gaps. It becomes much more dangerous when agents begin acting on top of those gaps at machine speed. That is why Everpure’s move toward Data Primacy is worth paying attention to. It is not just a product direction. It is a point of view. The application should not own the truth. The copy should not become the truth. The dashboard should not pretend to be the truth. The enterprise needs to own its data, understand its context, govern its use, and make it available to applications, analytics, and AI in a way that is coherent and trustworthy. That is easy to say and very hard to do. But this morning, for the first time, I felt the full shape of what Everpure is trying to become after the rebrand. Not just a storage company with a new name. Not just a platform company using AI language because everyone has to. But a company trying to move the enterprise conversation north of storage and into the question that will define the next decade: Who owns the context of your business? Because everyone wants your data. The companies that win will be the ones that know what it means. I appreciate you reading. Dmitry Gorbatov © 2025 Dmitry Gorbatov | #dmitrywashereClaude Code as Database SRE: Catching What Your Monitoring Never Will with Everpure Fusion MCP
Your DR site might be quietly unprotected and no alert will tell you. That's the gap Anthony Nocentino, Principal Architect at Everpure, Microsoft Data Platform MVP, and self-described computer nerd set out to catch. He built a Database SRE agent using Claude Code and the Everpure Fusion MCP server to audit SQL Server fleets against compliance policy, uncovering a silently unprotected DR instance before disaster struck. Read the full report at "Using Claude Code as a Database SRE Agent with the Everpure Fusion MCP Server"Get rid of stressful infrastructure headaches. Everpure Fusion handles your data, autonomously.
It happens! It's 11:45 PM on a Friday. An alert fires and storage latency has spiked across a production workload. The operator digs in and traces it back to an automated tiering policy that quietly moved a hot dataset to a slower tier because it looked idle based on a 24-hour access window, right before a scheduled batch job that runs every weekend. Nobody changed anything. The policy did exactly what it was configured to do. But nobody remembers configuring it that way, the documentation hasn't been touched in two years, and the monitoring dashboard shows storage as "healthy" because utilization is fine. It's just in the wrong place. The operator overrides the tier, performance recovers, and spends the next hour writing an incident report for a problem that shouldn't exist. A system that was supposed to make life easier made a decision with no context, no warning, and no visibility into why. That's the anger that doesn't go away quickly. It's not just frustration at the incident. It's the feeling that the tools are working against you instead of with you. The core problem in that story was a system making decisions with no context, no warning, and no visibility. Everpure Fusion attacks each of those problems: Unified visibility across the entire fleet: Everpure Fusion provides a global dataset as a single source of truth for discovery, management, and configuration of storage arrays so the operator isn't piecing together what happened across multiple dashboards, multiple arrays, multiple tickets after the fact. They see the full picture in one place, before things go wrong. Intelligent workload placement: Rather than static policies quietly acting on stale access patterns, Everpure Fusion uses AI-guided placement to boost performance and efficiency for every workload. It understands workload behavior, not just utilization snapshots, the kind of context that would have caught a batch job pattern before tiering the dataset down. Policy-driven governance with real control: Automated orchestration cuts manual tasks and speeds service delivery, while unified controls simplify audits, reduce risk, and prove compliance fast. Policies are visible, documented, and governable. Not buried configs nobody remembers setting. Built into the platform, not bolted on: Evepure Fusion is now simply a part of Purity, meaning it is not an add-on you have to install or buy, but rather a core piece of the Purity operating system. The operator doesn't have to manage another tool. The intelligence is already there. The operator in that story didn't need more alerts. They needed a system that understood context, made decisions transparently, and gave them control without requiring them to be online at midnight to maintain it. That's exactly the gap Everpure Fusion is designed to close - with One Fleet, Zero Complexity. Why policy-driven storage operations matter Everpure Fusion is built as the core of Everpure intelligent control plane that manages all arrays including FlashArray, FlashBlade, and cloud as a unified fleet, with one topology, one API, and one operational framework regardless of protocol or local - datacenter, cloud or edge. That uniformity is what makes policy enforcement reliable at scale. Everpure Fusion introduces workload-based provisioning through presets, which are predefined policy-driven templates for specific workload types, encoding protection policies, replication, and SafeMode retention from the moment a workload is provisioned, not patched in after an incident. Admins no longer need to pre-plan and tune deployments manually, which reduces the risk of non-compliance and improves resiliency by ensuring workloads are provisioned correctly from the beginning. The result is infrastructure that enforces your intent, not just your last manual action. Intelligent placement, rebalancing, and fleet-scale capacity control If you manage storage at scale, you've probably seen this scenario play out more than once. One array is buried, running hot, and screaming for relief. Three aisles over, another array is sitting at 40% utilization, doing almost nothing. And somewhere in between, your team is scrambling to provision capacity, kick off an emergency migration, and explain to stakeholders why an SLA was missed on a workload that, in hindsight, never should have been placed there in the first place. This is not a people problem. It is a tooling problem. And it is remarkably common. Everpure Fusion starts solving this problem at the moment of provisioning. When a new workload lands, most storage systems do a simple capacity check and place it wherever space is available. Everpure Fusion does something fundamentally different. The placement engine evaluates every array in the fleet simultaneously, looking at IOPS headroom, throughput capacity, and physical utilization before making a decision. The goal is not just to find somewhere to put the workload. It is to find the right home for it, one where it can live comfortably for the long term without creating a bottleneck down the road. Think of it as placing workloads with intention rather than convenience. Of course, environments do not stay static. Workloads grow, usage patterns shift, and an array that looked healthy six months ago can become a problem today. Everpure Fusion accounts for this with continuous rebalancing built directly into its operation. When an array starts trending toward overload, Everpure Fusion detects it and begins orchestrating data movement across the fleet automatically. No manual intervention required. No application downtime. Data migrates in the background while workloads keep running, and arrays that were sitting underutilized suddenly become productive members of your infrastructure. At fleet scale, now supporting up to 64 arrays, this turns capacity management from a constant firefight into something that largely runs itself. What makes this possible without disruption is how Everpure Fusion executes the move under the hood. It leverages ActiveCluster to stretch the volume across both the source and target arrays simultaneously, creating a synchronous mirror in place. Once the stretch is established, volumes are connected on the target array and hosts auto-discover the new target paths through standard multipathing. The target then validates that path usage is healthy and confirmed before any cutover begins. Only after that validation is complete are the volumes disconnected from the source, ensuring there is zero gap in access at any point in the sequence. Everpure Fusion then unstretches from the source array to complete the rebalance and release its capacity. The result is a seamless, non-disruptive migration that the application never sees. What truly sets Everpure Fusion apart from a standard load balancer is what happens under the hood. Powered by Pure1 AI and up to 30 days of historical workload data, Everpure Fusion does not just look at what is happening right now. It looks at what is about to happen. Say you have a workload that runs a heavy batch job every Saturday night. Everpure Fusion knows that. It has seen the pattern. So when the placement engine is evaluating tier assignments, it will never recommend moving that workload to a lower-performance tier just because it looks quiet on a Tuesday afternoon. It understands what Tuesday quiet actually means in context. And if that workload somehow ends up on the wrong tier, perhaps through a manual change or a migration gone sideways, Everpure Fusion will proactively raise a violation before the weekend arrives. Not after the SLA is missed. Before. The cumulative effect is that customers can operate their fleets closer to full utilization without the anxiety that normally comes with it. Underused hardware gets activated, incremental purchases get deferred, and the reactive, always-behind-the-curve model of capacity management starts to look like a problem from a previous era. And Everpure Fusion does not stop at the infrastructure layer. Through its integration with Pure1 Application Intelligence, Everpure Fusion gains deeper visibility into the nature of the workloads themselves, not just how they behave, but what they actually are. That additional context means smarter decisions at every level, from initial placement to long-term tier management, grounded in a more complete picture of what your environment is really doing. Workload rebalance and mobility will be available towards the end of 2026. Compliance as part of the control plane Most storage compliance workflows follow the same pattern: an audit is announced, someone pulls reports from three different tools, cross-references configuration against a spreadsheet of expected settings, and spends two weeks proving that workloads are protected the way they're supposed to be. Then the audit ends and nothing changes until the next one. That model breaks at fleet scale. When you're managing dozens of arrays across multiple sites and protocols, manual audits don't just slow you down — they leave gaps that only get discovered at the worst possible time. Everpure Fusion Compliance is built into the control plane, not bolted on after provisioning. Because Everpure Fusion presets encode protection policies, replication requirements, SafeMode retention, and QoS settings at deployment time, Everpure Fusion always knows what every workload's intended configuration is. Drift detection is continuous — not periodic. When a workload deviates from its preset, Everpure Fusion instantly surfaces the violation — visible in the UI, queryable via API or CLI, and accessible to AI agents through an MCP server. Remediation can be triggered directly through the same interfaces, without pulling in a separate tool or writing a custom script. Fleet-wide compliance dashboards give storage admins a live view of posture across every array, with exportable audit-ready reports that don't require manual assembly. The shift is meaningful: compliance becomes a property of how the fleet operates, not a project that interrupts how the team works. Everpure Fusion Compliance will be available towards the end of 2026. From dashboards and scripts to natural-language fleet operations You know the drill. A latency spike hits production. You open three dashboards, run a handful of CLI queries, dig through alert logs, and piece together enough context to understand what happened — and by then, you've already spent 45 minutes on a problem that should have taken five. The issue isn't the tools. It's that the context your fleet holds is trapped across systems that don't talk to each other. Everpure Fusion MCP Server changes that. Built on the open Model Context Protocol standard, it connects any MCP-compatible AI assistant — Claude, ChatGPT, Copilot, or internal agents — directly to live Everpure Fusion fleet state. Arrays, workloads, capacity, performance metrics, alert history, configuration, and placement data are normalized into clean, structured JSON and made available to AI in real time, pulled directly from Everpure Fusion and Purity REST APIs. The result: instead of navigating dashboards and stitching together CLI output, you ask a question. "Which arrays are approaching capacity?" "What's driving latency on this workload?" "Which workloads are drifting from their preset?" Everpure Fusion MCP Server answers from live fleet context, not stale snapshots. This is the on-ramp to agentic storage operations. Everpure Fusion already enforces policy and placement across the fleet. Pure1 adds AI-driven analytics and recommendations on top. Together, they give infrastructure operators the foundation to move from reactive troubleshooting to intent-driven, increasingly autonomous fleet management. Using topology groups to encode real infrastructure boundaries If your Everpure Fusion fleet's topology model lives in a color-coded spreadsheet, three wikis, and the institutional memory of one senior admin who never takes vacation — this is for you. Everpure Fusion, built into Purity for FlashArray and FlashBlade, introduces Topology Groups: fleet-scoped objects that let you describe your arrays in the same language your architecture diagrams already use — regions, availability zones, datacenters, rows, racks. No more provisioning a Everpure Fusion workload and hoping it lands in the right building. A Everpure Fusion Topology Group is a hierarchical, tree-structured object. Groups nest up to 10 levels deep (global → us-east → az-us-east-1a → dc01 → row3 → rack12), each array belongs to exactly one parent, and cycles are rejected at write time. Critically, they encode placement semantics — not access control. RBAC stays in Pure1 Resource Groups; topology stays in Everpure Fusion topology. Once modeled, Everpure Fusion presets reference groups using <group>.arrays notation. Everpure Fusion intersects the preset's allowed arrays with the group's membership at placement time. If there's no overlap, Everpure Fusion provisioning fails fast with a clear error — not silently in the wrong zone. The Everpure Fusion CLI shorthand makes automation clean: purevol list --context az-us-east-1a.arrays Everpure Fusion membership changes propagate automatically across the fleet. You stop maintaining a second source of truth outside the control plane. Stop treating topology as tribal knowledge. With Everpure Fusion, make it a first-class part of the intelligent control plane. Extending the model to Kubernetes and virtualization Most infrastructure operators are managing two parallel storage worlds right now: traditional VMs and databases on one side, Kubernetes-based containerized workloads on the other. Separate toolchains. Separate provisioning workflows. Separate everything. Everpure Fusion changes that. Through the Portworx Fusion Controller, Everpure Fusion extends its policy and placement control plane directly into Kubernetes — without forcing developers to change their existing workflows. Everpure Fusion auto-discovers your FlashArray and FlashBlade fleet, then exposes Everpure Fusion presets as native Kubernetes StorageClasses. That means when a developer requests a persistent volume, Everpure Fusion's placement engine resolves it against your existing policy constraints — storage class, protection policy, topology group, replication requirements — the same way it does for any other Everpure Fusion workload. No separate control plane for modern environments. No array-by-array configuration for each cluster. New arrays added to the fleet are automatically discovered and configured, so the operational model stays consistent as infrastructure grows. For VMware environments, Everpure Fusion extends the same operational model through the Everpure Fusion vSphere plugin, connecting storage management directly into virtualization workflows instead of running it as a separate administrative domain. The result: one control plane, one set of policies, one placement engine — spanning VMs, containers, and databases across the fleet. That is fewer parallel stacks to operate, less configuration drift between environments, and a more scalable path to consistent storage operations across the full infrastructure stack. Everpure Fusion as the storage admin foundation for autonomous operations The through-line across everything covered in this blog is simple: Everpure Fusion gives infrastructure operators a unified, policy-driven control plane that enforces intent consistently — across provisioning, placement, compliance, topology, and now Kubernetes and virtualization. That foundation matters because autonomous storage operations do not start with AI. They start with structure. Topology groups encode where workloads belong. Presets encode how they should be configured. Everpure Fusion presets exposed as StorageClasses ensure Kubernetes environments follow the same rules as everything else. When that structure is in place, AI can recommend, optimize, and eventually act — because the context is already clean, trusted, and machine-readable. For storage admins, the shift is real: less time resolving incidents caused by placement decisions nobody remembers making, more time defining the intent that governs the fleet. Everpure Fusion is that foundation — built into Purity, not bolted on. Want to learn more about Everpure Fusion? Check out the following links to dive deeper: Join the Everpure Fusion Mastery Program to build expertise, complete hands-on activities and earn rewards. Sign up for a Fusion test drive to try it out on your own time. Check out more about Fusion product details. Watch our cool new Fusion demo videos. Read Everpure Fusion Datasheet
