One gateway in front of the S3 storage you already run
Object storage without the object-count tax
Point your clients at Arcois instead of your storage system. Nothing in your applications changes. Five things that used to be hard stop being hard.
800 small objects arrive at the gateway
One sealed volume is what your store counts
Objects of 64 KB sealed into volumes of 100 MB give a ratio near 800 to one. Your own object sizes give your own ratio, and you can work it out before you talk to us.
Where it goes
Arcois sits between your applications and your storage. Your applications keep speaking S3. Your storage keeps holding the bytes. Only the address your clients point at changes.
Your store stops being your clients' endpoint. From here on it only stores and returns blobs, which is what makes the next five things possible.
Five things S3 users keep running into
Every one of them comes from the same place: your storage system is also your clients' endpoint, and it owns the meaning of your data as well as the bytes.
One
Millions of small objects slow your store down
An S3 store pays about the same price for every object it holds, whatever the object's size. It needs an index entry, a placement decision and a write for each one. Big objects spread that cost over a lot of bytes. Small objects pay it again every time.
So the trouble arrives on a dimension nobody bought against. Listings get slow, because listing walks keys rather than bytes. Tail latency climbs, because the index no longer fits in memory. A rebuild after a failed disk takes longer than the runbook says, because rebuilds work object by object. Capacity is still fine.
Arcois packs small objects into sealed volumes. Your store receives a few large objects instead of millions of small ones. The same bytes are stored, and the store you already own keeps serving them. The picture at the top of this page is exactly this: 800 objects in, one object for your store to count.
Reading one object does not pull the whole volume. This is the first thing people ask, so to be clear: the gateway knows the volume and the offset, and it fetches exactly that object's bytes as a single range request. Reading a 40 KB object moves 40 KB. The rest of the volume is never transferred and never read. If your client asks for a range inside the object, that becomes a narrower range inside the volume.
Your S3 clients cannot tell the difference. Same request, same ETag, same conditional headers, same range behaviour, same bytes back. Nothing is unpacked and nothing is staged.
And listing stops being your store's problem. A listing is a bounded scan over the gateway's own ordered rows, so what it costs follows the keys it returns rather than the keys you hold. Your store is never asked to enumerate anything.
That also frees your bucket names. They live in the gateway, not in a storage index, so you can have as many buckets as your application finds natural. Ask any storage vendor how long a prefixed listing takes on a bucket holding ten billion keys, while you are still writing to it. The answer usually arrives as a maximum object count, which is a different question.
What a sealed volume is
- One file, many objects
- Small objects are appended to an open volume. At 50 MB by default, the gateway seals it and uploads it.
- It describes itself
- A list of everything inside is written at the end of the file. Given the volume alone, Arcois can find and read back any object in it.
- Reads stay direct
- One byte-range request for exactly that object's bytes. A 40 KB read moves 40 KB, not the volume.
- Big objects skip it
- Packing them would gain nothing, so they go straight to your store.
- Buckets become logical
- Your bucket names live in the gateway, not in your store's index. Make as many as your application wants.
Work out your own number
You already know how many objects you hold and roughly how big they are. That is everything needed to see what your store would be counting instead.
Worked out conservatively: every object packed, and a volume sealed at a little over half full rather than waiting to fill. Objects bigger than a volume are stored directly and still count one each, so the arithmetic holds while your average is well under the volume size.
We ran this on a real customer system of twenty billion objects, against the Ceph cluster that had been sized to hold them. The full sizing is on the use-cases page.
What you gain, whatever your storage is
Four of these five have nothing to do with which product holds your bytes. The fifth changes size, never direction.
Four of the five do not depend on your storage at all
A mirrored copy on two different vendors, a DR site at a vendor that is not the one holding your data, a move between vendors with no outage, and tape. None of these get better or worse according to what your store is, because they are not about your store. They are about no longer being tied to one.
A vendor will happily replicate to itself. What none of them will do is present two different vendors as one namespace, under one set of credentials, and read from whichever one is healthy.
Aggregation's size depends on your product. Its direction does not.
Every S3 implementation spends an index entry and a placement decision on every object it holds. Every one of them lists a bucket by walking keys rather than bytes. Every one of them has a point past which a single bucket stops being comfortable, and a point past which the whole system does.
What changes from product to product is where those walls sit. What does not change is that holding far fewer objects means you meet them later, or never.
The optimisation is software, not an appliance
Some arrays have engineered around small objects internally, and they have done it well. The catch is where the cleverness lives: inside a product you have to keep buying. When it lives in a gateway instead, it works on the hardware you already own, on whatever you buy next, and on two different vendors at the same time.
You are not choosing between their engineering and ours. You are choosing whether the benefit travels with you.
Cold data belongs somewhere cheaper
Your array is the most expensive place you own. A lifecycle rule moves what nobody reads onto commodity capacity — a different make, a different vendor — and the application never notices.
No vendor will tier you off its own hardware. That is not a technical limit.
The next petabyte can come from anyone
You do not have to move to benefit from being able to. Having the option is what changes the price of the array you keep.
And a copy on a second make survives what same-vendor replication cannot: a bad firmware release, a mistake in the management plane, ransomware that reaches it.
On premium hardware it is worth more, not less
If you bought a fast, expensive array, then the per-object overhead you are paying is being paid on expensive hardware. Cutting the object count by two or three orders of magnitude pushes back the next expansion, and on that kind of kit the expansion you push back is the costly one.
The cheapest capacity is the capacity you did not have to buy this year.
Two
Changing vendor means an outage, so you never change vendor
Your clients are pointed at your storage system, so moving to another one means changing the address they use. The move is not finished until the last byte has landed. Teams book a maintenance window for it, and that window grows with every terabyte they hold.
So the move gets put off at every renewal. And your vendor knows it. A negotiation is only as strong as your alternative, and an alternative that means downtime is not much of one.
With Arcois, your clients are pointed at the gateway. That address never changes. Moving a bucket to another vendor is a copy in the background and a pointer update at the end. Clients read and write the whole time.
And the old copy is left where it is. If you change your mind half-way, you stop, and nothing has been lost.
This does not depend on aggregation. An object written straight through is one object on your store, and moving it is the same copy and the same pointer update. If packing is not for you, you can still register two vendors and move between them without an outage. The two are independent.
Before, and during
After
The move runs in phases and stops for your approval at the steps that matter. Vendor A's bytes are never deleted by the operation, so you can cancel at any point and stay exactly where you were.
Three
You can only use one vendor at a time
Two S3 stores are two endpoints, two sets of credentials and two namespaces. Splitting a workload across them is something your applications have to know about, so in practice nobody does it. Buying a different make of array means running it as a separate island.
Arcois makes several stores into one namespace. You describe where a bucket's data should live, and the gateway does the rest. Put copies in two places and every write goes to both. Spread a bucket across several targets in one place and it shares the load between them.
So you get a mirrored copy across two different vendors — redundancy that no single vendor can sell you, because it does not depend on any one of them staying up or staying honest at renewal. And when you add hardware, you add a target rather than an island.
Your stores never have to match. Each one only ever holds bytes.
Copy one, shared across two targets
Copy two, the mirror
Every write reaches both groups. Inside a group, the load is shared. Retiring a target is a drain: it stops taking new writes, carries on serving reads, and is only removed once nothing points at it any more.
Four
Your disaster-recovery copy is at the same vendor as your data
Cross-region replication normally means another region of the same product. It protects you from a fire. It does not protect you from a bad firmware release, a mistake in the management plane, or ransomware that reaches that plane — because both copies are running the same software, under the same credentials, in the same hands. Nor from a price rise, an account problem, or a supplier failing.
With Arcois, your second site can be someone else entirely. Two independent Arcois clusters, each with its own storage behind it, and nothing says the two have to be the same product or the same company. One serves your clients. The other keeps up with it.
Every change is queued for the second site in the same transaction that makes the change, so a change that has been committed is never left unqueued. Switching over is your decision, and a planned switch is designed to lose nothing.
Site one, serving clients
Site two, a different vendor
Two vendors, two buildings, two independent clusters. A third location can hold a small witness that settles which site is in charge, so a network split cannot leave both of them believing they are.
Five — in development
Tape is the cheapest storage there is, and you cannot use it
This one is still being built. The argument is worth making now, because the hard half is already done and shipping.
Nothing beats tape for data you have to keep and rarely read. It is cheap, it uses no power on the shelf, and it is offline, which is the only backup a piece of malware cannot reach. Every retention rule that says "seven years" is really asking for tape.
But tape wants to be fed. A drive streams at full speed only while data keeps arriving. Give it small files and it runs dry between them, stops, backs up, repositions and starts again. That is shoe-shining, and it can drop a drive to a small fraction of its rated speed while wearing out both the tape and the head.
This is why bolting a tape product onto an S3 store rarely works. The tape part is the easy half. The small files are what defeat it. The usual answer is to buy a second product that sits between the store and the library and packs the small objects into large containers before they reach the drive. That product exists because the problem is real, and what it does is aggregation.
Arcois has already solved the hard half. A sealed volume is a long, continuous run of bytes, which is exactly what a tape drive wants. Aggregation was built for the object-count problem, and it happens to be the thing that makes tape work.
The scheduling is in place too. Lifecycle rules already move data from one kind of storage to another on a timetable you set, so ageing data down to cheap disk works today. What is being built is the last hop, onto offline media.
Small files, written to tape one at a time
Stop, back up, reposition, start again
Sealed volumes, written to the same tape
One continuous pass, at the drive's own speed
Tape support is being built now. The part that makes it work — packing small objects into long sequential runs — is already in the product and already doing its other job.
Nothing here runs on one server
Arcois runs on Kubernetes or OpenShift as three workloads: the gateway tier, the metadata store, and the store's placement driver. There is no node whose loss stops the service, and no single machine holding anything the others need.
The gateway tier is active-active. Every pod is equal, every pod serves every kind of request, and one address sits in front of all of them. Add pods to add capacity and remove them to give it back, while traffic keeps flowing.
Background work is held by lease, not by a leader. One instance of each periodic job runs at a time, on whichever pod holds its lease. A pod that dies releases its leases and another picks the work up. There is no leader to lose and no election to wait out.
The metadata store is Raft-replicated across three or more nodes, with leaders elected per range of the key space and spread across those nodes. Lose a node and you lose no data and no capability. Add nodes and the ranges redistribute onto them.
Every tier ships with health probes and a disruption budget, so a rolling upgrade or a node drain cannot take out more replicas at once than you allow.
Gateway tier — every pod serves every request
Metadata store — Raft-replicated, leaders spread across nodes
Placement driver — three replicas, routes and elects
Both tiers scale while serving traffic, by changing a replica count. On the sizing in the calculator above, twenty billion objects needed eight gateway pods and five metadata pods.
And if you sell storage, this is the platform
A regional or sovereign provider has racks, network and a store. What it needs on top is the part nobody ships with the hardware: isolation between customers, per-customer logins and access rules, quotas that actually stop a write, and a usage record it can invoice against.
Each of your customers becomes a realm, with its own buckets, users, keys and policies, which that customer administers itself using the ordinary AWS command-line tools. You set the quota. Arcois refuses writes past it and never refuses a delete, so a customer over quota can always get back under. Every day, Arcois writes down what each customer stored.
One identity model and one metering record cover every customer, on every store you have registered.
What your customers get
- Their own namespace
- No customer can read or fill up another's. The boundary is in the gateway, so your store does not have to enforce anything.
- Their own console and CLI
- They create users, keys and policies themselves. You are not a ticket queue.
- Rules that hold
- Anything no policy allows is refused. An explicit "no" wins over every "yes", including bucket ownership.
- A bill you can defend
- A daily record per customer of bytes stored and objects held.
Who this is for
Platform teams
Billions of small objects on a store that was sized in terabytes, and a listing that has started to time out.
Regional and sovereign providers
Racks and a store already in place, and customers who need S3 in their own country under their own law.
Anyone planning an exit
A vendor change that is scheduled and reversible, instead of deferred again at the next renewal.
Bring your object count. We will do the arithmetic with you.
You already know how many objects you hold and how big they are. That is everything we need to work out what your store would hold after aggregation, before anyone signs anything.