Capacity you can actually read back
Cheap storage you cannot read quickly is not storage, it is a landfill with a monthly invoice. Every node in this line pairs bulk capacity with an NVMe tier and a port fat enough to drain the whole thing before you lose interest.
Cheap storage that you cannot read quickly is not storage, it is a landfill. Every node in this line pairs bulk capacity with an NVMe tier and a port fat enough to drain it.
| Plan | Dedicated cores | Memory | NVMe storage | Bulk storage | Port speed | Price | |
|---|---|---|---|---|---|---|---|
| S-20 20 TB | 8 | 32 GB | 500 GB | 20 TB | 10 Gbit/s | €119.00 /mo | Configure |
| S-50Most taken 50 TB | 12 | 64 GB | 1 TB | 50 TB | 10 Gbit/s | €249.00 /mo | Configure |
| S-100 100 TB | 16 | 128 GB | 2 TB | 100 TB | 25 Gbit/s | €449.00 /mo | Configure |
Prices exclude VAT where applicable. Traffic: Unmetered, fair use.
EPYC 9354P host · NVMe write cache · enterprise SATA bulk tier
Thirty-four cities, twenty-nine countries
Latency figures are measured medians from our own probes, not vendor brochures. They move; the page updates when they do.
Two tiers, one machine
The design assumption is that a small part of your data is busy and the rest is not. That is true of nearly every archive, media library and backup target we have ever seen, and it is what makes this line affordable.
Gen4 NVMe in front, enterprise SATA behind, both local to the host.
Each node carries five hundred gigabytes to two terabytes of Gen4 NVMe alongside twenty to a hundred terabytes of enterprise bulk capacity. The NVMe is not a cache we manage for you. It is a separate block device, yours to use as a write buffer, a metadata volume, a database, a scratch area for whatever is being processed this week, or all four.
Underneath, the bulk tier is enterprise SATA in a redundant array with parity and a hot spare. Sequential throughput is good, random throughput is what spinning media does, and the split between the two tiers is yours to arrange. We do not put a clever tiering layer in the way and then explain your latency spikes with a diagram.
The hot set on NVMe
Indexes, databases, in-flight uploads, transcoding scratch, torrent piece assembly. Anything that touches the same blocks repeatedly belongs here rather than on the bulk array.
The cold set on bulk
Finished media, backups, archives, logs nobody reads until an auditor asks. Written once, read occasionally, and priced accordingly.
Real cores in front of it
Eight to sixteen dedicated EPYC cores with ECC memory. Storage nodes end up doing hashing, compression, encryption and transcoding, and none of that is free.
A port that can drain it
Ten gigabits on the smaller tiers, twenty-five on the largest. A hundred terabytes at twenty-five gigabits is a long weekend rather than a change of career.
Who should not buy this
This line does one job well and several adjacent jobs badly. The badly ones are worth listing before you commit to a year.
Bulk storage is bought optimistically more often than any other product except GPUs.
You need random IOPS across the whole dataset
A database with a hundred terabytes of hot working set does not belong on spinning media, and no amount of NVMe in front rescues it. That is an EPYC instance with a lot of NVMe, and it costs what it costs.
You want object storage with an API
This is a server with disks in it. There is no bucket, no signed URL, no lifecycle policy. Install what you like on top; nothing is provided.
You want it to be a backup
One array in one building is not a backup, however much parity it carries. If the data matters, replicate to a node in a different city, which is cheap here precisely because bandwidth is not metered.
You are storing something illegal in the site you chose
The jurisdiction is yours to pick and yours to live with. We do not read what passes through, but we do answer what the law of that site requires, and the acceptable use policy is short and specific about the few absolutes.
You need it in Dubai, Sydney or Zurich
Sixteen of the thirty-four sites carry no bulk capacity at all, generally because the rack space costs too much for it to make sense. The configurator shows you the eighteen that do.
How the array is built
Nothing here is novel. It is the layout that has been correct for fifteen years, built with parts that were bought new.
Parity, a hot spare, and no thin provisioning anywhere.
Capacity is thick-provisioned like everything else we sell. Fifty terabytes bought is fifty terabytes reserved, not fifty terabytes hoped for. Storage is the product where overselling causes the most damage and where it is most common, so we would rather run out of stock than run out of blocks.
Rebuild times on a large parity array are measured in hours, occasionally in more than a day for a full hundred-terabyte node. Throughput during a rebuild is lower than normal. That is physics rather than policy, and anybody quoting you a figure without that caveat has not run one.
| Layer | What it is | What happens when it breaks |
|---|---|---|
| Hot tier | Gen4 NVMe, mirrored, power-loss protected | Mirror carries on, spare rebuilds, no interruption |
| Bulk tier | Enterprise SATA, parity array with a hot spare | Array degrades, rebuild starts automatically, reads continue |
| Write cache | Capacitor-backed, flushed on power loss | Journal replays cleanly rather than losing acknowledged writes |
| Host | EPYC 9354P, ECC DDR5, two bonded uplinks | Instance rebuilt on standby hardware in the same site |
| Off-node copy | Optional nightly backup to a different city | Independent of everything above it, which is the point |
Getting data in and out
A storage product with metered egress is a trap with a monthly instalment plan. Traffic here is unmetered under a fair-use figure we publish per port speed rather than hint at.
Unmetered under published fair use. Fifty terabytes a month on a ten-gigabit port.
The first upload
Ten gigabits sustained moves roughly a hundred terabytes a day if the far end can keep up. In practice the far end is the bottleneck almost every time, and it is worth testing before you plan around a date.
Node-to-node copies are free
Replication between two of our sites crosses our own backbone. Running a second node in another country is the cheapest disaster plan available to you.
Seeded transfers
For genuinely large first loads, ask support before inventing a plan involving physical media. Usually there is a better network path we can arrange for a week.
Filtering stays on
Edge scrubbing is permanently in path, up to twelve terabits per second at the largest sites. Public-facing storage attracts attention, and this is included rather than sold back to you during an incident.
If you cross fair use
You get an email proposing a dedicated port arrangement. What you do not get is a surprise invoice, a throttle applied quietly, or a suspension over the weekend.
A forty-gigabit dedicated port is available on this line at sites with the upstream capacity behind it. It is a paid option and most people do not need it.
Where the capacity is
Storage nodes live where floor space and power are affordable, which is not always where the fashionable sites are. Bucharest is the cheapest terabyte we sell, by a margin large enough that people move there for it alone.
Eighteen sites, sixteen countries. Bulk follows cheap rack space and cheap transit.
Europe carries eleven of the eighteen: both Amsterdam floors, Frankfurt, Helsinki, Stockholm, Reykjavík, Bucharest, Sofia, Chișinău, Riga and Warsaw. North America has New York, Miami and Toronto. Panama City and São Paulo cover Latin America, while Singapore and Mumbai cover Asia. Nothing in the Middle East or Africa carries bulk capacity yet.
Warsaw fills fastest. Nodes racked there are usually sold within days, which is flattering and inconvenient in equal measure. Helsinki and Reykjavík have the lowest power cost in the fleet, so they tend to be where we add capacity first when the demand is not tied to a particular jurisdiction.
| If your priority is | Consider | Why |
|---|---|---|
| Price per terabyte | Bucharest | Cheap transit and unfashionable rack space |
| A quiet jurisdiction | Chișinău or Panama City | Two places that read a complaint very literally |
| Low power cost and cold air | Helsinki or Reykjavík | Where we add capacity first when nothing else decides it |
| North American users | New York or Miami | Miami also carries most of our Latin American traffic |
| A second copy far away | Any site plus one other | Node-to-node replication crosses our own backbone |
Moving in
Storage migrations fail for boring reasons: the source is slower than anyone measured, the directory tree has four million small files in it, or nobody checked the hashes.
Test with a terabyte before you commit a hundred.
- 01
Measure the source, not the destination
Our port speed is easy to verify and rarely the problem. Copy a hundred gigabytes from wherever the data lives now, time it, and multiply. The result is usually sobering.
- 02
Move the bulk first, the delta later
One long transfer while the old system is still serving, then a second short pass once writes have stopped. Anyone who tries to do it in one pass with the service live does it twice.
- 03
Small files are a different problem
Millions of tiny files are limited by metadata operations rather than by bandwidth. Pack them into archives for transit and unpack at the far end; it is often an order of magnitude faster.
- 04
Verify with hashes, not with file counts
Checksum both ends. A file count matching is not evidence of anything, and a truncated file looks perfectly present in a directory listing.
- 05
Decide what lives on NVMe
Put the index, the database and the write path on the hot tier deliberately rather than by accident. This one decision accounts for most of the performance difference between two customers on identical nodes.
“I moved eleven instances across in a weekend and the only thing I had to ask support was whether the /48 was routed or proxied. It was routed.”
When a drive fails
Buy enough spinning media and some of it will fail this year. The array is built on that assumption, and so is our replacement process.
On a hundred-terabyte array, drives failing is a schedule rather than an event.
A failed bulk drive drops the array into a degraded state, the hot spare is pulled in automatically, and the rebuild begins without anybody being woken up. Your data stays readable throughout, at reduced throughput. A technician replaces the dead unit at the next visit and the new drive becomes the spare.
Losing the host rather than a drive means a rebuild onto standby hardware in the same site, with addresses following. Being straightforward about the timing matters here: moving a large array is slower than moving a small NVMe instance, and the honest range is under an hour for the smaller tiers and longer for a full node.
Degraded means slower, not stopped
Reads and writes continue during a rebuild. Throughput drops while parity is recomputed, and it recovers when the rebuild finishes.
Two failures is why the spare exists
Parity plus a hot spare covers the realistic case. Nothing covers every case, which is the argument for a second copy in another city.
You will be told
Notification goes out on detection. The incident record on the status page is updated while it is happening and stays published afterwards.
The SLA still applies
99.99% contractual monthly uptime, with credits applied automatically. Degraded performance during a rebuild is not an outage, and we do not pretend otherwise in either direction.
Questions about this line
Enterprise SATA, yes. That is what makes a hundred terabytes affordable. The NVMe tier in front is genuinely NVMe, and the split between them is yours to arrange rather than ours to manage invisibly.
People do, in large numbers, and the ten-gigabit unmetered port is the reason. What you may not do is anything the acceptable use policy prohibits or anything unlawful in the site you picked. We do not inspect traffic, and we do answer lawful requests where they apply.
Fifty terabytes a month on a ten-gigabit port, a hundred and fifty on twenty-five gigabits, two hundred and fifty on forty. Published on the pricing page, and enforced by an email rather than by an invoice.
Move up a tier while the node has room, which is usually the case for a step from twenty to fifty terabytes. Jumping to a full hundred-terabyte node generally means a new node and a copy across our own backbone, scheduled with you.
No. What you write is what is stored, byte for byte. Any deduplication or compression you want is yours to configure, where you can see its cost.
Only if you encrypt it. We do not hold keys for customer volumes, because a key we hold is a key that can be demanded from us. Full-disk encryption inside the instance, opened at boot over the out-of-band console, is the arrangement we would use ourselves.
Start with twenty terabytes
Take the smallest node in the site you want, move a terabyte, and measure it honestly. Moving up a tier is a scheduled job rather than a rebuild, and the first seven days come back in coin if the numbers disappoint you.