MySQL Reviews

We use MySQL to manage business intelligence reports by linking them with Oracle database and Power BI. 

I like MySQL's feature that helps to automate things. 

The solution is expensive. 

I have been using the product for five years. 

I would rate MySQL's stability a ten out of ten. 

My company has two users for the solution. 

We have not contacted support until now. We have an onboarding manual. 

The tool's installation is not complex but you need to have experience to set it up. You need to download the solution and pay for it. The installation can be done within an hour. 

You need to pay upgrade costs every year. 

I would rate MySQL a nine out of ten. 

Our primary use case for this solution is a home database of payments.

The feature I found most valuable is activity performance.

This solution needs to be improved when it comes to working with desktop applications on the developer side.

I have about 15 years of experience with MySQL.

My impression of the stability of this solution is that it is quite good.

My impression of the scalability of this solution is that it is standard. However, scalability depends on enterprise size and legacy product compatibility.

My impression is that their technical support is good.

My impression is that the initial setup is pretty standard. Some parts of it can be difficult. We had a tough time with the administration and database.

Overall, I would rate this solution an eight, on a scale from one to 10, with one being the worst and 10 being the best.

Our organization uses MySQL as an ERP database for transactional and financial systems.

We are completely comfortable with the database’s performance and it is a mature product. My organization was looking for an open-source database for our smaller customers like the community edition. For bigger customers, we can scale into commercial and supported editions.

I would like to improve the solution’s pricing for licenses.

I have been using the solution for two years.

The solution is a very stable product. We have had no reason to be concerned about its stability.

The solution is scalable and it is one of the reasons why we chose the tool. Oracle has the information documented. We have a solution that we sell to the end users. There are about 50-200 users of that solution who may be using it simultaneously. We also have dozens of clients like that.

Our solution’s end-user customers contact us for technical support. We haven’t felt the need to contact Oracle’s customer support.

The technical preparation for our company to migrate from the previous database was about three months. We did our homework and shortlisted three potential solutions. We invested a month’s time to ensure that our solution could operationally run on MySQL. We also built migration capabilities to facilitate migration and rolled out upgrades to our customers. We never had any engineering issues during the implementation process.

We did the deployment in-house. Our company had the in-house skills to do it.

I would rate the solution’s pricing a six out of ten. The solution is not cheap but it’s a fair value. The pricing depends on the use cases of our customers. Some of our customers use the community edition which is license free and a good fit for their use cases. However, we encourage our bigger customers to sign up because of the scalability issues. The paid versions get direct technical support from Oracle.

I would rate the solution an eight out of ten. Our company is a service provider that has designed and built a solution. We sell it to other third parties. We are comfortable with MySQL. The solution being owned by Oracle and its brand positioning influenced a big part of our decision. The solution is very consistent with its peer group and we accept the solution’s range of functionalities.

We are happy with our choice. We evaluated over ten solutions before choosing MySQL. I am sure that we would be making the same decision if we were to do it all over again.

We're on a software development team. We develop applications.

We're currently running version 5.7 of MySQL, and we are going to be upgrading to version 8 this year.

MySQL server currently is in a co-location center. We've got a hosting provider that takes care of that for us. We are looking at moving it into AWS, but that won't happen this year. We do have a smaller MySQL RDS instance in AWS right now, but it is pretty minimal. 

It is free, which is probably its most valuable feature. It is a pretty full-featured relational database. It really does everything we need it to do. 

The availability of tools could be improved in the MySQL open-source platform. They can provide more analytical tools. I haven't had any particularly difficult issues to troubleshoot on MySQL, but in the past, on Microsoft SQL Server, I had to troubleshoot some difficult issues, and better tools were in place to see what was going on in real-time on the server. So, that's the bit that is lacking on the MySQL open-source platform.

I have been using MySQL for seven years in my current company, and I have probably used it for another two or three years in a previous company.

It is very stable.

I haven't dealt with them.

We're using the open-source version right now, which is free. I do see some value in some of the more enterprise functions. We're using the open-source version right now, and I was interested in the MySQL Enterprise version really for the tools that they provide, but we decided not to make the purchase.

There are certain things that it doesn't do as well as SQL Server. There are certain things that you can do to swamp the server, such as it is just not very responsive to more complicated joins and things like that. Unfortunately, you have to try to learn what those things are, but there are certain things like correlated sub-queries and more complicated approaches that it doesn't support, and you can hang the server in doing that. So, even though it has standardized the SQL queries and other things, there are some things that it doesn't perform particularly well, such as more complicated joined scenarios. We join several tables at a time, but we tend to do that on well-known indices, primary keys, and things like that, but if you're doing something more sophisticated than that, it becomes more challenging. These things that I've mentioned are written up by people, and once you learn those things, you develop techniques to work around them. You take different approaches to solve the problem for those things. You have to do that anyway as a developer. You don't just write code and throw it out there on a production server. You certainly need a totally separate test environment and all that.

I would rate MySQL an eight out of 10.

I have been working for 25 to 30 years in this domain, and during this time, I have used various products such as MySQL, SQL Server, and PostgreSQL. Currently, in my product, I am using PostgreSQL, and in some projects, I am using MySQL. We are using the latest version of this solution.

We do projects for various government departments. We have used this solution for the transport department for vehicle registration, driving license, and all such things. We have also used it for port projects, depots, educational counseling projects, school databases, higher education, and health registry. As an organization, we have a lot of use cases of this solution.

It is very easy to install and has all basic database features.

We require more ease of use, scalability, and high availability. These are some of the critical features that we use and look for in a product. It should be easier to manage clusters. Scalability is very important for us because our projects and concurrency requirements are quite big. We also require high availability of the server, application, and other things.

It should also have more performance-based features or enhancements from the performance point of view. When we divide a database, it should be able to handle the queries very fast.

Whenever required, we also take support, but our people are quite experienced. They are able to manage it most of the time.

Its installation is quite easy.

We have our own people who do the deployment. We have various teams for various projects, and the size of the deployment team depends on the project. We have people who basically look after the DB activities, installation, and consolidation.

There is a licensing cost because we are going for a proprietary product. There are some other versions for which there is no licensing cost.

I would recommend this solution depending on the project. If a project requires the kind of features that are available in this solution, I would recommend this solution.

I would rate MySQL an eight out of ten.

We primarily use the solution for the many small applications we use. However, we do not use it with our enterprise-level applications.

The solution is very simple. It's easy to use. That's the most important feature. 

We do have it supported by various programs we run with it.

The replication needs improvement. It's becoming a native cloud product like Oracle DB or Cockroach DB.

We started using MySQL in various products about 10 years ago when it was still an independent community product.

The solution has proven to be quite stable. We haven't experienced any bugs or glitches.

According to our experience, it's not really an enterprise tool that you can easily expand and scale the way you can with, for example, Oracle. It's good for small to medium-sized applications. It is not ideal for very big applications.

We have a data center that uses the application and it isn't very heavy on traffic. It basically runs on its own. We only use it occasionally. It's like a co-operation management system.

We do plan to increase usage, but we plan on looking at different databases. We're in the process of researching how scaling up would work. Chances are, we'll need to move to a different platform.

We've never been in touch with technical support. For us, so far, things have been working perfectly so there hasn't been a need to.

This is the first solution we've used. We don't use any other product. It's very popular with the in-house program, as we advised them to stick with this application.

We've used the solution for ten years and the setup hasn't changed much over time. It is, more or less, simple when you compare it to other databases. 

Deployment takes less than an hour.

It only takes one person to maintain the solution. The individual doesn't have to be an engineer. They just need to be a support person.

We don't need a consultant for the implementation. This is used by someone in our company that uses databases and has an average knowledge of the product. We don't even need a vendor. We can handle setup ourselves at this point. It's not like Oracle or other products that can be quite complicated.

We use the community edition of the solution.

We didn't evaluate anything before choosing this solution. However, there are a few new products coming up that are growing in popularity and we will need to research them. Products like the Cockroach DB, Nuo DB, etc. are on our radar to be evaluated in the future.

The most important thing other potential users need to do is to look at the use cases for this application and to evaluate how it's able to handle heavy loads, etc. Users should evaluate how it handles high-traffic. They'll need to ask themselves: is the solution usable for my applications? 

I'd rate the solution seven out of ten.

We have used the solution to manage database administration and custom attributes.

The solution has all the essential features. We can manipulate bulk data, clean up data, divide it into compartments, and optimize it.

There should be a training platform for the solution without the complexities of owning a server partition in our system.

I rate the solution's stability a ten.

It is a scalable solution. We have 1200 solution users in our organization.

The solution's initial setup was straightforward.

I rate the solution as a ten. I advise others to have durable resources to handle the operations of MySQL systems.

My daily tasks are related to data mining and TBICO Spotfire is one of the products that I use. We are a small group of geologists operating in a niche area who are analyzing geochemical data. Our backend database is MySQL and we use products such as Power BI, Tableau, and Spotfire to display data for the geochemists.

I perform data-related tasks such as data manipulation and creating views, then updating the database afterward, all using SQL queries. As part of this, I'm making entries as needed or corrections to data that has already been processed.

Essentially, I'm doing data mining with SQL queries, although I wouldn't call what I am doing Data Mining exactly, because I already know the data model. I know the geochemistry data in my head, so I already know what I'm looking for when I write an SQL query. We're not doing machine learning or AI at this point, although it may come in the future.

Every now and then, we create dashboards for the geochemists, which cover their needs from the data.

The most valuable component for me is SQL Developer. It is pretty simple to use and I don't have anything really bad to say about it. It supports multiple window displays and all of the connections are available. A lot of people use Toad for this type of work, but I have not myself.

The functionality that I use most often is querying the data model.

I would like to see an autocorrect option, where if you're typing a query and you enter a comma instead of space, or something similar, the ability for it to be able to understand based on your previous scripts would be an advantage. For example, if you were to put a comma between your AND statements then it's not going to work. Maybe a smarter application where, as you're writing queries, similar to the way that grammar and spelling are checked when you type a text message on an iPhone, it could be autocorrected.

I would like to have the ability to cancel a query in SQL Developer. Specifically, I would like to be able to cancel the query should I accidentally write one that's going to loop, or have a JOIN wrong, where you get millions of records joining with millions of records over and over again. The availability to hit cancel so that it doesn't keep running would be helpful because, when such a thing happens, then you have to shut down the whole application and you lose any queries that you might've typed before.

I have been working with MySQL for approximately nine years.

This application is pretty easy to scale.

Within my department, which is technical data management, approximately 75% of the people use MySQL.

I have never had to deal with technical support from Oracle directly. We just raise tickets that go up and show operations, and in turn, they are the ones that deal with Oracle.

I have used several versions of Oracle MySQL including 10, 11, and 12, and I don't really see any difference between them.

MySQL comes pre-installed with our new PCs, so I have never been involved with the initial setup.

On the operations side, based on what I have seen in terms of people putting in tickets for issues, it seems that we have three people who support and maintain MySQL at different levels. I feel that having this number of resources assigned to maintaining a database is wasteful.

I think that a single person can be in charge of maintaining multiple databases.

As a data analyst, I am not in operations and don't have a say in which products we use.

My advice for anybody who is implementing MySQL is to ask around because there are many different ways that you can create a database now. Relational databases are no longer the best way to organize your data. It really depends on what it is that you're doing. For example, you may not need a relational database, but instead just a file structure. So, look at all of your options and speak with the experts to see what kind of database is needed before assuming that you need an RDBMS.

I would rate this solution an eight out of ten.