Everpure FlashArray//C: capacity-oriented all-flash
FlashArray//C is the capacity member of the FlashArray family, built on QLC DirectFlash media. It targets workloads that want all-flash consistency at a cost per terabyte closer to hybrid storage: file services, virtualisation, test and development, and backup or archive tiers that still need predictable response. The R5 line covers //C50, //C70 and //C90.
Technical specification
| Model | Type | Maximum capacity | Controller | Protocols | Drive type | Rack U |
|---|---|---|---|---|---|---|
| FlashArray//C50 R5 | Capacity-oriented all-flash (QLC) | – | Dual controller | NVMe and NVMe-oF (FC, RoCE, TCP), SMB, NFS | QLC DirectFlash Module | – |
| FlashArray//C70 R5 | Capacity-oriented all-flash (QLC) | – | Dual controller | NVMe and NVMe-oF (FC, RoCE, TCP), SMB, NFS | QLC DirectFlash Module | – |
| FlashArray//C90 R5 | Capacity-oriented all-flash (QLC) | – | Dual controller | NVMe and NVMe-oF (FC, RoCE, TCP), SMB, NFS | QLC DirectFlash Module | – |
Source of the values: Everpure FlashArray//C data sheet. The data sheet we hold describes the family but does not publish a per-model capacity table. An en dash means the manufacturer does not publish that value; we do not fill it in with an estimate. Confirm every figure against the current manufacturer document before it is written into a contract.
The references we quote in this family are FlashArray//C50 R5, FlashArray//C70 R5 and FlashArray//C90 R5. Send us the reference if you already have one, or the usable capacity and the protocol you need if you do not, and we will confirm availability and lead time.
Which one should you choose?
QLC is the reason it is cheaper
QLC media stores more bits per cell than the TLC used in //X, which lowers cost per terabyte and lowers write endurance. The array software manages that difference. For read-heavy and mixed workloads it is the right trade; for a write-saturated transactional database it is not.
It is still all-flash, and that is the point
The comparison people should make is not //C against //X but //C against a hybrid array. Against hybrid, //C removes the tiering behaviour where response time depends on whether the data happened to be promoted. Consistency is usually worth more operationally than peak speed.
Same operating environment as the rest of the family
//C runs the same Purity operating environment as //X and //XL, so replication, snapshots and management are identical. If you already run a FlashArray, adding a //C for capacity is an extension of the existing estate rather than a new platform to learn.
Our table is honest about what is missing
The data sheet we hold describes the family without publishing a per-model capacity table, so the capacity, controller and rack cells are blank for all three references. We do not estimate them from the //X figures. Send us the capacity requirement and we will obtain the model-level specification before quoting.
Position it against the workload, not the budget line
//C is often chosen because it is the cheaper FlashArray, which is the wrong reason on its own. The right reason is a workload that is large, read-heavy and sensitive to inconsistent response. If the workload is small and hot, //X is cheaper overall because you buy less of it.
Where it fits, and where it does not
Fits large read-heavy datasets that want predictable flash response at a lower cost per terabyte: file services, virtual desktop estates, test and development copies, and archive tiers. Does not fit a write-saturated transactional workload, where //X is the correct member of the family.
What we need in order to quote it
- Usable capacity required and the read to write ratio
- Whether a FlashArray already exists to replicate with
- Protocols required: block, file or both
- Rack units available
- Growth expected over the subscription term
Request a Quote
Tell us the usable capacity, the protocol and the delivery country. A priced quote comes back within 48 hours, usually with a second option so the trade-off is visible.
