As AI teams increasingly build on distributed, cloud-native infrastructure, they often run into limitations around how files and data are accessed across systems.
POSIX — the Portable Operating System Interface — is the standard API used by UNIX and conforming non-UNIX (including Windows) operating systems to maintain compatibility with each other. It allows applications written for one OS to work on others with little to no rework, greatly simplifying the development of cross-platform software.
POSIX is widely adopted, well understood by developers, and backed by established compliance tests. But it’s no longer universal—especially when it comes to file access in the cloud. Object storage systems like Amazon S3 use REST APIs, which operate outside the POSIX model. As cloud-native workloads grow, the question arises: is POSIX still relevant, or is it a legacy system?
POSIX has been around for a while. Why hasn’t something replaced it?
Whether POSIX is outdated — or simply too slow to evolve — is a long-running debate:
“Over the years, we’ve done lots of nice ‘extended functionality’ stuff. Nobody ever uses them. The only thing that gets used is the standard stuff that everybody else does too.” — Linus Torvald, creator of the Linux kernel
POSIX hasn’t been replaced or meaningfully updated for a simple reason: developers value compatibility and long-term support. Any serious alternative would need to offer clear advantages and gather enormous momentum to challenge its dominance.
Still, while POSIX remains in place, it's being left behind in some key new areas — particularly for accessing files stored in low-cost cloud object storage.
Standards exist for a reason.
Cloud storage vendors often claim full S3 compatibility, but developers quickly discover that software working with Amazon S3 may fail entirely on other “compatible” platforms — or break after a provider update. This typically happens due to subtle differences in underlying technologies or missing APIs, especially when providers are just chasing AWS’s changes without shared standardization.
At Storj, we’ve worked with developers across high-performance and data-intensive environments. We’ve encountered issues with supposedly 100% S3-compatible systems, including:
- Commas and special characters breaking when using the AWS C++ SDK on Google Cloud Storage
- Transfers failing under load with a major cloud vendor
- Object keys not returned in lexicographical order (contrary to the S3 spec)
- Deleted directories lingering as phantom keys in a widely used on-prem system
- Errors when requester-pays headers aren’t configured
- Performance hits caused by fallback to slower APIs due to missing or buggy implementations
Adding basic support for object storage is easy — APIs are documented and SDKs are available. But in the real world, getting reliable, high-performance behavior across providers is the hard part.
This reinforces the need for a true standard — one that’s widely adoptable, performance-capable, and built for modern workloads.
Every cloud provider has its own incomplete S3 API implementation.
Companies are investing billions in object storage platforms that try to keep up with AWS — while still depending on it to define the API they must mimic. Amazon has little incentive to collaborate with competitors on a shared standard.
Meanwhile, vendors like Azure and Google, and projects like OpenStack, have started publishing their own APIs. This fragmentation creates developer headaches, increases vendor lock-in, and undermines the long-term value of cloud applications, which often require rework just to remain compatible — even within the same platform when APIs change.
Developers need to be able to write once and run anywhere, with decent performance. That’s why a single standardized layer of abstraction makes sense.
Extending POSIX to address the biggest object storage challenges.
Discarding a proven standard rather than extending it to new use cases could be reckless. Just because REST APIs exist for object storage doesn’t mean they’re better than file access APIs — they simply emerged to fill a gap, and they bring their own share of issues.
POSIX is a well-understood standard. Developers rely on it because it offers a familiar, lower-friction development experience. There’s already a deep ecosystem of software built around POSIX file behavior — software that runs reliably across environments and integrates easily into toolchains. Developers often turn to object storage APIs only because they’re forced to — not because they prefer them.
Extending POSIX to work in the cloud lets developers stick with familiar patterns, tools, and expectations — and avoid the complexity of rewriting their workflows for object storage quirks. Projects like s3fs and goofys are already trying to bridge the gap, but performance, reliability, and cross-provider inconsistencies remain.
The future of POSIX and storage APIs
We believe there’s still plenty of room to extend POSIX for cloud-native workloads. As POSIX-style access becomes more widely available across object storage platforms, developers are likely to shift back toward writing applications that rely on portable, cross-platform environments.
One signal of POSIX’s ongoing relevance is the adoption of WASI (WebAssembly System Interface) — which brings POSIX-style behavior into even the most modern, sandboxed execution environments.
These advancements hold a lot of promise, but they must be handled carefully. The long-term value of POSIX lies in its stability and predictability — qualities that developers rely on.
Want to try it? Object Mount for Linux gives AI and infrastructure teams fast, consistent access to S3-compatible storage with full POSIX semantics.
→ Explore the docs
→ Contact us
