MinIO Reviews

I was using MinIO for my own research and some other work which I cannot disclose.

MinIO has brought more scalability, use of computing resources, and it can lead towards higher cost savings for companies.

The features that I have found most valuable with MinIO is its coding bit rot protection and how it distributes the workload over all the servers. I observed that the workload is very even in all the nodes.

I like the interface. It's beautifully designed and it's great. It's one of the best platforms I've seen and it is highly compatible. The only downside I see is that you do not have a complete picture of an object.

Additionally, a feature I would like to see in the next release would be if they can include an uneven disk structure. Then you can use an uneven number of disks and create a bunch of tickets by a factor of two. If I could use an odd number of disks, that would be better, it would give me more flexibility.

MinIO can sometimes crash because of the dependency in underlying OS software layers. Of course it crashes depending on the file system. There is a heavy dependence on the node's file system, that is another issue.

MinIO requires ongoing maintenance by the staff. Their interface is pretty good, it just needs a software upgrade.

MinIO should be easy to scale. It's an evenly scaling system.

I have plans to increase the usage.

The initial setup was simple.

You just need one person to do that part of the small cluster and I had a pretty small cluster so it didn't take much time - maybe half a day.

My advice to anyone considering using MinIO would be to first check if the open source version works for you. It probably should be able to. It has an S3 plugin so quite easily you can have interoperability between the public and private cloud or a hybrid setup. That is one advantage of the system. So if you need a private enterprise working as a public cloud, then MinIO is one of the best solutions I've seen so far.

I was using it for my personal work and MinIO it's a high-performance object storage system. So when you need high performance, you should go to MinIO.

On a scale of one to ten, I would rate MinIO an eight.

In the current market, when you have so many options for objects storage, MinIO is completely open source and an all inclusive package offering you both stability and scalability and its most attractive feature is the S3 plugin which is very similar to AWS.

We used it for machine learning artifacts in terms of model weights and the model outputs for visualizations for ephemeral tasks.

I was using it less than a year ago, and it was the latest open-source version.

It helped us to use AWS because we wanted a hybrid solution or to move to AWS eventually. MinIO provided that bridge. We could write code only once and make it work with MinIO. When we move the same code to the cloud to scale it, it will still continue to work.

The ability to spawn a MinIO Tenant on demand and shut it down right after is most valuable.

There should be the ability to expand the size after it has already been deployed. Currently, you cannot do that. It doesn't support an increase in size. Each time we spawn a new MinIO, we need to track the particular MinIO instance or tenant that has the file. Therefore, we had to create a multi-tenant solution that tracks the MinIO that has our artifacts. It isn't in one single instance. It should have better multi-tenancy support.

On Kubernetes, it wasn't as stable as we wanted it to be.

It scales very well. It integrates quite well with other solutions.

We had probably a couple of hundred users. Their titles were Machine Learning Engineers or DevOps Engineers.

I didn't have to call up MinIO for tech support. There is documentation, but it is not so good.

We are phasing it off, and we are going to AWS. We have stopped using MinIO. At the moment, we are using Alluxio.

It was a bit complex. The complete deployment took about a month and a half.

We used Kubernetes YAML files because we were using MinIO on Kubernetes. Once that was up, we had to expose the MinIO instances via load balancers. That's how we connected MinIO.

In terms of maintenance, we have to make sure that we're always using the latest version. So, we have SRE people deployed to just monitor the health and versions. We have to update a few hundred instances of MinIO.

I would advise others to not use MinIO on Kubernetes. I would rate MinIO an eight out of 10.

I am a software developer. My company was using MinIO to build new frontend applications. We were modernizing the desktop branch application into a web application because it was a modular application with lots of screens. 

We didn't want the architect team to increase the size of the client applications. We also did not want a single package as our clients in rural areas would not be able to efficiently load application pages from a very long package network. 

We were looking for a better way to optimize the load so MinIO was able to customize web packaging for the frontend and then decompose the web application components. We were packaging everything into a single package. By using MinIO we now optimize the transfer by providing storage for the packages.

Also, our development team had been deploying machine learning algorithms and modules were being produced. Some of these pilot projects do not end up going into production, so we use MinIO as storage for the data produced from machine learning. It works like a Git for machine learning models. The data is posted to Git and the actual files with the hashes are stored in MinIO. The IDs of those models are stored as metadata. It's a model versioning system for machine learning projects.

We deploy MinIO in our data centers as a local version.

The most valuable features are that MinIO is open, it works on-premise, and is compatible with the Amazon industry which is great for finding compatible libraries in many languages which is very good for developers.

MinIO could use a time patch on it. It could also use better documentation for some languages like Python. 

The company I was working for had been using MinIO for almost two years.

The company was using MinIO in production, it was stable because we depend on it for production. I have complaints about the stability.

The company was just putting files on a server disk prior to using MinIO.

The solution is a service provided to developers, so our systems and DevOps team was responsible for deploying MinIO.

I did not have any problems with MinIO, I would rate it a 9 out of 10.

We are using this solution as a data link, to store data in a structured dataset. We've been testing the functionalities and how we can integrate our system into it. We are customers of MinIO and I'm a data scientist. 

This is an all-in-one, user-friendly data storage solution. It provides high throughput to access data. We tend to use AI and some of the resource-intensive applications related to data, like analysis and visualization. I like the S3 API.

I feel there is a lack of good addons to integrate without having to use third-party applications. It makes the process time-consuming. It would be helpful if MinIO built artifacts or anything that could be used to stream data into it. That said, I'm not sure MinIO is different from other solutions. Hopefully, data governance will improve in the future. I'd also like to see more support for AI. 

I've been using this solution for four months. 

I can't judge stability yet because we're only using a couple of megabytes or gigabytes, it's very small. We probably have three or four potential users in the company. 

I previously worked with Hadoop which I found to be a little bit more complex than MinIO which is easier to use. I chose MinIO because I like the S3 API. We were looking for an all-in-one solution to backup or to carry out disaster recovery, and to have a place where we can store a new dataset for analysis and something for big data and AI.

I generally recommend it in favor of Hadoop Distributed File System because I can see more benefits and it's a little bit cheaper if you download it on-premises compared to Amazon S3.

The standalone is really easy to deploy. I think we'll deploy four nodes and I'll use Docker Swarm for that.

We are using the free version. This is still a new system and I think it's a good idea to have a free version to test before purchasing a license.

It's difficult to comment on the product because we haven't completed testing or deployed it in the production environment.  Moving to MinIO involves a learning curve. It's a question of whether someone is prepared to put in the effort to learn the solution and whether they have sufficient experience. The decision to use it needs to be based on whether it's for backup only or for backup and disaster recovery. Then there's the option to use it for analytics and AI, which is more complex and requires integration with other tools.

Once the solution has more maturity, I think it will become a dominant product. For now, I rate it eight out of 10.

We are a service provider for the financial sector. We make solutions for our biggest town and guys from this town. The government is trying to keep specific information inside the country, so we developed a solution with that goal in mind. 

MinIO was deployed in the center of the Kubernetes cluster, and it's used for keeping files. What's more interesting is how MinIO works with a file. So we used our widget in this instance. For the first approach, we got files from a user proficient system, I believe it's called. We got everything moving on FTP. After that, we put it all into MinIO on our internal partition. So that means transforming and preparing for transfer to the bank. With MinIO, you are preparing a pipeline of folders, where each folder maintains a particular stable file. So for that, we're using MinIO's ability to work with attributes and transfer copies of region files via the stream. As a solution, we use MinIO just like a file keeper. We use characteristics for storage then triple the small source from history 

MinIO's use case varies from project to project. In that case, guys from the company used MinIO as a solution for their particular system. It wasn't my decision to use MinIO. For my company, we use another approach because I work at Russian Post. It's a specific company with government contracts, and we have a lot of work requirements about what solutions we can use.

MinIO can work with attributes and folders, and it has the ability to use a stream approach for files. I have moments that should work exclusively. It also has some management features you can use, like exclusive locks that you can perform on one record or a collection. 

MinIO has behaved strangely in the past. For instance, the application dropped connection to MinIO. It's not too significant, but it loses connection. We're trying to understand exactly what is happening when this happens. Maybe the team at MinIO should work on this error because, at this time, it's unclear why this happens.

We've used MinIO for three months. We made two solutions in MinIO and used it to keep the bank's files and write up payment systems. 

I've never had trouble with the equipment, especially with DUI surges. I had connectivity issues, but it's not a problem with MinIO. The general lot level was not so high, and it didn't present any problems. Since we're not getting so many requests, we keep it all in MinIO and process it.

I think MinIO is not so hard to scale. Our guys are using part of this scale to replicate data, and this process was not very hard to scale. Right now, we have two teams using it. We make a solution for the financial part, and the other guys make one for customer data. And two teams were enough for that time. It was 10 or 12 developers.

I've never had to call MinIO support

Guys from DevOps helped us, so setting up MinIO was not so difficult.

Compared to SAS, MinIO is more straightforward from the developer side. It's easier to work with API. Most file solutions are similar when it comes to storage and how they work with ChAS SCP and Java. And when I compare, I'm trying to understand what the goal is and what level the developer should be working on with one of the solutions. I think MinIO is easier to use compared to Java API or for working this fast.

I rate MinIO seven out of 10. I say seven because I've worked with finance and require consistency and work with exclusive locks. From the standpoint of a coder or a developer, it's a good solution that's easy to use, connect, and prepare requests with. It doesn't require a lot of complex skills, and it's easy to put into your application. 

For people considering MinIO, I generally recommend understanding what level of consistency you want when working with these files. Also, you want to consider what kind of file reporting procedure you need, like streaming or batch processing. And, if you want some locks, like exclusive locks, then maybe you don't want MinIO. But for other sites, it's suitable.

A multi-tenant data space solution that in our case, consumes and stores large amounts of traffic sensor data for multiple cities worldwide. 

Right from the start the data-space solution we were building was supposed to be cloud native & cloud agnostic, hence instead of interacting with AWS-S3 using SDK we were using minIO as a gateway over AWS-s3 store. 

We're long-standing customers of MinIO. I was a senior member of the technical staff with the team who built the data-space solution.

While being well suit for kubernates, MinIO also made solution cloud agnostic in storage operations.  

For one of the customer due to regulatory constraints, we had to deploy the product on-prem with no access to AWS or open internet. MinIO out-of-the-box supports NFS share (volume) object store. It meant that rather than having to look out for or move to a new product we could stick with MinIO and adapt to newer environment requirements. Secondly, the APIs are quite well documented, including the setup onto Kubernetes clusters and we were able to reduce our ops efforts.

The solution has good compatibility with different kinds of storage and that was a major feature for us. 

We were using Presto, a query engine, which out-of-the-box connects to MinIO. 

MinIO provides APIs which have extensive documentation. 

The solution also has a good UI. During the development phase team sometimes needed to go through the data structure to see how data was getting stored. The UI helped us to debug the data quickly.

MinIO is easy to understand, simple to implement and provides a good feature set. 

There is nothing major that needs to be improved. 

While using some of the advance features of MinIO we encountered the minor bugs but they generally get fixed in version upgrades. 

I would like to see some kind of graphical representation of underlined data on MinIO UI. Like size, document type etc.

I've been using this solution for a year and a half.

Setting up MinIO on Kubernetes has its own perks. In terms of stability, Kubernetes took care of most things like spinning up new pod/node when existing one is down. More over MinIO itself is quite a stable application with less of application crashing instances and hardly any downtime in any of our environments. 

With high availability configuration it's easy to scale when running on Kubernetes.  

From a development team perspective, we have around eight users for either the console or API. From the application perspective, we had Presto, the query engine with connecting with system user.

Because the solution is open source we used the community to find solution of most of the problems we ran into.  

The initial setup was quite a straightforward process. The documentation which was provided in the Helm chart repository, was quite comprehensive and easy to access. The DevOps team carried out the deployment. Deploying the helm chart with default configuration doesn't take much time, it's a single line command. But if you want to do high availability production grade setup, then it might take couple of days.

Inhouse team set it up & maintaining it.

The solution is free for personal use but for large organizations/ commercial use, seems there are some charges involved. 

If you want to go with MinIO setup, I suggest using a Kubernetes-based setup using helm chart because it's quite easy to manage and will less of a learning curve. 

I rate the solution eight out of 10. 

We are a solution provider and I am working on a project that is using MinIO for storage.

The most valuable feature is the ease of management and administration. I do not have a system administrator in my project, so the simplicity of management is important to me.

The monitoring capability is really bad and needs to be improved. There are no monitoring tools available and there are several metrics that I would like to keep track of. Without good usage monitoring, it will be very hard to use in production.

In my opinion, the monitoring feature should be added to minIO in order to give administrators efficient data including bucket information(size, load on it, requests …), the CPU usage, running/ stuck/blocked threads, queue of thread pools, free/max heap percent, request per object in buckets and ...

I think providing REST API for monitoring and configuration makes it easier to use.

If I can set up MinIO to run as a service then it will be more stable.

Enhancing the user interface with more options would be a nice improvement.

I have been using MinIO for two years.

It is a stable product and I use it every day. If I were able to set it up as a service then the stability would be improved.

MinIO is scalable, although we do not rely on that right now. In the future, we will be expanding it. At this time, we have a team of five developers who are using MinIO.

I have not needed support to this point, as I seek help in the community when I have issues. Furthermore, because we are located in Iran and under sanctions, were are not able to purchase technical support.

I used to use Red Hat Ceph Storage, but it is more complex than MinIO and very difficult to manage because I do not have a system administrator on my team.

The initial setup is very simple. It took me about 15 minutes to deploy five instances that had Java on it.

I can easily deploy this solution using the command prompt.

This is an open-source solution but I am using the licensed version.

When I began this project, I researched several options for storage that were alternatives to Red Hat Ceph. I found that MinIO is the best choice for this project because of the API support.

My advice for anybody who is implementing MinIO is to visit the website and view the documentation. It is very complete and is helpful. 

This is a good product choice for startups that don't have a system administrator. It has a good API and it's easy to use. My main complaint is about the lack of monitoring tools.

I would rate this solution a nine out of ten.

My primary use case of MinIO is to ingest the data coming from devices, and to store the raw files coming from the devices.

The most valuable feature of this solution is its reliable erasure coding. It is also easy to deploy and manage.

I think the product tends to be more oriented toward Kubernetes and lacks documentation for people who don't want to use it, so they could improve their documentation. They could also better highlight the recommended versions as there are a lot of new versions, and it's difficult to know which is the best to use.

I've been using MinIO for two and a half years.

MinIO's stability is quite good, except for some synchronization issues.

I've used their Slack account for support, which gave me okay answers.

I previously used Red Hat Ceph Storage, which was harder to implement but more robust, with more features.

The initial setup wasn't too difficult and took between five to ten minutes.

You need to monitor disk usage and cluster status, but with correct monitoring, this solution works quite well. It's also important to keep up with upgrades as the product is evolving quite fast. If you need some S3-like solution with common features, MinIO is a good solution. I would rate this solution as eight out of ten.