Object storage

[uhthomas]

Object storage support has been widely requested (#1683) and is something we're keen to support. The limitations imposed by object storage happen to be beneficial for data resilience and consistency, as it makes features like the storage template infeasible. Issues like orphaned assets (#2877) or asset availability (#4442) would be resolved completely.

As discussed on the orphaned assets issue (#2877), I'd like to propose a new storage layout designed for object storage, with scalability and resilience as priorities.

Where:

• <asset id> is a unique ID for an asset, ideally a random UUID. UUIDv7 may serve to be beneficial due to its property of natural order. If not, UUIDv4 should be sufficient.
• <original asset filename> is the original filename of an asset, as it was uploaded.

.
└── <asset id>/
    ├── <original asset filename>
    ├── sidecar.xml
    └── thumbnails/
        ├── small.jpg
        └── large.webp

The above structure should serve to efficiently scale with resiliency and flexibility. The unique 'directory' for an asset can contain additional files like edits, colour profiles, thumbnails or anything else.

The original file and filename is preserved in case of an unlikely full database loss, where it should be possible to restore most information in such a scenario. This property is also good for humans, or if a full export is required. A directory of vague filenames without extensions would be quite unhelpful. I feel this strikes a good balance between legibility and a resiliency.

I have also considered content addressable storage (CAD), as it would save space in the event of duplicate uploads but consider it to be impractical due to complexity and the previous concern of legibility. I believe this should instead be deferred to the underlying storage provider, which can make much better decisions about how to store opaque binary blobs.

Part of this effort will require some changes to the storage interfaces (#1011) and the actual object storage implementation should use the AWS S3 SDK (docs). Most, if not all object storage systems should have an S3-compatible API.

[tonya11en]

The advantages aren't clear to me after reading- can you elaborate? Seems like the pitch is that it fixes orphaned assets and availability during storage migrations, but I'm failing to see how object storage fixes this as opposed to anything else (storing photos in the DB, flat filesystem indexed by DB, etc.)

[uhthomas]

@tonya11en This is possible with a regular file system, but there has been a lot of push back for implementing the proposal for it. The current model is fundamentally incompatible with object storage, and so the proposed safe and efficient structure is required.

It may be possible to introduce some configuration option to completely disable storage migration and use this proposal for block storage too, but I am not sure if it's worth the confusion at current. I'd much rather implement object storage and gather feedback.

I have started work on this, so hopefully I can show it soon.

[jrasm91]

I think the tldr is that if you don't ever move the file after it is uploaded you get a simpler system.

It has been discussed several times before and we have no immediate plans to drop support the storage template feature.

[pinpox]

Apart from the technical benefits, object storage can be rented way cheaper on providers like backblaze, scales without re-partitioning drives and has become pretty standard for theses applications as it makes deployment in clouds a lot easier and cleaner.

I'm eagerly awaiting the S3 support of immich to be able to migrate all my photos. Currently running a self hosted Nextcloud instance on a small VPS with external S3 storage via backblaze.

So, TL;DR: please strongly consider adding native support 🙂

[uhthomas]

#5917 will help - as it allows storage migration to be disabled.

[janbuchar]

To sum up discussion from Discord:

• @zackpollard mentioned that having many nested folders would make listing all files in the library slow on HDDs
  • however, it is desirable to have the same directory layout for both object storage and local storage
  • not just for simplicity's sake, I can see myself wanting to move my library from rclone-mounted S3 to native S3
  • listing all files is done quite often, for example on the Repair page in the administration
• renaming, however, is slow (and potentially expensive) in cloud storage - it's always copy+delete
  • the current directory layout needs to move every single uploaded file though
• disabling storage template migration for cloud storage seems like a reasonable thing to do
• wouldn't a middle ground approach where we store uploaded files in the local storage and upload them to cloud storage once metadata are extracted be sufficient? (I believe this was not answered by the team)

It is evident that there is pushback from the team against radical changes to the directory layout that may hinder performance. What would an MVP for cloud storage support look like?

[edude03]

you would create an entry in a local dynamodb

As far as I know you can't self host dynamo and it only exists in aws so not really a local database for most people.

I've only been following this thread passively to be honest, but I'm not sure I understand what the actual blocker to implementing this is - is it direction or dev time or core devs willingness to support it (or all of the above?)

Architecturally I believe abstracting the storage is straightforward, the frontend already gets a url to the image, it shouldn't matter if the image is remote or not.

The bucket doesn't need to be world readable for pre signed urls to work, and if people are really concerned - the images can be encrypted and decrypted on the client like how mega does it.

Tbh I don't know how immich already stores image metadata (I assume some kind of DB) the only real blocker I can see would be if immich doesn't store metadata and relies on reading it from the filesystem but even then we have sophisticated ways of storing metadata on object storage with things like parquet and deltalake

All this to say, where can the community actually help to get this over the line?

[bo0tzz]

a local DB that stored the relevant metadata information with a s3 uri path for the parent object

This is essentially how Immich currently works with local storage as well.

[bo0tzz]

I'm not sure I understand what the actual blocker to implementing this is

It's a very involved refactor that would almost certainly have to be executed by the core team, or very closely guided by us, and it's currently not enough of a priority to warrant that.

[andrew-d]

@bo0tzz apologies for the drive-by question, but... are there any incremental changes that us non-maintainers can do here? Even if the overall refactor needs to be executed by or guided by the core team, if there's code cleanup, test coverage, etc. that are a prerequisite for this, I'd be happy to help out in my free time 😃

[enarciso]

Chiming in on this sub-thread to close the gap in the maintainer's reasoning. I've already filed a PR with a solution, and it was quickly shut down, as seen in PR #22427. You can also see my contributions to this thread if you scroll further down. Overall, this project is great! I personally maintain a fork version with my S3 support intact. I only merge the released version of the code, and it has been serving my use case just fine. I didn't go the signed URL route because data transfer from an EC2 is cheaper than a signed URL, and there's a huge data transfer cost hit if your mobile phone is scrolling through images that are streamed (not saved locally on your phone). Small thumbnail sizes are cheaper. Communication between the EC2 and the bucket is free as long as they are in the same region, which saves a lot in the nightly jobs that run and in thumbnail generation. I can easily go back and forth from S3 to bare metal as long as I'm willing to pay for the data transfer cost hit when running a aws s3 sync cli.

You can try it out using the Docker images I maintain:

• enarciso/immich-server
• enarciso/immich-machine-learning

I manually build them now because I am hitting a 'disk is full' limit with GitHub Actions, and bumping the runner would require bumping my subscription to a teams/pro tier.

Overall, if anyone is interested in running their immich server in an EC2 instance and using an S3 bucket, feel free to test/use my image or fork my repo and build it yourself.

[uhthomas]

listing all files is done quite often

I would argue this is not the case at all and listing files is not a normal part of operation for Immich at all. It is only used for the repair page, and should run infrequently (if ever). There was also discussion of backups and how that may take a while, but I would also argue it should be an infrequent operation. Regardless, it seems important to some users, so we should try to optimise for this case. @bo0tzz proposed we move forward with an object storage implementation and answer some of these questions later, as to make progress, which I agree with.

wouldn't a middle ground approach where we store uploaded files in the local storage and upload them to cloud storage once metadata are extracted be sufficient? (I believe this was not answered by the team)

I don't think this would be sensible. The whole point of object storage support is to be fast and reliable. We should try to understand how to read directly from object storage rather than add additional complexity (i.e persisting things in multiple places).

[janbuchar]

listing all files is done quite often

I would argue this is not the case at all and listing files is not a normal part of operation for Immich at all.

I can't be the judge of that, but it looks like that there is no consensus about that amongst the developers, so a conservative approach to this seems correct.

wouldn't a middle ground approach where we store uploaded files in the local storage and upload them to cloud storage once metadata are extracted be sufficient? (I believe this was not answered by the team)

I don't think this would be sensible. The whole point of object storage support is to be fast and reliable. We should try to understand how to read directly from object storage rather than add additional complexity (i.e persisting things in multiple places).

I believe that this complexity is inherent to the problem though. Object storage can be the long-term destination for the assets, and assets can be delivered directly from there. However, operations such as metadata extraction and thumbnail generation work with the local filesystem and it would be difficult to change that.

[bo0tzz]

However, operations such as metadata extraction and thumbnail generation work with the local filesystem and it would be difficult to change that.

This is true, but I think the best approach there would be for the microservices instances to keep a cache folder that they download files into, rather than having files go to local storage -first- before being uploaded to S3.

[janbuchar]

However, operations such as metadata extraction and thumbnail generation work with the local filesystem and it would be difficult to change that.

This is true, but I think the best approach there would be for the microservices instances to keep a cache folder that they download files into, rather than having files go to local storage -first- before being uploaded to S3.

If I understand correctly, the two proposed ways of operation for the microservices are very similar - check if the target asset is present in the local filesystem (it doesn't matter if we call it a cache), if not, fetch it from the object storage. Then proceed with whatever the microservice does.

If the uploads folder is on the local filesystem, we 1) save ourselves one roundtrip to the object storage and 2) won't need to rename the uploaded file after we extract the metadata. What are the advantages of the object-storage-first approach?

[bo0tzz]

The advantage is consistency, knowing for a fact that if an asset is in Immich, it is absolutely also in the object storage. It also means that the server and microservices instances can be decoupled further, no longer requiring a shared filesystem.

[janbuchar]

The advantage is consistency, knowing for a fact that if an asset is in Immich, it is absolutely also in the object storage. It also means that the server and microservices instances can be decoupled further, no longer requiring a shared filesystem.

Fair enough. What would be the way forward with object storage support though?

• use the proposed storage for both object storage and local filesystem, ignoring the performance concerns?
• have a different storage layout for object storage and local filesystem?
• something entirely different?

[bo0tzz]

The past few days have seen significant discussion of the object storage topic amongst the maintainer team. There's no full consensus yet, but one thing that seems clear is that there will be a need for significant refactoring around how we store and handle files before object storage can be approached directly. That means cases such as abstracting away the current (filesystem) storage backend behind a common interface and using file streams throughout the code base rather than directly accessing paths. (I'll let @jrasm91 chime in on what other refactors might be needed).

[aries1980]

As a workaround, maybe https://github.com/efrecon/docker-s3fs-client could help? Has anyone tried using mounting S3 with FUSE?

[janbuchar]

As a workaround, maybe https://github.com/efrecon/docker-s3fs-client could help? Has anyone tried using mounting S3 with FUSE?

I currently run immich with the rclone docker volume driver and it is perfectly usable.

[enarciso]

Sorry for bringing up an old issue again. If anyone wants to test or do regression testing on a version of this, you can check it out at https://hub.docker.com/r/enarciso/immich-server (and the machine-learning). Instructions on what to put in your .env file and how to migrate from local to S3 are in the Overview. Thanks.
P.S. I recommend starting with IMMICH_STORAGE_ENGINE=local first to ensure everything is working properly. The option variables can be pre-populated already; as long as IMMICH_STORAGE_ENGINE is set to local, it won't do anything.

Where is the source code for this, I don't see a forked Immich repository in your GitHub account. I would advise against anyone blindly running a docker container if the source isn't available.

Yup, that's on me, sorry. Here's a forked version: https://github.com/enarciso/immich/tree/en/S3Support

Thanks

I finally had some time to reconcile my branch to main. This is now available in https://github.com/enarciso/immich/ (main branch)

Images are also available here: https://hub.docker.com/r/enarciso/immich-server & https://hub.docker.com/r/enarciso/immich-machine-learning

[kiskoza]

@enarciso are you planning to open a PR to bring this feature to Immich? I would love to use S3 storage, but on the other hand I would keep my setup running on the official images

[enarciso]

@enarciso are you planning to open a PR to bring this feature to Immich? I would love to use S3 storage, but on the other hand I would keep my setup running on the official images

I would love to, although I feel like I'm breaking some core architectural principles with this approach (not sure). I'm literally shimming it in server/src/cores/storage.core.ts. So, I’m not sure how the team would feel about that. Plus, I heavily relied on an LLM for this; again, I'm not sure how the team views that either. 😆

However, I understand your point, so I'll research it further and see what I come up with. Thanks

[Ardakilic]

@enarciso I'd just open the PR and get on with the feedback. You could always submit the review/feedback from the PR to the LLM, and make it update accordingly anyways 😏

[RogerSik]

I have two immich storage paths. One for thumbnails etc which is stored on SSD and one where the original files is stored on HDD. I have also 2 different minio instances. One on SSD and one on HDD. Would it be possible to define here 2 S3 endpoints and bucket?

[kiskoza]

So, I’m not sure how the team would feel about that.

The worst that can happen is they say it cannot be merged this way, and give you some guidance on how it could be improved - if you don't have the time, others might help finishing it. The best scenario is everyone having an official S3 support in the near future. I think you can give it a try

[enarciso]

I'm not sure what happened to my last comment here, but I did submit a PR, and it was a no, as I expected. #22427

[damianogiorgi]

I am doing a little experiment with S3Backer to indirectly use object storage, but it still requires testing to see how stable it is.
The deployment is on AWS, so latency is not an issue; however, it should also work in other environments.

If you want to give it a try and test it, while waiting for the feature to be implemented, you can find a guide on how I made it at this link: https://damianogiorgi.it/articles/2025/11/my-cheap-aws-setup-to-host-immich-files-on-s3/

[gvolpe]

I would definitely love Immich supporting native S3 object storage. In the meantime, I enjoyed the technical challenge of getting S3 object storage working. Happy new year! https://gvolpe.com/blog/immich-photos/

Immich is awesome 🤩

[diraneyya]

I've been following this discussion and #1683 for a while, and wanted to offer a perspective as a user and self-hosting advocate — not as a coder. I haven't implemented what I'm describing, and I don't know if it's entirely feasible. But I think there may be a disconnect between the concerns raised and the use cases driving demand for S3 support, and I wanted to try to articulate it.

The S3 support being discussed here appears to focus on server-proxied object storage — Immich stores files in S3 but still acts as an intermediary for all uploads and downloads. This addresses storage flexibility, data resilience, and decouples storage capacity from the server's local disk. All valuable things and I am not downtalking any of these.

However, I'd gently suggest this architecture doesn't address what may be the primary barrier to a broader adoption in my opinion: the Immich server becoming a bandwidth bottleneck.

Consider a typical self-hosting scenario: someone runs Immich on a modest VPS or home server with limited upload bandwidth. When family members back up photos or browse their library, every byte flows through that server. The experience is constrained by the server's connection, not by the user's connection or the storage provider's capabilities.

The architecture that would be transformative — and what I believe services like Ente Photos implement — is direct client-to-storage transfers:

1. Mobile app requests upload → server returns a pre-signed S3 URL → app uploads directly to S3
2. User views/downloads a photo → server returns a pre-signed URL → client fetches directly from S3 (or a CDN in front of it)

In this model, the Immich server handles authentication, metadata, ML processing, and orchestration — but bulk data transfer bypasses the server entirely. A user downloading a 4K video gets the speed of their connection to the S3 provider, not their connection to someone's residential upload pipe or a cheap VPS.

---

I noticed @uhthomas raised concerns about pre-signed URLs earlier in #1683, and I wanted to engage with those directly, because I suspect we may be imagining different use cases:

On caching and unfriendly URLs: In the architecture I'm imagining, pre-signed URLs wouldn't be exposed to users or cached long-term. The Immich client would request an asset, the server would generate a short-lived pre-signed URL on demand (based on its own caching logic), and redirect the client. The URL expires in minutes — it's not something users bookmark or share. The caching and UX concerns seem to apply to a different pattern where pre-signed URLs are stored or handed out in advance.

On S3 not being publicly accessible: This concern feels disconnected from the use cases driving most of the demand in these threads. The people asking for S3 support are largely saying things like:

• "I want to run Immich on a cheap VPS with limited disk"
• "I want to use Backblaze B2 / Cloudflare R2 because it's $6/TB/month"
• "I want to run Immich on a Raspberry Pi but store photos in the cloud"

For these use cases, the S3 bucket is definitionally publicly accessible — that's the whole point. If someone is running MinIO locally on the same network as Immich, they're not really decoupling compute from storage, and local filesystem storage would serve them just as well.

---

I realize I may be missing technical constraints that make this harder than it sounds. But I wanted to name this distinction clearly, because server-proxied S3 — while useful — doesn't fundamentally change the scalability story for users who want to serve a distributed family from limited infrastructure. Direct client-to-storage is what decouples compute from storage in a way that meaningfully impacts adoption.

If this architecture is already on the roadmap and I've misread the discussion, I apologize for the noise. And if there are fundamental reasons it won't work, I'd genuinely love to understand them.

Appreciate all the work going into this.

[jrasm91]

I think this was a good summary. The main issue with implementing any of these types of changes is usually the scope of work required to migrate away from an assumed, local file system to something abstract like s3. Introducing signed urls is a good idea and something that would be useful, but the server still directly needs to access files for all the jobs, storage template, integrity checks (WIP), database backup and restore functionality, etc. Not to mention updating documentation, providing migration tools between the two systems, etc. I think adding signed urls after the fact is trivial compared to the effort to make the server codebase configurable with s3 in the first place.

[Deeds67]

I built a proof-of-concept that adds S3-compatible object storage as an alternative backend to Immich's local disk storage. Both backends work simultaneously - existing disk assets keep working while new uploads go to S3.

What works:

• Upload → files written to S3 bucket
• Metadata extraction → downloads from S3 to temp, runs exiftool/ffprobe, cleans up
• Thumbnail & video encoding → same download-process-upload pattern
• Serving → presigned URL redirect or server-proxied streaming (configurable)
• ZIP download → streams S3 objects into archive
• Deletion → removes S3 objects
• ML pipeline (CLIP, face detection) → streams from S3 into memory for inference
• Sidecar handling → download/write/upload cycle for XMP files
• Motion photo extraction → works with S3 originals

How it works:

• New StorageBackend interface with DiskStorageBackend and S3StorageBackend implementations
• Path format in DB distinguishes backends: absolute = disk, relative = S3
• Config via env vars: IMMICH_STORAGE_BACKEND=s3, IMMICH_S3_BUCKET, IMMICH_S3_ENDPOINT, etc.
• Uses @aws-sdk/client-s3 — compatible with MinIO, Backblaze B2, Cloudflare R2, etc.
• Serving mode configurable: redirect (presigned URLs) or proxy (stream through server)

If there's interest from the maintainers, I'm happy to clean this up, address feedback, and submit a PR. The implementation is designed to be non-breaking. Disk mode is the default and behaves identically to today.

https://github.com/Deeds67/immich

2026-03-03.18-23-24.mp4

[pestaa]

As much as I want to see bucket storage happen in Immich, I wholeheartedly support the project owners in choosing the right timeline for this feature.

Generated or not, the code itself was never the challenge. This discussion should not be about LLMs.

Immich has powerful features that work seamlessly in the current architecture. Maintaining this seems to be the priority for this project, and giving that up is a one way road.

Give it time, or fork it.

[hk-ng]

"Saying code is LLM-generated" is an informal way to say the code quality is not acceptable.

If the code quality from LLM is good enough, we should not be able to tell if it is LLM generated.

[DomiiBunn]

To be a random person who drops their 2 cents.
Has anyone actually looked at the diff rather than seeing "AI" and thinking it's bad?

It is a reality that AI tools are becoming more widely used and, sadly, at many enterprises, a go-to. While many practises can lead to sloppy code... (Insert long rant about AI, code quality, etc., etc) The changes look good in my eyes (Being in the dev field for over 6 years now on different positions working with Node, TS, etc.

Diff in question It is a big diff, but it does implement the storage provider well. So I don't know. Immich is not my project; I just use it and love it thus far. But if I were a reviewer in a corporate setting for this (while being rather pissed at the size of it, understandable due to the scope), looking over some unnecessary changes that AI commonly leaves behind

server/src/services/asset-media.service.spec.ts
- 798 const updatedFile = fileStub.photo;
+ 806 const updatedFile = { ...fileStub.photo, originalPath: '/fake_path/photo1.jpeg' };

Most of it looks good, usable, human-readable, and maintainable.

[DomiiBunn]

"Saying code is LLM-generated" is an informal way to say the code quality is not acceptable.

If the code quality from LLM is good enough, we should not be able to tell if it is LLM generated.

Seen a lot more of human written code that is way less maintainable than AI code. AI will generate slop when not prompted/lead correctly. If a person using it uses it as a tool, it's just Intellisense on steroids.

[Deeds67]

To be a random person who drops their 2 cents. Has anyone actually looked at the diff rather than seeing "AI" and thinking it's bad?

It is a reality that AI tools are becoming more widely used and, sadly, at many enterprises, a go-to. While many practises can lead to sloppy code... (Insert long rant about AI, code quality, etc., etc) The changes look good in my eyes (Being in the dev field for over 6 years now on different positions working with Node, TS, etc.

Diff in question It is a big diff, but it does implement the storage provider well. So I don't know. Immich is not my project; I just use it and love it thus far. But if I were a reviewer in a corporate setting for this (while being rather pissed at the size of it, understandable due to the scope), looking over some unnecessary changes that AI commonly leaves behind

server/src/services/asset-media.service.spec.ts
- 798 const updatedFile = fileStub.photo;
+ 806 const updatedFile = { ...fileStub.photo, originalPath: '/fake_path/photo1.jpeg' };

Most of it looks good, usable, human-readable, and maintainable.

Thanks for taking a look. I didn’t intend for this entire diff to be merged as a single PR. It’s a POC and would absolutely require refinement and splitting into smaller PRs.

The goal was to provide a concrete starting point for discussion, both around the feature itself and what a final implementation could look like, and to gather some feedback.

[tino376dev]

Probably a very silly question, but what are the current discussion in the core team? Is this still an active topic? Is it being actively planned? Are there any rough target dates?

Thanks for the awesome product, it's very much appreciated.

[diraneyya]

@Deeds67 I just saw you committing to this immich fork named gallery: https://github.com/open-noodle/gallery which seems to be exactly what I have been seeking, namely, the S3 Compatible Storage section reads as follows:

Store your photos and videos in any S3-compatible object storage — AWS S3, MinIO, Cloudflare R2, Backblaze B2, Wasabi, and more. Configure it with a few environment variables and new uploads go straight to your bucket. Choose between redirect mode (clients download directly from S3 via presigned URLs) or proxy mode (server streams the files). Both disk and S3 backends run simultaneously ... 🎉🥳🍾

Who is behind this fork and for how long has it been around? I am be very excited and eager to test it and hopefully switch to it in the near future.

PS: If this is your fork then I would like to support you, please let me know how you would like to be supported.

[Deeds67]

PS: the immich mobile app DOES work, however it does not contain the new functionality that I have built. I will be launching the gallery apps soon on the app stores, they are pending approval

In my case it says it's incompatible.

It's just a warning due to the versions being different

[bjo81]

I would like to see S3 support here instead using your vibe-coded fork.

[tonya11en]

This discussion has been going on for multiple years at this point--I sincerely doubt the maintainers will make the changes needed for this. If the Immich fork that supports object storage adheres to the same API as the original Immich project, I don't see why Immich clients wouldn't be able to work with it.

[diraneyya]

I would like to see S3 support here instead using your vibe-coded fork.

Ultimately, we all want that, but as @jrasm91 explained, the path to having this support may not be linear, and may well run through an AI-assisted prototype like the one @Deeds67 is offering. The best thing we can do at this point is engage with and support this temporary, prototypical fork — testing it, benchmarking it, and bringing the results back here. Only then can we challenge the status quo in a way that prompts the folks behind Immich to decide for themselves if this is as much of a big deal and a blocker to wider adoption as we have been claiming.
There is not one possible outcome here, but multiple. One possibility is that we would realise why this will not work as we imagine — but even in that case, it is a win for the community, as this thread will get closed based on concrete results and practical evidence.
We all want the same thing here, but accepting that getting there might involve simultaneous, temporary, and new modalities of contribution is necessary for us to eventually converge.

[diraneyya]

I love how my comment above got (PS: and continue to get) equal thumbs down and heart emojis — a perfect reflection of how divided we are on this!
To those who reacted negatively: do you think a prototypical fork makes it less likely for Immich to implement this officially? I am genuinely curious. If it does not help, how can it hurt? And if you are simply frustrated that this has not made it into the official codebase yet, why not side with @Deeds67, who is obviously trying to do something about it?

[mikes1991gh]

With all due respect to the maintainers opinions/prioritizes etc, I’d like to add a reflection from my own usage.

My personal library is multi-terabyte and even though I would very much like to move it from NAS to cloud, the SSD option is just too expensive. I’m also hoping to help two non-profits with large archives migrate to Immich at some point. Their archives are already in the tens of TB and yearly cloud storage costs is in the thousands. This is already unsustainable for them and it will just keep growing.

IMHO, even at what might be considered “moderate” library sizes today, block storage becomes tricky, monthly costs are normally multiple times higher compared to object storage, and the gap grows as the archive expands. Beyond cost, traditional storage normally requires tracking usage and manually scaling, which is a real concern.

What I am trying to say is that many users naturally accumulate multi-TB archives over time, and this is hard to scale well with cloud based SSD-based storage. S3 support could make things more sustainable long term. Just my two cents, huge fan either way.