Letting families download everything, without melting the server

Being able to leave a platform with everything you put into it, in full quality, no strings attached, is a basic form of respect for user data. MamaPapa's "download all my photos" feature exists for exactly that reason: a family's photos and videos, at original quality, packaged as a ZIP they can save wherever they want, accompanied by a manifest describing what's included.

The idea is simple. Building it without it becoming a way to accidentally take the whole system down took more thought.

You can't buffer a family's entire photo library in memory

A family that's used MamaPapa for years can have gigabytes of original-quality photos and videos. Trying to assemble that into a ZIP file in memory before sending it would mean holding potentially enormous amounts of data in RAM per export request, a design that works fine in testing with a small sample library and then falls over the first time someone with years of photos actually uses it.

The export instead streams: photos and videos get pulled from storage and written into the ZIP archive as it's being sent to the user, rather than being fully assembled first and only then transmitted. Memory usage stays roughly constant regardless of how large the export actually is, because the server is never holding more than a small buffer's worth of data at any given moment, not the entire archive at once.

Rate limits that match how the feature is actually used

Downloading your entire photo library isn't something anyone needs to do repeatedly. It's a rare, deliberate action, someone switching services, wanting a local backup, or just wanting peace of mind that their data is genuinely theirs to keep. That usage pattern shaped the rate limits: one export per day, and no more than three within a rolling thirty-day window, tracked per user.

Those limits aren't there to make the feature annoying to use. They exist because a streamed export of a large library is still a meaningfully expensive operation for the server to perform, reading potentially gigabytes of data from storage and streaming it back out. A limit shaped around how the feature is actually meant to be used, occasional and deliberate, doesn't get in the way of anyone using it the way it's intended, while still preventing it from becoming an accidental way to hammer the storage backend through repeated requests.

A global cap, because one user's export isn't the only export running

On top of the per-user limits, there's a global concurrency cap: no more than three exports run across the entire system at the same time, regardless of who's requesting them. Without that cap, a handful of large libraries all being exported simultaneously could still add up to real load, even if each individual user were well within their own personal limits. The global cap is what keeps the feature safe in aggregate, not just safe per person.

Data portability is easy to promise and harder to actually build in a way that holds up once the libraries involved are large and the request volume is real. Streaming instead of buffering, and rate-limiting based on how the feature is actually meant to be used rather than an arbitrary number, is what makes "download everything, whenever you want" something MamaPapa can actually offer without it becoming a liability.

More on how MamaPapa handles your data is on its product page.