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.
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.
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.
The tool helps our customers store documents with their respective versions. Our solutions work around loan processing, loan origination, loan management, and collections. During the loan application process, there is a lot of documentation involved which needs to be stored. The product handles the document’s versioning and storing.
Our solutions also have a module that does the video KYC of our customers. MinIO saves the actual recording of the video KYC process. We use the tool to store and retrieve documents and videos with proper versioning.
The tool’s integration is very easy. This feature has helped us reduce development time. The solution also has many out-of-the-box features like versioning support and management of roles and permissions. The product also supports clustered deployment.
The tool’s pricing needs to improve. We also encountered challenges while deploying the tool in Kubernetes. The documentation also was not too great. We have currently deployed the solution in a stand-alone fashion.
We have been using the solution for two and a half years.
The product’s stability is pretty straightforward.
The tool is scalable. It supports clustered deployment which we haven’t used. However, we wrote the documentation and did an internal POC where we deployed it in the test clustered fashion.
We are using the tool’s free version. The free version does not come with any support. However, you can get support from the tool’s strong community. We haven’t run into any issues that require extensive support.
It is difficult to deploy the solution if you involve Kubernetes. The setup is easy otherwise. I believe that it shouldn’t be an issue with the tool’s latest version. The good part is that the tool supports multiple storage technologies
The product has pretty good documentation available on their website which our DevOps team followed and successfully deployed the solution. My team downloaded the binaries from the library, executed them, and made some initial configurations.
The deployment was pretty quick and we were able to complete the process within a couple of days. The Kubernetes part took weeks to complete. You just need a resource with a good understanding of the documentation and experience in Linux technologies to do the deployment. A team of two to three members can complete the deployment in a week’s time.
I would rate the tool an eight out of ten. We use the solution’s community version. My company is the implementer of MinIO and not the end user. We are a fintech company that provides digital lending solutions and digital onboarding solutions to banks and financial initiatives. When we deploy our solutions, we also implement Document Management Systems as part of our solutions. These Document Management Systems use MinIO as the core object storage.
We have not found any issues in the tool’s maintenance. You can get pretty good object storage with the community version. The tool has good capabilities in the enterprise version as well. I would definitely go for MinIO over other technologies.
We use the solution for object storage in our core platform. It works best as a data lake solution for us.
The solution is simple to use and maintain for DevOps executives. Also, it has the best performance compared to other solutions.
The solution's features for distributed non-container applications and reverse proxy could be better.
I have been using the solution for three months.
It is a stable solution. I rate its stability ten out of ten.
It is a scalable solution. It uses consistent patching; thus, it is more scalable than other solutions. Although, we encountered a few scalability-related issues while introducing a new node.
We used Azure solution before. It was challenging to maintain the Kubernetes cluster.
The solution's initial setup was straightforward. We deployed it through Ansible playboards. It took about three days to complete.
We use the solution's open-source version.
I recommend the solution to start-up businesses. It is the best tool in the market if they want a simple and low-maintenance product. Also, it requires DevOps expertise for the smooth functioning of scalability and reverse proxy features.
I rate it eight out of ten.
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.
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.
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.
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.