case-study

Dropbox's Move Off S3

also called Magic Pocket

Dropbox moved the majority of its file storage off Amazon S3 onto custom infrastructure, reporting savings that its S-1 filing put at roughly $75 million over two years.

case-studydropboxbuild-vs-buystoragecost

The decision

Dropbox was one of the largest S3 customers in the world. In 2016 it completed a migration of over 90% of its stored data onto Magic Pocket, its own exabyte-scale storage system running on custom-specified hardware in leased data centres. Its 2018 S-1 filing reported roughly $74.6 million in cumulative savings over the preceding two years.

This is the highest-profile example of a cloud repatriation that was clearly correct — and the conditions that made it correct are the reason it is a case study rather than a template.

Why it worked for Dropbox specifically

The workload was single-purpose and enormous. Storing and retrieving immutable blocks, at a scale where a percentage point of efficiency is worth millions. Custom hardware and a purpose-built storage stack can beat a general-purpose service only when the workload is narrow enough to specialise for.

Storage was the dominant cost line, not an incidental one. Optimising something that is 60% of your cost of revenue is a strategic act; optimising something that is 3% is a distraction.

It was core to the product. Dropbox's product is storage. Owning it is owning the core domain — the same argument as Netflix and its CDN.

They had the engineering capability, and they kept a hybrid posture — remaining on public cloud for regions and workloads where that made more sense, rather than treating repatriation as ideological.

Why it is not a general lesson

The conditions are demanding: extreme scale, a narrow workload, storage as the dominant cost, deep in-house expertise, and multi-year commitment. Most organisations meet none of them. The cloud's value proposition — elasticity, breadth of managed services, no capacity planning — is worth a substantial premium for a workload that is varied and not enormous.

The transferable reasoning

Build-versus-buy is a function of scale and specificity, and the answer legitimately changes over time. The right choice at \(10M of annual spend on a diverse workload is not the right choice at \)100M on one workload. The mistake is treating an early decision as permanent — and the equal and opposite mistake is generalising Dropbox's answer to an estate that looks nothing like theirs.