MinIO Reviews

I am a solutions architect. MinIO is a public cloud type of storage that can attach external storage volume. I run it proprietary, or open-source. I use it to run a lot of test instances and production, spinning a new product out of it. In general, I use it for the S3 cloud storage capabilities.

Internally in our company, we have five people that use MinIO by putting their data in and heavily pound it for testing efforts.

With different types of storage, MinIO enables me to create these storage volumes called buckets, this is an S3 type cloud storage, I can attach these cloud buckets to different types of storage and actually create levels, or tiering of options of storage levels. If you were using Dropbox, I can attach a cloud storage volume to that Dropbox and it can be publicly shared as opposed to you having to do a file sync and share with basic storage.

The container installation features are good. The S3 feature provisions the storage buckets making it easy. It allows me to spin up the public buckets with open-source technology.

Another valuable feature of MinIO is Erasure Coding which is comparable to enterprise-based systems.

The MinIO dashboard is minimal as there are only a couple of features inside the dashboard for a basic user. I would like this to be more robust with more click-around features.

It is important that MinIO continues to increase its performance. With the increased scaling of specific research coding and the specific throughput the features currently work well, however they need to continue to maintain that community.

The stability of MinIO is great. It is a software defined storage that will manage everything well if everything is configured and setup correctly.

MinIO is very easy to scale as it is scale-out architecture. If I need more performance, more memory, or more discs I can add another virtual machine and it attaches to it nicely. 

MinIO is open source software. It is community based so its developed by the community.

I was using Amazon's S3 and nothing really seemed to work as well as this, until MinIO, the product is comparable. The main reason I switched to MinIO was that it is open source.

Deployment of MinIO depends on what you are trying to accomplish. In my case, it is a four-node cluster with a minimum of four servers, and took myself, a senior cluster role, a full day. The biggest complexity is how you configure the storage around this. You can storage attach, which can get complicated making it an intermediate level of deployment.

This solution is maintained in-house however, there are a lot of factors around that. MinIO manages disc failure, so you need to have hot spares of failing hard drives. You also need to maintain your operating system to make sure that the caching is running optimally and that you get your updates and patches on. Within MiniIO, I look at the caching between the discs. Sometimes you can have files that lock and are holding something up on a certain file.

MinIO is open source so it is free.

Hitachi HCP is an option that I compared MinIO against.

Our intention is to rollout MinIO as an enterprise, product offering, to customers. It will be part of a big ecosystem of cloud-based storage. If a company is coming off object storage, or if they were looking at Hitachi HCP be sure that you deploy with your Erasure coding and look into the caching configuration.

As far as functionality and stability on the backend of MinIO I would rate it an 8 out of 10. 

I mainly use MinIO to store and process unstructured data like customer receipts.

The developer support could be better.

I've been using MinIO for two years.

MinIO's stability is pretty much okay.

MinIO is scalable.

We've used the UI interface and community practice and tended to get a response back within a couple of days.

Previously, we had a Hadoop-based database, but the tools and the community service to manage the Hadoop clusters were too expensive.

The initial setup was straightforward as MinIO provided good support documentation and took a couple of days to complete. I would give MinIO a rating of eight out of ten.

We evaluated Cloudian and RedHat.

MinIO's architecture is very simple, but since it doesn't go with any particular hardware, sometimes they rely on outside software. 

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 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. 

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.

Our primary use case of this solution is for the microservices architecture built with .NET Core. I'm a senior software engineer and we are customers of MinIO. 

The solution has provided the company with a super approach in development and testing environments which is what we were looking for. 

The solution has a good interface. We initially used several commands for configuring in the Docker Compose to create the default bucket and to make it public. It was pretty easy to use and fulfilled our requirements. It's quite powerful.

We had some issues with the initial configuration which I think could be improved by working on the documentation. I had to search different sources to get what I needed. 

The MinIO client was hard to automatize, we had to include some scripting on startup of the client container so that the buckets were setup with the read/write permissions and to make it public and accessible

I've been using this solution for two years. 

We haven't had any issues with stability. 

The way we deployed the test environment was to have just one instance for every container so every user was able to run their own test environment and we didn't need to scale. There were somewhere between 20 and 30 users, product owners and testers. The solution didn't require any maintenance. Expanding use will depend on the amount of information they have to store. 

In the test environment we were using Terraform scripts with the commands for the MinIO Client to set up the MinIO, and all the containers were deployed to a Nomad Ecosystem. We used the continuous deployment to deploy and create the test environments with Azure DevOps. There were three back end developers and two DevOps people that helped with deployment but I did most of it, configuring the continuous integration and deployment of the project. 

The most difficult part of the setup was to configure the MinIO Client, because I'm used to working with Windows and the Docker containers were running on a Linux container. I had to figure out the commands, create the bucket and make it public. It took a bit of research and documentation was an issue.

The solution was intended for private cloud, but we also had an on-premise installation which meant we could manually install the MinIO in every computer required. For on-premise installations, we could install MinIO and just change the connection string of the service using that MinIO. I recommend the solution, it's quite simple to implement and is very powerful because if you need to run the storage in your computer it's as simple as having a container of MinIO. 

I rate this solution eight out of 10. 

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.