Applies toOCI Block Volume (and boot volumes), OCI File Storage (NFS), OCI Object Storage (Standard, Infrequent Access, Archive tiers), OCI File Storage with Lustre, local NVMe on Dense I/O shapes
#By access method
| Access | Service |
| Block device for one instance (OS, databases, apps) | Block Volume |
| Shared NFS file system for many clients | File Storage |
| Object API (backups, data lakes, media, logs) | Object Storage |
| Parallel high-throughput file system for HPC/AI | File Storage with Lustre (check region availability) |
| Very low-latency local scratch | Local NVMe on Dense I/O shapes (data lost if instance is lost) |
#Comparison
| Block Volume | File Storage | Object Storage | Lustre |
| Protocol | iSCSI / paravirtualized | NFSv3 | HTTPS (S3-compatible API available) | Lustre client |
| Sharing | One instance (shareable volumes for clusters) | Many clients | Any client | Many clients |
| Scope | Availability domain | Availability domain | Region | Availability domain |
| Performance | Set by VPUs and size | Scales with data; mount target throughput options | High throughput, object latency | Very high throughput |
| Protection | Backups, clones, cross-region replication | Snapshots, replication | Versioning, replication, retention rules | Backups/integration per service |
Note the AD scope of block and file storage: in multi-AD regions, an instance in AD-2 can't attach a volume from AD-1.
#Common mappings
| Workload | Typical choice |
| Database on a VM (self-managed) | Block Volume (Higher/Ultra High Performance) |
| Shared web content, home directories, app shared config | File Storage |
| NFS file server replacement | File Storage (see the NFS transformation post) |
| RMAN backups, exports | Object Storage (Standard → Archive with lifecycle) |
| Data lake for analytics | Object Storage |
| AI training data with high read throughput | Lustre or Object Storage with caching |
| Container persistent volumes | Block Volume (RWO), File Storage (RWX) |
#Object Storage tiers
| Tier | Use |
| Standard | Frequently accessed |
| Infrequent Access | Accessed rarely; retrieval fee and minimum retention apply |
| Archive | Long-term; restore takes hours before reading |
| Auto-tiering (bucket setting) | Moves objects between Standard and Infrequent Access by access pattern |
#Design questions
- What protocol does the application use, and can it change?
- How many clients read and write concurrently?
- Measured IOPS, throughput and latency at peak?
- AD-level failure: is the data replicated or backed up elsewhere?
- Restore granularity (file, volume, object version) and RPO/RTO?
- Encryption keys: Oracle-managed or customer-managed in Vault?
#Traps
| Trap | Avoid by |
| File Storage for a database | Use block volumes |
| Assuming block volumes survive AD failure | Cross-region/AD replication or backups |
| Archive tier for data needed quickly in an incident | Infrequent Access or Standard |
| Small-file heavy workloads on NFS without testing | Pilot with real data; consider app changes |
| Local NVMe for data without replication | Only scratch or replicated data |
Tip
Run a short pilot with real data volumes and client counts. Storage behaviour with many small files and metadata operations rarely matches what the datasheet suggests.
#Checklist
Found this useful? Share it with your team: