Persistent vs Non-Persistent VDI: Five Differences That Decide Your Architecture

The persistent versus non-persistent debate is one of those topics where the vendor slide decks have oversimplified the decision into a false binary. In practice, most VDI estates we run are a mix — and the mix is driven by five differences that actually matter when you're the one paying the storage bill and answering the pager at 2 a.m. We've been building and running virtual desktops since before Citrix owned the category outright, and we have put more than a million seats into production. Here is what actually matters.

1. Who Owns the Mess Inside the Desktop

A persistent desktop is, for all practical purposes, a physical PC that happens to live on a hypervisor. The user can install things. Settings persist. Drive letters stay mapped. The Outlook cache rebuilds itself exactly once and stays put. From the user's perspective, this is the thing they want.

A non-persistent desktop wipes itself on logout (or on reboot, depending on how you pool it) and hands the next user a freshly minted image. From the operations team's perspective, this is the thing they want.

The honest answer is that whoever wins this argument in your organization is telling you something about where the operational burden is going to sit. Persistent VDI pushes the burden onto your patching, imaging, and antivirus tooling — you have to keep hundreds or thousands of running desktops compliant. Non-persistent pushes the burden onto profile management, application layering, and user data redirection — you have to make a freshly minted desktop look like the user's old one in under ten seconds without them noticing.

There is no free lunch. Pick the burden you have the skills to carry.

2. Storage Cost and the IOPS Reality

A persistent 100 GB desktop for 1,000 users is 100 TB of storage, and every byte of it needs to be on something fast enough to boot Windows in under twenty seconds during a 9 a.m. login storm. Even with deduplication and compression at 4:1, you are on the hook for 25 TB of flash, plus the backup copies, plus snapshots.

A non-persistent pool of the same 1,000 users might run on a single 100 GB golden image plus a write-cache differential per session. The total storage footprint is often 80 to 90 percent smaller. The IOPS profile is also completely different — writes are ephemeral and can live on cheap local NVMe inside each host instead of on the shared array.

If your CFO cares about capital efficiency, non-persistent wins this category in a landslide. The only catch is that storage is cheaper now than it was in 2012, and the gap isn't as decisive as it used to be. Against that, remember that you are paying for it every year, not once.

3. Login Time Is Your Real Service Level

Users do not care about your architecture. They care that when they double-click the icon in the morning, their desktop appears with Outlook, their browser tabs, and their network drives inside of thirty seconds. Anything worse than that and your help desk will hear about it.

Persistent desktops win login time by default because the profile is already there. The desktop was running overnight (or was resumed from a saved state), the user's settings are intact, and the first logon is the only slow one.

Non-persistent desktops need a full profile rehydration on every login. If your profile container is on a slow file share, if your application layering is heavy, or if you have a couple of gigabytes of OneDrive cache to reattach, you will feel it. Getting non-persistent logons under thirty seconds is achievable but it is a project, not a checkbox. FSLogix done right gets you there. FSLogix done wrong gets you 90-second logons and angry users.

4. Patching, Image Updates, and the Weekend Maintenance Window

Here is where non-persistent earns its keep. Patching a thousand persistent desktops means Tuesday night WSUS pushes, reboots during the maintenance window, and a help desk full of "my machine is stuck installing updates" tickets every month.

Patching a thousand non-persistent desktops means patching one golden image, running it through a test pool, and scheduling a rolling pool refresh. When users log off, they get the new image. When they log in the next morning, they are on the patched version and they never had to wait for anything. Rollback is equally clean — revert the pool to the previous image version and the users are back on the known-good build in minutes.

If you have a mature image factory, non-persistent cuts your patching labor by roughly an order of magnitude. If you do not have an image factory, non-persistent will make your life miserable until you build one.

5. What Happens When a User Needs Admin Rights

This is the difference that nobody talks about in the vendor decks, and it is the one that decides more architectures than any other. Developers, engineers, data scientists, and power users need to install things. They need to run old versions of ODBC drivers alongside new ones. They need to point Visual Studio at a specific SDK version. They need to debug a process with elevated permissions.

On a persistent desktop, you give them admin rights on their own VM and move on with your life. On a non-persistent desktop, every install either has to be packaged into the golden image (slow, political, and bureaucratic) or layered in via App Volumes or MSIX app attach (faster, but still not the same as "just install it"). Neither of those makes a developer happy.

The pattern we use most often is a split: knowledge workers, call center staff, task-based users, and shared kiosks all go onto non-persistent pools because the operational savings are enormous and these users do not miss what they never had. Developers, finance power users running old Excel macros, marketing people with design tools, and executives with custom workflows go onto persistent desktops because fighting them is more expensive than the storage.

What We'd Actually Do

For a new VDI estate of 1,000 to 5,000 seats, we typically recommend roughly 70 percent non-persistent and 30 percent persistent. The non-persistent pools run on host-local NVMe with FSLogix profile containers on a fast SMB share. The persistent pools run on a tiered all-flash array with nightly snapshots and weekly backups to object storage.

Whatever you do, do not let a single vendor talk you into all-persistent because "users expect it" or all-non-persistent because "it's cheaper." Both answers are lazy. Your user population is not homogeneous and your architecture should not pretend it is.

Three Takeaways

1. Non-persistent saves real money on storage and patching, but you pay for it in profile engineering and application layering. Budget the skills, not just the licenses.
2. Persistent is not obsolete. It is the right answer for power users and developers, and it always will be. The question is how small you can make that population.
3. Login time is the metric users judge you on. Whichever model you pick, measure logon duration at the 95th percentile and treat it as a service level, not a nice-to-have.