SwiftStack

Distributed object storage, honestly reviewed. This one has a twist: the commercial product no longer exists.

TL;DR

• What it was: SwiftStack was a commercial management layer built on top of OpenStack Swift — an open-source distributed object storage system. Think “S3-compatible storage you run on your own hardware, with a control plane.” [1]
• Current status: NVIDIA acquired SwiftStack, Inc. The SwiftStack data platform is no longer available for sale. Existing customers get support portals; new customers get nothing. [1]
• The underlying project: OpenStack Swift (Apache 2.0 license) is alive and maintained at opendev.org. The GitHub repository with 2,757 stars is a mirror. [2]
• Who OpenStack Swift is still for: Infrastructure engineers building distributed object storage at scale — backups, media, ML datasets. Not a point-and-click product.
• Cost: OpenStack Swift is free. SwiftStack’s commercial layer is gone and was never publicly priced for self-service purchase.
• Key fact: If you came here looking to deploy SwiftStack today, you can’t. If you came here looking for self-hosted S3-compatible object storage, read the alternatives section.

---

What is SwiftStack

SwiftStack was a company that built a commercial data management platform on top of OpenStack Swift. OpenStack Swift itself is a distributed object storage system originally developed by Rackspace as the backbone for its Cloud Files product, then open-sourced in 2010 as part of the OpenStack project [2].

What Swift does at the technical level: stores arbitrary unstructured data (objects) across multiple nodes with automatic replication, eventual consistency, and a REST API. You hit it with HTTP requests — PUT an object, GET it back, DELETE it. It’s designed to scale from a single machine to thousands of servers without architectural changes, making it the foundation for systems managing petabytes or exabytes of data [2].

What SwiftStack added on top: a controller plane that made operating and managing Swift clusters manageable without deep OpenStack expertise. Multi-site data placement policies, a web-based management interface, capacity reporting, and a unified console for managing nodes and clusters across private data centers and public clouds [1]. The pitch was “you get OpenStack Swift’s scale and economics, without needing a full OpenStack operations team.”

NVIDIA’s acquisition interest is easy to read: the website explicitly notes the platform is “ideal for managing very large AI and deep learning data sets” with capacity scaling to “exabytes within private data centers, edge locations, or public clouds” [1]. NVIDIA bought the company to get the enterprise storage management capability for its AI infrastructure stack. SwiftStack customers aren’t being migrated to a new product — they’re being supported during transition, not onboarded to a successor.

---

Why People Choose It

This section has an unusual problem: no relevant third-party reviews exist in the available research for this article. The provided sources [1]–[5] do not contain SwiftStack reviews. What follows is derived from primary sources — the OpenStack Swift documentation and the SwiftStack website.

The case for OpenStack Swift as the underlying engine is straightforward compared to alternatives:

Versus AWS S3: If you’re paying for S3 at scale, the unit economics eventually invert. S3 charges per GB stored plus per-request fees plus data egress. At petabyte scale, running your own Swift cluster on owned hardware can reduce storage costs by an order of magnitude. This is the same math that drove Dropbox to build its own storage backend rather than stay on S3 permanently.

Versus Ceph (RADOS Gateway): Ceph is the more common enterprise self-hosted object storage recommendation today. Ceph does more (block, object, and file storage in one system), but that breadth comes with operational complexity. Swift is narrower — object storage only — which makes it simpler to reason about and operate. For teams that only need object storage and don’t want to operate the full Ceph stack, Swift’s focused scope is a genuine advantage.

Versus MinIO: MinIO is S3-compatible, simpler to deploy, and has become the default recommendation for new self-hosted object storage deployments. Swift predates MinIO by several years and has more production mileage at extreme scale, but MinIO has largely won the mindshare battle for new deployments, particularly those under 1 PB.

The honest reason people historically chose SwiftStack (the commercial product) over raw OpenStack Swift: they needed Swift’s scale but didn’t want to hire OpenStack specialists. That value proposition died with the acquisition [1].

---

Features

Based on the OpenStack Swift README and documentation:

Core object storage:

• REST-based API for PUT, GET, DELETE, HEAD operations [2]
• Horizontal scaling from a single node to thousands of servers [2]
• Multi-tenancy support built into the architecture [2]
• Optimized for high concurrency read/write workloads [2]
• Designed for unstructured data — backups, web content, media, ML datasets [2]

Durability model:

• Data is replicated across multiple nodes automatically [2]
• Background consistency processes detect and repair missing replicas [2]
• “Probe tests” verify internal consistency of running clusters [2]

Architecture components:

• Proxy server (entry point for all client requests) [2]
• Account server, container server, object server (the storage layer) [2]
• Ring — the data structure that determines which nodes store which data [2]
• Middleware system for auth, rate limiting, and access control [2]

Developer API:

• Full REST API documented at docs.openstack.org/swift [2]
• Python client libraries
• S3 compatibility via middleware (not native — requires additional configuration)

Deployment:

• pip installable
• SAIO (Swift All In One) development environment documented
• Supports large-scale multi-node production deployments

What SwiftStack added (now discontinued):

• Web-based management controller [1]
• Multi-site data placement policies [1]
• Centralized node and cluster management [1]
• Controller-as-a-Service (cloud-hosted management plane) [1]

---

Pricing: SaaS vs Self-Hosted Math

This section is unusually simple for a discontinued product:

SwiftStack commercial product: No longer available for purchase [1]. Historical pricing was enterprise sales-only — no public pricing was ever listed. Current customers have support portal access for transition; no new accounts are being created.

OpenStack Swift: Apache 2.0 licensed, free to use, fork, modify, and redistribute. The software itself costs nothing [2].

Actual costs for self-hosting OpenStack Swift:

• Hardware or VPS: The dominant cost. Swift requires at least 3 nodes for production replication (5+ recommended). A minimal production cluster on bare metal starts at several hundred dollars per month on cloud VMs, or capital expenditure on owned hardware.
• Operational overhead: Significant. Operating a Swift cluster requires understanding the ring, replication factors, capacity planning, and failure recovery. This is not a solo-weekend setup.
• XFS filesystem strongly recommended (required for full test suite support) [2]

Honest math for typical founders: If you’re a non-technical founder looking to replace Dropbox Business or a simple cloud storage bill, SwiftStack/Swift is not the right tool. It’s infrastructure for teams with storage engineers. The alternatives section has more realistic options.

---

Deployment Reality Check

The OpenStack Swift README is honest about what this involves: the recommended getting-started path for developers is “SAIO — Swift All In One,” a VM-based development environment [2]. That’s the development path. Production is a different story.

What you actually need for production Swift:

• Multiple Linux servers (physical or virtual) — minimum 3, ideally 5+
• XFS filesystems on storage nodes [2]
• Understanding of Swift’s ring concept (how data gets distributed and replicated)
• Ability to manage ring rebalancing as capacity changes
• Monitoring for replica counts, async operations, and replication lag
• Capacity planning: Swift doesn’t autoscale; you plan and add nodes deliberately

Three test suites in the repository tell you something about complexity [2]:

1. Unit tests — standard
2. Functional tests — black-box API tests against running clusters
3. Probe tests — white-box tests that validate internal cluster behavior (creating objects, deleting replicas, verifying background processes fix them)

That third category exists because Swift’s behavior under partial failure is complex enough to require a dedicated test category. That’s a signal about operational depth.

What can go sideways:

• Ring misconfiguration during capacity changes can cause data to temporarily become unavailable
• XFS requirement means storage infrastructure isn’t plug-and-play with default Linux configurations
• No built-in web UI in the open-source version — the management controller was the SwiftStack commercial product, which is gone [1]
• S3 compatibility requires additional configuration and isn’t seamless out of the box

Realistic time to production for a competent infrastructure engineer: Days to weeks for a properly configured cluster. Not an afternoon.

---

Pros and Cons

Pros

• Proven at extreme scale. OpenStack Swift has been running Rackspace Cloud Files since 2010. It handles exabyte-scale workloads in production [2]. There are very few open-source distributed storage systems with that track record.
• Apache 2.0 license. Clean open-source license, no commercial restrictions, no “fair-code” limitations [2].
• REST API from day one. The API surface is stable and well-documented at docs.openstack.org [2].
• Multi-tenancy native. Built for service providers and multi-tenant environments from the start, unlike some competitors that bolted it on later [2].
• Strong consistency guarantees via background processes. The probe test suite validates that the cluster self-heals — data integrity isn’t just claimed, it’s tested [2].
• Active OpenStack project. The underlying Swift project continues to receive contributions even if SwiftStack the company is gone.

Cons

• The commercial product is dead. If you want the management layer that made Swift accessible to non-experts, it no longer exists [1]. You’re back to raw OpenStack operations.
• Steep operational curve. Understanding the ring, capacity planning, and failure recovery requires real expertise. This is not MinIO or Ceph with tutorials for every edge case.
• No modern web UI in the open-source version. You’re managing it via CLI and config files.
• S3 compatibility is not native. S3-compatible access requires the Swift3 or S3API middleware, which adds configuration and doesn’t cover the full S3 API surface. If S3 compatibility is your primary requirement, MinIO is a cleaner choice.
• Aging documentation for new deployers. Most of the accessible tutorials target OpenStack cloud environments. Standalone Swift deployment guides are less polished than MinIO or Ceph documentation.
• Community momentum has shifted. MinIO and Ceph have captured most of the mindshare for new self-hosted object storage deployments. Swift is maintained but no longer where the energy is.

---

Who Should Use This / Who Shouldn’t

Consider OpenStack Swift if:

• You’re operating an existing OpenStack-based infrastructure and need the native storage layer.
• You’re a cloud service provider or large enterprise that needs multi-tenant object storage at petabyte scale with a long track record.
• You have infrastructure engineers who know the OpenStack ecosystem.
• You’re an existing SwiftStack customer navigating transition — your cluster keeps running, you just won’t get new features.

Don’t use this if:

• You’re a non-technical founder who wants self-hosted file storage. There are much better options.
• You want S3-compatible storage and measured it in terabytes, not petabytes. MinIO covers this cleanly.
• You want an active community, modern documentation, and a growing ecosystem. That’s MinIO or Ceph today.
• You were planning to buy the SwiftStack commercial product. It’s not available [1].
• You want a hosted/managed option. No equivalent to the old SwiftStack SaaS exists for Swift specifically.

---

Alternatives Worth Considering

Given SwiftStack is discontinued as a commercial product, these are the realistic alternatives:

• MinIO — Apache 2.0, S3-native (not S3-compatible via middleware — it speaks S3 natively), dramatically simpler to deploy, excellent documentation, active community. The default recommendation for new self-hosted object storage deployments under petabyte scale. For most founders and small teams, this is the right choice.
• Ceph (RADOS Gateway) — does block, file, and object storage in one system. More powerful than Swift in scope, operationally heavier. Common in Kubernetes-native environments. Rook makes Ceph deployment significantly easier on Kubernetes.
• Garage — small, lightweight distributed object storage designed for self-hosting, S3-compatible. Newer project, much simpler than Swift or Ceph, suitable for small clusters.
• Zenko (by Scality) — enterprise-grade multi-cloud object storage management, closer in positioning to what SwiftStack was. Commercial product.
• Cloudian HyperStore — enterprise S3-compatible object storage. Commercial.
• Pure Storage Portworx — enterprise Kubernetes storage. Commercial, unrelated pricing tier.
• Wasabi / Backblaze B2 — if self-hosting isn’t a hard requirement and you just want cheap S3-compatible cloud storage, these are dramatically cheaper than AWS S3 without the operational overhead of self-hosting.

For the audience most likely reading this (founders and small teams trying to reduce SaaS bills): MinIO is what you want. It deploys in minutes via Docker, speaks native S3, has a web console, and the documentation assumes you’re not an OpenStack expert.

---

Bottom Line

SwiftStack the commercial product is gone. NVIDIA bought the company, the data platform is no longer for sale, and new customers have nowhere to go [1]. What remains is OpenStack Swift — a battle-hardened distributed object storage system with a clean open-source license and a long track record at extreme scale, but a steep operational curve and no management UI [2].

If you came here because you saw SwiftStack mentioned somewhere as a self-hosted storage option: it was real, it was good for what it did, and now it’s over. For new deployments, evaluate MinIO first. If you’re already running Swift clusters, the software itself isn’t going anywhere, but you’ve lost the management layer that made large-scale operations manageable without deep OpenStack expertise. That gap is real, and there’s no direct replacement.

If the infrastructure complexity is the blocker, that’s exactly the kind of setup upready.dev evaluates and deploys for clients — getting you from “I need self-hosted storage” to a running system without the weeks of documentation archaeology.

---

Sources

1. NVIDIA — “NVIDIA has acquired Swiftstack, Inc.” (SwiftStack acquisition landing page). https://www.nvidia.com/en-us/data-center/swiftstack/
2. OpenStack Swift — GitHub mirror / README (Apache 2.0, mirror of opendev.org). https://github.com/openstack/swift

Primary sources consulted:

• OpenStack Swift documentation: https://docs.openstack.org/swift/latest/
• OpenStack Swift deployment guide: https://docs.openstack.org/swift/latest/deployment_guide.html

Note: No relevant third-party reviews of SwiftStack were available in research for this article. The five sourced articles provided contained unrelated content. All claims above are derived from primary sources (official website, GitHub README, documentation).