5 ms·

First off, I don't think there is anything wrong with MinIO closing down its open source. There are simply too many people globally who use open source without

First off, I don't think there is anything wrong with MinIO closing down its open source. There are simply too many people globally who use open source without being willing to pay for it. I started testing various alternatives a few months ago, and I still believe RustFS will emerge as the winner after MinIO's exit. I evaluated Garage, SeaweedFS, Ceph, and RustFS. Here are my conclusions: 1. RustFS and SeaweedFS are the fastest in the object storage field. 2. The installation for Garage and SeaweedFS is more complex compared to RustFS. 3. The RustFS console is the most convenient and user-friendly. 4. Ceph is too difficult to use; I wouldn't dare deploy it without a deep understanding of the source code. Although many people criticize RustFS, suggesting its CLA might be "bait," I don't think such a requirement is excessive for open source software, as it helps mitigate their own legal risks. Furthermore, Milvus gave RustFS a very high official evaluation. Based on technical benchmarks and other aspects, I believe RustFS will ultimately win. https://milvus.io/blog/evaluating-rustfs-as-a-viable-s3-compatible-object-storage-backend-for-milvus.md https://milvus.io/blog/evaluating-rustfs-as-a-viable-s3-comp...

bityard 7mo ago
> too many people globally who use open source without being willing to pay for it. That's an odd take... open source is a software licensing model, not a business model. Unless you have some knowledge that I don't, MinIO never asked for nor accepted donations from users of their open source offerings. All of their funding came from sales and support of their enterprise products, not their open source one. They are shutting down their own contributions to the open source code in order to focus on their closed enterprise products, not due to lack of community engagement or (as already mentioned) community funding.
- victormy 7mo ago
  I respectfully disagree with the notion that open source is strictly a licensing model and not a business model. For an open-source project to achieve long-term reliability and growth, it must be backed by a sustainable commercial engine. History has shown that simply donating a project to a foundation (like Apache or CNCF) isn't a silver bullet; many projects under those umbrellas still struggle to find the resources they need to thrive. The ideal path—and the best outcome for users globally—is a "middle way" where: The software remains open and maintained. The core team has a viable way to survive and fund development. Open code ensures security, transparency, and a trustworthy software supply chain. However, the way MinIO has handled this transition is, in my view, the most disappointing approach possible. It creates a significant trust gap. When a company pivots this way, users are left wondering about the integrity of the code—whether it’s the potential for "backdoors" or undisclosed data transmission. I hope to see other open-source object storage projects mature quickly to provide a truly transparent and reliable alternative.
  - gunapologist99 7mo ago
    > For an open-source project to achieve long-term reliability and growth, it must be backed by a sustainable commercial engine You mean like Linux, Python, PostgreSQL, Apache HTTP Server, Node.js, MariaDB, GNU Bash, GNU Coreutils, SQLite, VLC, LibreOffice, OpenSSH?
    - victormy 7mo ago
      Actually, Linux reinforces my point. It isn't powered solely by volunteers; it thrives because the world's largest corporations (Intel, Google, Red Hat, etc.) foot the bill. The Linux Foundation is massively funded by corporate members, and most kernel contributors are paid engineers. Without that commercial engine, Linux would not have the dominance it does today. Even OpenAI had to pivot away from its original non-profit, open principles to survive and scale. There is nothing wrong with making money while sustaining open source. The problem is MinIO's specific approach. Instead of a symbiotic relationship, they treated the community as free QA testers and marketing pawns, only to pull up the ladder later. That’s a "bait-and-switch," not a sustainable business model.
      - overfeed 7mo ago
        > Actually, Linux reinforces my point. Not many open source projects are Linux-sized. Linux is worth billions of dollars and enabled Google and Redhat to exist, so they can give back millions, without compulsion, and in a self-interested way. Random library maintainer dude should not expect their (very replaceable) library to print money. The cool open source tool/utility could be a 10-person company, maybe 100 tops, but people see dollar-signs in their eyes based on number of installs/GitHub stars, and get VC funding to take a swing for billions in ARR. I remember when (small scale) open source was about scratching your own itch without making it a startup via user-coercion. It feels like the 'Open source as a growth-hack" has metastasized into "Now that they are hooked, entire user base is morally obligated to give me money". I would have no issue if a project included this before it gets popular - but that may prevent popular adoption. So it rubs me the wrong way when folk want to have their cake and eat it.
      - 7mo ago
- devsda 7mo ago
  > That's an odd take... open source is a software licensing model, not a business model. Yes, open-source is a software license model, not a business model. It is also not a software support model. This change is them essentially declaring that MinIO is EOL and will not have any further updates. For comparison, Windows 10 which is a paid software released in the same year as first minio release i.e. 2015 is already EOL.
  - NetMageSCW 7mo ago
    >This change is them essentially declaring that MinIO is EOL and will not have any further updates. Just fork it!
    - victormy 7mo ago
      Simply forking it won't work. The legal risks have been well-documented. Under their AGPL + Commercial model, the moment your fork gets too popular, MinIO can just shut you down. This is exactly why the smart money and talent have already moved on to systems like RustFS, SeaweedFS, and Garage instead of trying to maintain a doomed fork.
      - true_religion 7mo ago
        The only risk is if you’re trying to bootstrap your competitors with their open source contribution, and have a paid private integrations. AGPL means you cannot do this. This is less of a risk, than it is the explicit intention of the Licence.
jjm 7mo ago
Gosh, Ceph what a pita. Never again LOL. I wouldn't even want an LLM to suffer working on it.
- victormy 7mo ago
  Haha, totally get you! I think if you forced an LLM to manage a large-scale Ceph cluster, it would probably start hallucinating about retirement.
redskyluan 7mo ago
Maintainer of Milvus here. A few thoughts from someone who lives this every day: 1. The free user problem is real, and AI makes it worse. We serve a massive community of free Milvus users — and we're grateful for them, they make the project what it is. But we also feel the tension MinIO is describing. You invest serious engineering effort into stability and bug fixes, and most users will never become paying customers. In the AI era this ratio only gets harder — copy with AI becomes easier than ever 2. We need better object storage options. As a heavy consumer of object storage, Milvus needs a reliable, performant, and truly open foundation. RustFS is a solid candidate — we've been evaluating it seriously. But we'd love to see more good options emerge. If the ecosystem can't meet our needs long-term, we may have to invest in building our own. 3. Open source licensing deserves a serious conversation. The Apache 2.0 / Hadoop-era model served us well, but cracks are showing. Cloud vendors and AI companies consume enormous amounts of open-source infrastructure, and the incentives to contribute back are weaker than ever. I don't think the answer is closing the source — but I also don't think "hope enterprises pay for support" scales forever. We need the community to have an honest conversation about what sustainable open source looks like in the AI era. MinIO's move is a symptom worth paying attention to.
- victormy 7mo ago
  Huge thanks for your contributions to the open-source world! Milvus is an incredibly cool product and a staple in my daily stack. It’s been amazing to watch Milvus grow from its roots in China to gaining global trust and major VC backing. You've really nailed the commercialization, open-source governance, and international credibility aspects. Regarding RustFS, I think that—much like Milvus in the early days—it just needs time to earn global trust. With storage and databases, trust is built over years; users are naturally hesitant to do large-scale replacements without that long track record. Haha, maybe Milvus should just acquire RustFS? That would certainly make us feel a lot safer using it!
- hajile 7mo ago
  GPL for open source and commercial license for the enterprise lawyers. Unfortunately, a majority seems to hate GPL these days even though it prevents most of the worst corporate behaviors.
gunapologist99 7mo ago
Garage installation is easy. 1. Download or build the single binary into your system (install like `/usr/local/sbin/garage`) 2. Create a file `/etc/garage.toml`: metadata_dir = "/data/garage/meta" data_dir = "/data/garage/data" db_engine = "sqlite" replication_factor = 1 rpc_bind_addr = "[::]:3901" rpc_public_addr = "127.0.0.1:3901" rpc_secret = "[your rpc secret]" [s3_api] s3_region = "garage" api_bind_addr = "[::]:3900" root_domain = ".s3.garage.localhost" [s3_web] bind_addr = "[::]:3902" root_domain = ".web.garage.localhost" index = "index.html" [k2v_api] api_bind_addr = "[::]:3904" [admin] api_bind_addr = "[::]:3903" admin_token = "woG4Czw6957vNTXNfLABdCzI13NTP94M+qWENXUBThw=" metrics_token = "3dRhgCRQQSxfplmYD+g1UTEZWT9qJBIsI56jDFy0VQU=" 3. Start it with `garage server` or just have an AI write an init script or unit file for you. (You can pkill -f /usr/local/sbin/garage to shut it down.) Also, NVIDIA has a phenomenal S3 compatible system that nobody seems to know about named AIStore: https://aistore.nvidia.com/ https://aistore.nvidia.com/ It's a bit more complex, but very powerful and fast (faster than MinIO - slightly less space efficient than MinIO because it maintains a complete copy of an object on a single node so that the object doesn't have to be reconstituted as it would on MinIO.) It also can be a proxy in front of other S3 systems, including AWS S3 or GCS etc and offer a single unified namespace to your clients. IMO, Seaweedfs is still too much of a personal project, it's fast for small files, but keep good and frequent backups in a different system if you choose it. I personally will avoid RustFS. Even if it was totally amazing, the Contributor License Agreement makes me feel like we're getting into the whole Minio rug-pull situation all over again, and you know what they say about doing the same thing and expecting a different result..
- victormy 7mo ago
  Garage is indeed an excellent project, but I think it has a few drawbacks compared to the alternatives: Metadata Backend: It relies on SQLite. I have concerns about how well this scales or handles high concurrency with massive datasets. Admin UI: The console is still not very user-friendly/polished. Deployment Complexity: You are required to configure a "layout" (regions/zones) to get started, whereas MinIO doesn't force this concept on you for simple setups. Design Philosophy: While Garage is fantastic for edge/geo-distributed use cases, I feel its overall design still lags behind MinIO and RustFS. There is a higher barrier to entry because you have to learn specific Garage concepts just to get it running.
yjftsjthsd-h 7mo ago
> Although many people criticize RustFS, suggesting its CLA might be "bait," I don't think such a requirement is excessive for open source software, as it helps mitigate their own legal risks. What legal risks does it help mitigate?
- everfrustrated 7mo ago
  RustFS has rug-pull written all over it. You can bookmark this comment for the future. 100% guaranteed it will happen. Only question is when.
  - victormy 7mo ago
    Lol, maybe you should fund the RustFS team yourself or sponsor a top-tier legal team for them. If you can help them rewrite their CLAs and guarantee they'll never face any IP risks down the road, then sure, you're 100% right.
    - yjftsjthsd-h 7mo ago
      And again - what IP risk does a CLA solve, that a DCO wouldn't? Like, IANAL so I certainly could be missing something, but I'd like to hear what it might be.
      - victormy 7mo ago
        I’m also maintaining an open-source project and have spent significant time drafting our CLA, so I completely understand the concerns surrounding them. While DCO is excellent for tracking provenance, we opted for a CLA primarily to address explicit patent grants and sublicensing rights—areas where a standard DCO often lacks the comprehensive legal coverage that a formal agreement provides. It’s a common and sustainable practice in the industry to keep the core code open-source while developing enterprise features. Without a solid CLA in place, a project faces massive legal hurdles later on—whether that’s for future commercialization or even the eventual donation of the project to an open-source foundation like the CNCF or Apache Foundation. We're just trying to ensure long-term legal clarity for everyone involved.
singhrac 7mo ago
I want to like RustFS, but it feels like there's so much marketing attached to the software it turns me off a little. Even a little rocket emoji and benchmark in the Github about page. Sometimes less is more. Look at the ty Github home page - 1 benchmark on the main page, the description is just "An extremely fast Python type checker and language server, written in Rust.".
- victormy 7mo ago
  Haha, +1. I really like RustFS as a product, but the marketing fluff and documentation put me off too. It reads like non-native speakers relying heavily on AI, which explains a lot. Honestly, they really need to bring in some native English speakers to overhaul the docs. The current vibe just doesn't land well with a US audience.
dathinab 7mo ago
> 4. Ceph [...] MinIO was more for the "mini" use case (or more like "anything not large scale", with a very broad definition of large scale). Here "works out of the box" is paramount. And Ceph is more for the maxi use case. Here in depth fine tuning, highly complex setups, distributed setups and similar are the norm. Hence out of the box small scale setup experience is bearly relevant. So they really don't fill out the same space, even through their functionality overlaps.
- __turbobrew__ 7mo ago
  Definitely, ceph shines in the 1-100 petabyte range whereas minio excelled in the 0-1 petabyte range.
hintymad 7mo ago
> RustFS and SeaweedFS are the fastest in the object storage field. I'm not sure if SeaweedFS is comparable. It's based on Facebook's Haystack design, which is used to address a very specific use case: minimizing the IOs, in particular the metadata lookup, for accessing individual objects. This leads to many trade-offs. For instance, its main unit of operations is on volumes. Data is appended to a volume. Erasure coding is done per volume. Updates are done at volume level, and etc. On the other hand, a general object store goes beyond needle-in-a-haystack type of operations. In particular, people use an object store as the backend for analytics, which requires high-throughput scans.
kyyol 7mo ago
I run Ceph in my k8s cluster (using rook) -- 4 nodes, 2x 4TB enterprise SSDs on each node. It's been pretty bulletproof; took some time to set up and familiarize with Ceph but now it's simple to operate. Claude Code is amazing at managing Ceph, restoring, fixing CRUSH maps, etc. It's got all the Ceph motions down to a tee. With the tools at our disposal nowadays, saying "I wouldn't dare deploy it without a deep understanding of the source code" seems like an overexaggeration! I encourage folks to try out Ceph if it supports their usecase.
- __turbobrew__ 7mo ago
  If you setup ceph correctly (multiple failure domains, correct replication rules across failure domains, monitors spread across failure domain, osds are not force purged) it is actually pretty hard to break it. Rook helps a lot too as rook makes it easier to set up ceph correctly.
- sgarland 7mo ago
  Considering the hallucinations I routinely deal with about databases, there isn’t a chance in hell I would trust an LLM to manage my storage for me.
meotimdihia 7mo ago
It looks like this article is biased. It only benchmarked RustFS. In my experience, SeaweedFS has at least 3–5× better performance than MinIO. I used MinIO to host 100 TB of images to serve millions of users daily.

bityard 7mo ago

> too many people globally who use open source without being willing to pay for it. That's an odd take... open source is a software licensing model, not a business model. Unless you have some knowledge that I don't, MinIO never asked for nor accepted donations from users of their open source offerings. All of their funding came from sales and support of their enterprise products, not their open source one. They are shutting down their own contributions to the open source code in order to focus on their closed enterprise products, not due to lack of community engagement or (as already mentioned) community funding.

victormy 7mo ago
I respectfully disagree with the notion that open source is strictly a licensing model and not a business model. For an open-source project to achieve long-term reliability and growth, it must be backed by a sustainable commercial engine. History has shown that simply donating a project to a foundation (like Apache or CNCF) isn't a silver bullet; many projects under those umbrellas still struggle to find the resources they need to thrive. The ideal path—and the best outcome for users globally—is a "middle way" where: The software remains open and maintained. The core team has a viable way to survive and fund development. Open code ensures security, transparency, and a trustworthy software supply chain. However, the way MinIO has handled this transition is, in my view, the most disappointing approach possible. It creates a significant trust gap. When a company pivots this way, users are left wondering about the integrity of the code—whether it’s the potential for "backdoors" or undisclosed data transmission. I hope to see other open-source object storage projects mature quickly to provide a truly transparent and reliable alternative.
- gunapologist99 7mo ago
  > For an open-source project to achieve long-term reliability and growth, it must be backed by a sustainable commercial engine You mean like Linux, Python, PostgreSQL, Apache HTTP Server, Node.js, MariaDB, GNU Bash, GNU Coreutils, SQLite, VLC, LibreOffice, OpenSSH?
  - victormy 7mo ago
    Actually, Linux reinforces my point. It isn't powered solely by volunteers; it thrives because the world's largest corporations (Intel, Google, Red Hat, etc.) foot the bill. The Linux Foundation is massively funded by corporate members, and most kernel contributors are paid engineers. Without that commercial engine, Linux would not have the dominance it does today. Even OpenAI had to pivot away from its original non-profit, open principles to survive and scale. There is nothing wrong with making money while sustaining open source. The problem is MinIO's specific approach. Instead of a symbiotic relationship, they treated the community as free QA testers and marketing pawns, only to pull up the ladder later. That’s a "bait-and-switch," not a sustainable business model.
    - overfeed 7mo ago
      > Actually, Linux reinforces my point. Not many open source projects are Linux-sized. Linux is worth billions of dollars and enabled Google and Redhat to exist, so they can give back millions, without compulsion, and in a self-interested way. Random library maintainer dude should not expect their (very replaceable) library to print money. The cool open source tool/utility could be a 10-person company, maybe 100 tops, but people see dollar-signs in their eyes based on number of installs/GitHub stars, and get VC funding to take a swing for billions in ARR. I remember when (small scale) open source was about scratching your own itch without making it a startup via user-coercion. It feels like the 'Open source as a growth-hack" has metastasized into "Now that they are hooked, entire user base is morally obligated to give me money". I would have no issue if a project included this before it gets popular - but that may prevent popular adoption. So it rubs me the wrong way when folk want to have their cake and eat it.
    - 7mo ago
devsda 7mo ago
> That's an odd take... open source is a software licensing model, not a business model. Yes, open-source is a software license model, not a business model. It is also not a software support model. This change is them essentially declaring that MinIO is EOL and will not have any further updates. For comparison, Windows 10 which is a paid software released in the same year as first minio release i.e. 2015 is already EOL.
- NetMageSCW 7mo ago
  >This change is them essentially declaring that MinIO is EOL and will not have any further updates. Just fork it!
  - victormy 7mo ago
    Simply forking it won't work. The legal risks have been well-documented. Under their AGPL + Commercial model, the moment your fork gets too popular, MinIO can just shut you down. This is exactly why the smart money and talent have already moved on to systems like RustFS, SeaweedFS, and Garage instead of trying to maintain a doomed fork.
    - true_religion 7mo ago
      The only risk is if you’re trying to bootstrap your competitors with their open source contribution, and have a paid private integrations. AGPL means you cannot do this. This is less of a risk, than it is the explicit intention of the Licence.

jjm 7mo ago

Gosh, Ceph what a pita. Never again LOL. I wouldn't even want an LLM to suffer working on it.

victormy 7mo ago
Haha, totally get you! I think if you forced an LLM to manage a large-scale Ceph cluster, it would probably start hallucinating about retirement.

redskyluan 7mo ago

Maintainer of Milvus here. A few thoughts from someone who lives this every day: 1. The free user problem is real, and AI makes it worse. We serve a massive community of free Milvus users — and we're grateful for them, they make the project what it is. But we also feel the tension MinIO is describing. You invest serious engineering effort into stability and bug fixes, and most users will never become paying customers. In the AI era this ratio only gets harder — copy with AI becomes easier than ever 2. We need better object storage options. As a heavy consumer of object storage, Milvus needs a reliable, performant, and truly open foundation. RustFS is a solid candidate — we've been evaluating it seriously. But we'd love to see more good options emerge. If the ecosystem can't meet our needs long-term, we may have to invest in building our own. 3. Open source licensing deserves a serious conversation. The Apache 2.0 / Hadoop-era model served us well, but cracks are showing. Cloud vendors and AI companies consume enormous amounts of open-source infrastructure, and the incentives to contribute back are weaker than ever. I don't think the answer is closing the source — but I also don't think "hope enterprises pay for support" scales forever. We need the community to have an honest conversation about what sustainable open source looks like in the AI era. MinIO's move is a symptom worth paying attention to.

victormy 7mo ago
Huge thanks for your contributions to the open-source world! Milvus is an incredibly cool product and a staple in my daily stack. It’s been amazing to watch Milvus grow from its roots in China to gaining global trust and major VC backing. You've really nailed the commercialization, open-source governance, and international credibility aspects. Regarding RustFS, I think that—much like Milvus in the early days—it just needs time to earn global trust. With storage and databases, trust is built over years; users are naturally hesitant to do large-scale replacements without that long track record. Haha, maybe Milvus should just acquire RustFS? That would certainly make us feel a lot safer using it!
hajile 7mo ago
GPL for open source and commercial license for the enterprise lawyers. Unfortunately, a majority seems to hate GPL these days even though it prevents most of the worst corporate behaviors.

gunapologist99 7mo ago

Garage installation is easy. 1. Download or build the single binary into your system (install like `/usr/local/sbin/garage`) 2. Create a file `/etc/garage.toml`: metadata_dir = "/data/garage/meta" data_dir = "/data/garage/data" db_engine = "sqlite" replication_factor = 1 rpc_bind_addr = "[::]:3901" rpc_public_addr = "127.0.0.1:3901" rpc_secret = "[your rpc secret]" [s3_api] s3_region = "garage" api_bind_addr = "[::]:3900" root_domain = ".s3.garage.localhost" [s3_web] bind_addr = "[::]:3902" root_domain = ".web.garage.localhost" index = "index.html" [k2v_api] api_bind_addr = "[::]:3904" [admin] api_bind_addr = "[::]:3903" admin_token = "woG4Czw6957vNTXNfLABdCzI13NTP94M+qWENXUBThw=" metrics_token = "3dRhgCRQQSxfplmYD+g1UTEZWT9qJBIsI56jDFy0VQU=" 3. Start it with `garage server` or just have an AI write an init script or unit file for you. (You can pkill -f /usr/local/sbin/garage to shut it down.) Also, NVIDIA has a phenomenal S3 compatible system that nobody seems to know about named AIStore: https://aistore.nvidia.com/ https://aistore.nvidia.com/ It's a bit more complex, but very powerful and fast (faster than MinIO - slightly less space efficient than MinIO because it maintains a complete copy of an object on a single node so that the object doesn't have to be reconstituted as it would on MinIO.) It also can be a proxy in front of other S3 systems, including AWS S3 or GCS etc and offer a single unified namespace to your clients. IMO, Seaweedfs is still too much of a personal project, it's fast for small files, but keep good and frequent backups in a different system if you choose it. I personally will avoid RustFS. Even if it was totally amazing, the Contributor License Agreement makes me feel like we're getting into the whole Minio rug-pull situation all over again, and you know what they say about doing the same thing and expecting a different result..

victormy 7mo ago
Garage is indeed an excellent project, but I think it has a few drawbacks compared to the alternatives: Metadata Backend: It relies on SQLite. I have concerns about how well this scales or handles high concurrency with massive datasets. Admin UI: The console is still not very user-friendly/polished. Deployment Complexity: You are required to configure a "layout" (regions/zones) to get started, whereas MinIO doesn't force this concept on you for simple setups. Design Philosophy: While Garage is fantastic for edge/geo-distributed use cases, I feel its overall design still lags behind MinIO and RustFS. There is a higher barrier to entry because you have to learn specific Garage concepts just to get it running.

yjftsjthsd-h 7mo ago

> Although many people criticize RustFS, suggesting its CLA might be "bait," I don't think such a requirement is excessive for open source software, as it helps mitigate their own legal risks. What legal risks does it help mitigate?

everfrustrated 7mo ago
RustFS has rug-pull written all over it. You can bookmark this comment for the future. 100% guaranteed it will happen. Only question is when.
- victormy 7mo ago
  Lol, maybe you should fund the RustFS team yourself or sponsor a top-tier legal team for them. If you can help them rewrite their CLAs and guarantee they'll never face any IP risks down the road, then sure, you're 100% right.
  - yjftsjthsd-h 7mo ago
    And again - what IP risk does a CLA solve, that a DCO wouldn't? Like, IANAL so I certainly could be missing something, but I'd like to hear what it might be.
    - victormy 7mo ago
      I’m also maintaining an open-source project and have spent significant time drafting our CLA, so I completely understand the concerns surrounding them. While DCO is excellent for tracking provenance, we opted for a CLA primarily to address explicit patent grants and sublicensing rights—areas where a standard DCO often lacks the comprehensive legal coverage that a formal agreement provides. It’s a common and sustainable practice in the industry to keep the core code open-source while developing enterprise features. Without a solid CLA in place, a project faces massive legal hurdles later on—whether that’s for future commercialization or even the eventual donation of the project to an open-source foundation like the CNCF or Apache Foundation. We're just trying to ensure long-term legal clarity for everyone involved.

singhrac 7mo ago

I want to like RustFS, but it feels like there's so much marketing attached to the software it turns me off a little. Even a little rocket emoji and benchmark in the Github about page. Sometimes less is more. Look at the ty Github home page - 1 benchmark on the main page, the description is just "An extremely fast Python type checker and language server, written in Rust.".

victormy 7mo ago
Haha, +1. I really like RustFS as a product, but the marketing fluff and documentation put me off too. It reads like non-native speakers relying heavily on AI, which explains a lot. Honestly, they really need to bring in some native English speakers to overhaul the docs. The current vibe just doesn't land well with a US audience.

dathinab 7mo ago

> 4. Ceph [...] MinIO was more for the "mini" use case (or more like "anything not large scale", with a very broad definition of large scale). Here "works out of the box" is paramount. And Ceph is more for the maxi use case. Here in depth fine tuning, highly complex setups, distributed setups and similar are the norm. Hence out of the box small scale setup experience is bearly relevant. So they really don't fill out the same space, even through their functionality overlaps.

__turbobrew__ 7mo ago
Definitely, ceph shines in the 1-100 petabyte range whereas minio excelled in the 0-1 petabyte range.

hintymad 7mo ago

> RustFS and SeaweedFS are the fastest in the object storage field. I'm not sure if SeaweedFS is comparable. It's based on Facebook's Haystack design, which is used to address a very specific use case: minimizing the IOs, in particular the metadata lookup, for accessing individual objects. This leads to many trade-offs. For instance, its main unit of operations is on volumes. Data is appended to a volume. Erasure coding is done per volume. Updates are done at volume level, and etc. On the other hand, a general object store goes beyond needle-in-a-haystack type of operations. In particular, people use an object store as the backend for analytics, which requires high-throughput scans.

kyyol 7mo ago

I run Ceph in my k8s cluster (using rook) -- 4 nodes, 2x 4TB enterprise SSDs on each node. It's been pretty bulletproof; took some time to set up and familiarize with Ceph but now it's simple to operate. Claude Code is amazing at managing Ceph, restoring, fixing CRUSH maps, etc. It's got all the Ceph motions down to a tee. With the tools at our disposal nowadays, saying "I wouldn't dare deploy it without a deep understanding of the source code" seems like an overexaggeration! I encourage folks to try out Ceph if it supports their usecase.

__turbobrew__ 7mo ago
If you setup ceph correctly (multiple failure domains, correct replication rules across failure domains, monitors spread across failure domain, osds are not force purged) it is actually pretty hard to break it. Rook helps a lot too as rook makes it easier to set up ceph correctly.
sgarland 7mo ago
Considering the hallucinations I routinely deal with about databases, there isn’t a chance in hell I would trust an LLM to manage my storage for me.

meotimdihia 7mo ago

It looks like this article is biased. It only benchmarked RustFS. In my experience, SeaweedFS has at least 3–5× better performance than MinIO. I used MinIO to host 100 TB of images to serve millions of users daily.