MinIO Reviews

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.

We use MinIO for enterprise file storage.

I have been using MinIO for approximately three years.

The stability of MinIO is good.

The scalability is one of the limitations we have found. We are looking for another solution but they must provide the same characteristics, such as an affordable price and continuity.

We have approximately 100 of my colleagues that are using the file service.

I have not needed to use the support.

The initial implementation was straightforward. It took us three days for the process.

We use our in-house team of two to do the implementation. The maintenance is done by three people 10 days out of the year.

MinIO is a free open-source solution.

I rate MinIO an eight out of ten.

My primary use case for MinIO is as a tool for document management and storage.

The benefit of MinIO is that it's more secure. It also facilitates our works due to the facility of its end-point course.

MinIO's most valuable feature is that we can send a lot of detail in the bottom of the core of the end-point, in a way that is easy and interactive. It also saves a lot of time in generating and managing documents.

An area that could be improved is the limited storage provided in the free version of this tool. When handling a lot of documents, the interaction can take a lot of time.

I've been using MinIO for the last two to three years.

The stability of this solution is fine, though sometimes the duration of responses is too long.

MinIO is easy to scale.

The initial setup was not easy at all. We had some problems since we weren't given the information on how many instances needed to be deployed the first time, which blocked our deployment. It took us one or two days to deploy the product. On the other hand, it was very easy to manipulate and interact with.

I think MinIO is the most efficient tool in the management of documents, and its performance facilitates our works. I would rate this tool as seven out of ten.

Generally speaking, we use MiniIO for storing unstructured or semi-structured data. In my current project, we were using it for the semi-structured data. We also use MinIO as a data link. The data is transformed and loaded onto MinIO. And MinIO is used to rate the statistics based on the data.

So I'll just briefly explain how the entire flow works and how the data comes into the menu. After we transform the data, we input it into MinIO. The raw data is in different formats. It is in a delimited, positional-specific, or some other format. And three types of data—virtual, date and time, and numeric—are being loaded, including all Python and Java date formats and various kinds of normal data. Once we transform the data, we load it onto MinIO.

The development and QA teams are the primary users. They work on MinIO together to load the data. So, for the lower environment, the subsequent systems directly read the data from the menu and then utilize it for visualization. The actual end-customer is not reading the data directly from MinIO.

Earlier, the organization experienced some issues transforming the data and loading it into the technology, so we adopted Spark, and the data was to be loaded onto the menu, MinIO. In terms of the volume, processing speed, and accessibility of data, MinIO was outstanding. First, it worked well for storing large volumes and sizes of data. Second, you can retrieve, load, or transform data with MinIO quite fast. It is a backbone to the organization because it loads the data and stores it after transformation, then all the lower systems can use it.

For starters, MinIO has a good user interface. You can access it through the browser and perform operations like creating the object. And inside that, you can make the bucket manually. You can also access it through the command-line interface. Using the command interface, you can perform a complete set of operations — create the bucket, open it, read the data, delete those buckets, etc. — and it is pretty fast 

The Distributed User Interface (DUI) needs some work. It's hard to view a large set of data on the DUI. It's an issue with the DUI's performance. One way to improve this would be to allow a large set of data to be directly viewed on the UI. Usually, business people do not access the data through the command-line interface. So the DUI tool could be helpful if MinIO improves its performance and ability to handle a larger sample of data. When you're working with a small set of data, the DUI can download that quite easily. But if the data set is vast, it takes time. It becomes quite challenging to view that or download that data. So maybe introducing a PLI command-line interface could improve the DUI function. That would be very useful for the end-user.

I've been working with MinIO for about a year and a half to two years.

We have not faced any stability issues or had any problems accessing the data on MinIO that I can recall.

I think scalability-wise, MinIO is quite good. However, we had to do some MinIO cleanup activity on the lower environments. By lower environment, I mean the test or development environments. So we had limited capacity in the lower environments. But overall, we have not faced many issues in terms of scalability. Space was available whenever it was required. On the other hand, we could not automate scalability. We had to perform cleanup activity on the lower environments manually.

I haven't interacted with the MinIO technical support.

I did not help set up MinIO, so I will not be able to answer that question. An in-house DevOps team deployed it. Installing new versions of MinIO does not take much time. The entire deployment process took around two days for us, including deploying the code of different modules or different features. But I don't think the basic setup of MinIO took a very long time. It was installed in 10 minutes or so. The DevOps team, which includes around three to four people, upgrades MinIO from time to time.

I rate MinIO eight out of 10. It has a good UI, and it allows you to use the command line, which has a solid list of operations that you can perform. My advice to anyone who implementing MinIO is to take advantage of the command-line interface. It's pretty good to use. If you use the command line wisely, it is a highly efficient feature.

We were trying to implement on object-storage a distributable solution and the main use was for cryptocurrency mining. The cryptocurrency uses block storage or different storage for crypto mining.

With MinIO, we managed to go forward with our cryptocurrency mining project. 

The ease of use, the low memory footprint, and the community is quite helpful as well. The web interface is also pretty nice.

At the time, they were rewriting their documentation and they had two versions of it: legacy. found at https://docs.min.io/, and the current, which has 3 versions at the time; one of them being: https://docs.min.io/minio/bare...

Some of the information was in one and some was in the other. There wasn't just one place to go and look for whatever you required. They still appear to have a warning on top of the "baremetal docs".

I've been using it for the last six months or so.

We've had a few crashes because of excessive use. We struggled a little to learn where the problem was. Everything was in containers and it sometimes made visibility hard to get to the logs so we could figure out exactly what the problem was. 

It seems to be pretty scalable because you just need to add more nodes for instances of MinIO and it connects automatically.

We did not use paid support, but the community communication channels, mainly Flat.

Positive

We were using OpenStack, Shift, and Keystone. They provided an optic-storage solution, but it's fairly complicated to install and to maintain and to upgrade. Performance wasn't great either because of our type of setup, so we decided to check MinIO out, and the managers liked it. We ended up implementing.

I deployed MinIO myself. Deployment is pretty easy and straightforward. The one thing that takes more time is the tuning because it's made to be very automatic, so you don't have to mess a lot with the configuration. But in the end, you need to tweak it. So, installation was easy. It took two hours, maybe less. Tuning probably took a few days.

We deployed it in-house. 

That is not my area, but I am sure it is high. The service works fine and the deployment cost was minimal.

We went with the open source version. I wouldn't know what to tell you about licensing. That said, I think the open source version is quite good and has everything one needs.

We were using OpenStack Swift at the time. It's kind of difficult to deploy and manage in standalone mode. Also, the performance isn't as good. 

I would rate this solution a nine out of ten.

There were two huge users, but at points, there were many sporadical users. So basically, the two users were consuming 80% or 90% of the resources, while the rest of the users, maybe ten of them, working just indirectly.

The premise required a bit of maintenance, which I was responsible for. They tried to update very often. In fact, every two weeks they tried to make a release or they urged you to check if there were any new releases. At the time, given the nature of cryptocurrency mining, we were using MinIO extensively.

My advice would be to go through the manual slowly to understand every aspect of MinIO. That helps you grasp how it works and how it needs to be installed and what the requirements are. They have very good representation.

My primary use case is to help our customers integrate with MinIO to do file-sharing collaborations.

MinIO made it easy to collaborate with Amazon SDK.

The most valuable feature is file storage.

The product's security is open by default, without any SSL, which could be an area for improvement. I don't think I would request any new features in the next release, as the product currently meets all my needs.

I have been using MinIO for about six months.

The stability of this solution is great - with any file that we uploaded or downloaded, we found it was quick to respond.

My impression is that MinIO supports a wide range of clustering, and I believe it should work in a highly scalable environment for people with larger platforms and larger storage.

The initial setup was very easy - one click, and it was installed. That's what is great about MinIO.

MinIO is open source, but it also has an enterprise license available if preferred.

I feel MinIO is the best solution to recommend to anyone who requires on-premise S3-compatible storage. It is easy to install, easy to configure, and you can get it up and running in minutes, not hours or days. I would rate this product as nine out of ten.