When applications need seamless, concurrent access to shared files with consistent performance, network file system (NFS) is often the right fit. Oracle Cloud Infrastructure (OCI) File Storage Service extends those capabilities to the cloud for workloads such as enterprise applications, high-performance computing (HPC), and analytics. The following use cases outline where it fits best and how to choose between the Standard and High Performance tiers.
Common NFS use cases:
| Use Case / Application | Why NFS Shared File System Is Needed |
| Web or application server clusters (ex. Weblogic, Apache, NGINX, and Tomcat) | These clusters often need shared, POSIX-compliant access to configuration files, logs, and media uploads across multiple instances, such as WordPress uploads shared between nodes. |
| Enterprise applications (ex. Oracle E-Business Suite, SAP, and PeopleSoft) | Application tiers commonly require shared directories for binaries, logs, and staging files. NFS supports concurrent mounts while maintaining consistency. |
| HPC and analytics pipelines | These workloads rely on shared datasets across compute nodes for simulation, training, or post-processing. Local disks and object storage do not provide concurrent POSIX access. |
| Content management systems (CMS) and media pipelines | A shared repository supports content ingestion, editing, transcoding, and publishing workflows. Metadata-heavy workloads benefit from file system semantics. |
| Dev/test environments and shared build systems (ex. Jenkins and GitLab CI) | Build artifacts and dependencies often need to be shared across multiple build runners or test VMs. NFS simplifies concurrent read and write access. |
| Big data and machine learning workflows | Distributed training nodes often need shared access to training data and model checkpoints. NFS simplifies checkpointing and coordination. |
| Home directories and user profile storage in VDI or HPC | Each user’s home directory can be mounted dynamically across sessions, which requires POSIX file permissions and familiar directory structures. |
| Lift-and-shift migrations for legacy on-premises applications | Many legacy applications assume a shared file system. Rewriting them to use object storage APIs is often costly or impractical. |
| Shared staging or transfer areas between compute and database systems | Examples include intermediate data exchange between analytics engines and databases, such as ETL temporary files, CSV files, and backups. |
| Clustered databases or shared metadata systems (ex. Oracle RAC and IBM Spectrum Scale) | These systems need shared, consistent file access with locking and low-latency metadata operations. |
Why not just use object or block storage?
Many enterprise workloads need more than basic shared access. They depend on POSIX semantics, file locking, and predictable metadata performance. When customers choose object or block storage instead of File Storage Service (FSS), they often run into the following issues:
- Applications can crash or files can become corrupted under concurrent access
- Metadata-heavy operations can perform poorly, such as slow directory listings
- Recovery, scaling, and failover management can become more complex
| Mistaken Alternative | Typical Thought Process | What Goes Wrong |
| Object storage (S3, OCI Object Storage) | “It’s shared and cheaper, let’s use it instead of NFS.” | Object storage is not POSIX-compliant. It lacks file locking, rename semantics, and directory traversal, so applications can break or require code changes. |
| Block storage (iSCSI, NVMe, OCI Block Volume) | “We can just attach the same block volume to multiple instances.” | This approach is unsafe unless used in read-only mode. Concurrent writes can corrupt the file system, so it’s not a true shared file system. |
| Local instance storage and ephemeral storage | “Fast and simple for temporary data.” | This storage is not persistent and cannot be shared across nodes. Data is lost when the instance is terminated. |
| Database tables (ex. storing BLOBs) | “Let’s store files in DB columns instead of files.” | This option can introduce scalability, performance, and cost issues. Databases are not meant to serve as shared file systems. |
| DIY file server on a VM (using NFSd or Samba) | “We’ll just run our own NFS server.” | This design can become a single point of failure and lacks scalability and multi-AD redundancy. It also adds admin overhead and tuning complexity. |
| Cloud storage gateways (ex. S3FS, Rclone mount) | “We can mount object storage as a filesystem.” | This option can introduce poor performance, high latency, inconsistent caching, and no metadata locking. It often fails under concurrent write workloads. |
When to use the Standard vs High Performance mount target in FSS
After identifying the need for shared file storage, the next step is choosing the right performance profile. The following table can help you decide when the Standard mount target is sufficient and when the High Performance mount target is a better fit.
| Use Case | Performance Sensitivity | Typical I/O Pattern | Recommended OCI FSS Tier | Notes |
| HPC and analytics pipelines | IOPS- and throughput-intensive | Mixed small random reads/writes and large sequential datasets | High Performance | Needs low-latency metadata and parallel access to large datasets. Benefits from high MTU and multiple mount targets. |
| Big data and ML training workflows | IOPS- and throughput-intensive | Large sequential reads for datasets, with frequent small writes for checkpoints | High Performance | Parallel training jobs can put sustained pressure on storage, so throughput and metadata operations are critical. |
| Clustered databases and metadata systems (ex. Oracle RAC) | IOPS- and metadata-intensive | Many small random reads/writes and frequent file locking | High Performance | Requires file locking, metadata synchronization, and low latency for quorum and heartbeat files. |
| Dev/test shared build systems (ex. Jenkins, CI/CD) | IOPS-intensive | Thousands of small file reads/writes, short file lifetime | High Performance | Build trees, caches, and artifact directories benefit from low metadata latency. |
| Enterprise applications (ex. Oracle E-Business Suite, SAP, PeopleSoft) | Balanced IOPS and metadata | Steady small-to-medium I/O, many concurrent users | High Performance (for prod) and Standard (non-prod) | Shared file mounts between app tiers; latency spikes can slow entire batch jobs. |
| Web and application server clusters (ex. CMS, WordPress, NGINX) | Moderate IOPS and throughput | Frequent metadata ops and small to medium files | Standard (often sufficient) | Static media, logs, and configurations usually have moderate performance needs, but consistency remains essential. |
| Content management and media pipelines | Throughput-intensive | Large sequential reads/writes (ex. video, image processing) | High Performance | Video transcoding and streaming workloads benefit from parallel read throughput. |
| Home directories and user profile storage (ex. VDI, HPC) | Metadata-intensive | Many small files, high lookup frequency | High Performance | Needs low metadata latency for interactive sessions and scales better with HP tier. |
| Lift-and-shift legacy applications | Balanced | Similar to on-premises environments, typically with small files and metadata operations | Depends on workload | Use Standard for low concurrency. Use High Performance when metadata access dominates. |
| Shared staging and transfer areas (Ex. ETL, data exchange) | Throughput-intensive | Large sequential writes and reads | Standard or High Performance | Depends on frequency and file size. Staging before database load often works well on the Standard tier. |
Standard vs High Performance mount target: Quick decision guide
The Standard mount target is often enough for general-purpose workloads, shared file repositories, and staging data exchange. Use the following questions as a quick guide when deciding whether you need the High Performance mount target.
| Question | If the answer is yes → use the High Performance mount target |
| Does your application read/write thousands of files per second from many clients concurrently? | Yes |
| Is your workload media or AI/ML data intensive, and does it need enterprise shared file system capabilities like Replication, Snapshot, or Clone? | Yes |
| Is this a production enterprise system with very high throughput SLAs, such as 1 Gbps or more? | Yes |
Get started today
Shared file systems continue to be the backbone of performance, collaboration, and scalability for many cloud workloads. OCI File Storage Service delivers those capabilities in a managed service that supports everything from HPC environments to enterprise applications.
Whether you’re new to OCI or already running workloads, now’s the perfect time to evaluate File Storage Service for your shared data needs. Run a proof of concept or compare performance profiles to see whether the Standard or High Performance mount target is the best fit for your workload.