Cloud storage is sold under three category names: object, block, and file. Each maps to a different access pattern. The names sound interchangeable. They are not. Pick the wrong one and you end up paying more, hitting performance walls, or rewriting your application.
Block, File, And Object
Block storage is a virtual disk attached to one VM. The hypervisor presents it as /dev/vdb, you format it with ext4 or NTFS, and the OS reads and writes 4 KB blocks the same way it talks to a physical SSD. Only one VM mounts a given volume at a time. The canonical hyperscaler example is Amazon EBS. On ZCP, block storage is backed by Ceph RBD.
File storage is a shared mount across multiple VMs. You speak NFS (Linux) or SMB (Windows) to the storage backend and several VMs read and write the same directory tree concurrently with POSIX semantics. Amazon EFS is the reference. Use it for shared application data, build caches, media libraries, content roots, and any workload where two or more VMs need to see the same files.
Object storage is addressable over HTTP. Each object has a key, some bytes, and metadata. You PUT and GET it through an S3-compatible API. There is no filesystem, no mount, no concept of “attached to a VM”. Amazon S3 defined the category in 2006 and the API is now a de facto standard supported by boto3, the AWS CLI, rclone, and most backup tools.
When to use which
Use block when the workload expects a real disk: database engines (PostgreSQL, MySQL, MongoDB), VM root volumes, write-ahead logs, and small random I/O at low latency. One VM, one volume.
Use file when multiple VMs need to read and write the same paths at once: a web tier serving uploaded assets from three application servers, a render farm, a Windows file share replacement.
Use object for everything else with bulk unstructured data: backups, logs, build artifacts, container images, video, large datasets, static site assets, anything you’d otherwise dump on a NAS but want to access from code over HTTP.
ZCP pricing, side by side
Here are the real per-GB numbers as of 2026-05-16:
| Service | Backend | Price | Access |
|---|---|---|---|
| Block, rbd-fast (NVMe) | Ceph RBD | $0.11 / GB / mo | Single VM |
| Block, rbd-standard | Ceph RBD | $0.07 / GB / mo | Single VM |
| Block, rbd-bulk (HDD) | Ceph RBD | $0.04 / GB / mo | Single VM |
| File (NFS / SMB) | Ceph | $0.10 / GB / mo | Multi-VM, Linux + Windows |
| Object (S3-compatible) | Ceph RGW | $0.024 / GB / mo, $0 ingress, $0 egress | HTTP API |
Block storage has a 10 GB minimum and supports online expansion and on-demand snapshots. Object storage charges nothing for ingress or egress, which makes it the right place for data read often or moved out of the platform.
A 1 TB database fits rbd-fast for $113/mo. The same TB of nightly backups belongs in object storage at $25/mo, about a quarter of the price, with zero egress fees when you eventually need to restore.
The rule, when you’re not sure
If you are unsure: use object storage for unstructured data, and block storage for databases. This heuristic gets the answer right most of the time. Reach for file storage only when multiple VMs need to share a mutable filesystem, and consider whether an S3 bucket with a sync would do the same job for less.