How to choose between object storage, block storage, and file systems

Three Storage Types

Storage choice depends on access pattern, not just cost. Using the wrong type creates performance problems no amount of scaling fixes.

Object Storage (e.g., S3, GCS)

• Flat namespace of key-value pairs. Each object has a unique key and metadata.
• Access via HTTP API. No file system abstraction.
• Infinite scale, lowest cost. Ideal for images, videos, backups, data lake files.
• Not suitable for: databases, random read/write workloads.

Block Storage (e.g., EBS, Azure Disk)

• Raw disk volumes attached to a single VM.
• Low-latency, random read/write. Databases (MySQL, PostgreSQL) run on block storage.
• Expensive, tied to one instance, limited size.

File Storage (e.g., EFS, NFS)

• Shared file system mounted by multiple instances simultaneously.
• Suitable for shared config files, ML training datasets accessed by multiple workers.
• Higher latency than block, more expensive than object.

# Upload to S3 (object storage)
aws s3 cp ./video.mp4 s3://my-bucket/videos/video.mp4

# Mount EFS (file storage) on Linux
mount -t nfs4 fs-12345.efs.us-east-1.amazonaws.com:/ /mnt/efs

In system design interviews: user uploads → object storage. Database → block storage. Shared config → file storage.