A data-driven recommendation to consolidate nine aging FlashArrays into two modern, right-sized systems for the Oracle 19c estate — now corroborated in the Everpure Sizer — plus a third, dedicated array to absorb ~1 PiB of new VDI, VM, and container workloads the client has asked us to accommodate.
The nine-array Oracle estate consolidates onto two balanced FA-X70R5 systems — corroborated in the Everpure Sizer. The additional ~1 PiB of new VDI/VM/container workloads is best placed on a third, dedicated array — the Everpure Sizer corroborated a single FA-X90R5 for the expected case, and its computed 2.33:1 data reduction matched our estimate almost exactly. This isolates the high-IO MongoDB tier and quarantines estimation risk. Combined recommended estate: three arrays.
The nine Santa Clara systems are a single Oracle 19c database estate — a conclusion written directly into the volume inventory: of 565 volumes, 112 carry the -19c Oracle Database 19c tag (57 of them -19c-stdby Data Guard standbys), alongside Oracle redo-log volumes (volupredo1/2) and oracle- host-named volumes, with every one of the nine arrays showing at least one direct Oracle signature. The estate spans a mix of aging and current-generation hardware — from FA-M20R2 and FA-X50R3 boxes through to FA-X50R5 and FA-X90R5. Several arrays are near capacity and on older Purity releases. Consolidating them onto two modern arrays simplifies operations, refreshes the lifecycle, and creates consistent performance and data-reduction behavior across the whole estate.
The two heaviest systems are deliberately split across separate targets so neither runs hot. Capacity and performance land within a few percent of each other on both boxes. Sizing is driven by effective used capacity (the real host-written data that must land, not raw physical footprint) and by sustained (P95) load, with peak retained as the worst-case headroom check.
Beyond the Oracle estate, the client asked us to absorb ~1 PiB of workloads currently on local disk — 600 VDI, 800 VMs, and 4,000+ containers, of which ~500 TiB is high-IO MongoDB and data processing. No telemetry exists for these yet, so they are sized from reference-architecture assumptions and reported as a range. These figures are estimates, deliberately kept separate from the measured Oracle work.
Blending would re-open a Sizer-corroborated result and dilute it with estimates.
When real telemetry arrives, only the new array is re-sized — not the whole estate.
Both Oracle arrays came back performance-limited at ~71% full (X1 at 77% of max performance, X2 at 66%), so they have limited performance headroom to absorb new load. High-IO MongoDB/data-processing is kept off the latency-sensitive Oracle targets.
The figures below are the raw hardware capability of each selected array — usable capacity before data reduction and estimated maximum performance — so dedupe assumptions can be normalized independently. Effective (host-written) capacity is simply usable × the array’s data-reduction ratio; all three configs are performance-limited, not capacity-limited.
Raw = installed media capacity. Usable = pre-dedupe capacity after RAID/formatting. Max IOPS = estimated performance ceiling for the config; Targets A/B/C use 77% / 66% / 65% of that ceiling at the modeled load. Latency shown as estimated block read/write range at the modeled load. Targets A–B (Oracle) are measured; Target C (new workloads) is a reference estimate.
These are neutral, workload-anchored gates any candidate platform should be held to. Each is framed by its impact on Client Y's performance SLA — not by vendor. If an alternative cannot evidence all three, the gap surfaces later as missed SLAs on the Oracle and MongoDB workloads.
Client Y's Oracle redo/undo and MongoDB ingest are sustained 8–16 KiB random writes — not bursty. Any architecture that buffers writes in a cache tier and destages to QLC must prove it holds latency once that buffer is under continuous pressure at scale. Diligence should require recent references in a transactional-database estate of comparable block profile — not AI, analytics, or large-file benchmarks. Unproven, the exposure is Oracle transaction latency and MongoDB write-stall at peak.
The design assumes production fill with reduction and encryption enabled. The requirement is demonstrated latency at 80–95% capacity with those services on — not cache-warmed, features-off numbers. Unproven, the risk is latency degradation exactly as the estate fills, when it matters most.
Client Y is consolidating a live estate; cutover cannot wait on hardware. The requirement is a contractual installed-and-production date. Uncommitted, the risk is a stalled migration and extended run-on of the aging arrays being retired.
Flash lead times have stretched dramatically. At CES 2026, the CTO of one prominent all-flash competitor publicly stated lead times have reached up to 52 weeks and that "availability is the number one buying determinant" in the current market. The recommended design consolidates onto an existing, multi-source-supplied DFM platform — materially de-risking delivery versus any greenfield build dependent on net-new QLC hardware.
The lowest acquisition cost is not the lowest total risk. If selection optimizes on price without validating these three gates, the cost resurfaces as missed performance SLAs on the Oracle and MongoDB workloads.
Every capacity and performance number derives from 30 days of continuous telemetry sampled every 30 seconds — full resolution, no roll-up, ~86,000 samples per array.
Capacity is expressed as effective used (host-written) data — the basis the Everpure Sizer and Evergreen//One consume — never raw or usable capacity.
Each array was profiled by Oracle role, block size, and read/write mix, so co-location decisions reflect real I/O behavior, not just totals.
Targets are sized to sustained load with peak retained as a check, and a +25% uplift is applied to write-heavy workloads per sizing guidance.
Measured Oracle work and estimated new-workload sizing are kept separate — nothing estimated is shown with more confidence than it earns.
Oracle: 2 × FA-X70R5 (validated). New workloads: 1 × FA-X90R5 for the expected case, flexing to 2× under the high-sensitivity scenario.
Track 2 is sized from reference assumptions. Capture real telemetry once the workloads land and re-size; the MongoDB DRR and IOPS are the parameters most likely to move the result (1× vs 2× new arrays).
Standby (replica) volumes were detected on several arrays. Confirming whether they remain on-target or move in a redesign could materially reduce required capacity.
Showed net negative 30-day growth (data deleted or migrated). Verify it is not mid-migration so its steady-state footprint isn't understated.
One of nine arrays is currently mapped to a Pure1 Evergreen//One subscription; the remaining eight need subscription IDs to reconcile measured vs. billed capacity.