MySQL Reviews

It's been used as a primary relational database for most applications. It's scalable and could easily be maintained and could be migrated to any Cloud-based Database as a Service solutions which are compatible with MySQL.e.g. AWS RDS MySQL, AWS RDS Aurora, Google SQL. 

It has improved scalability, easy-maintenance. It is open-source and is easy to use. 

MySQL is open-source. There are a lot of open-source communities trying to come up with their own patches, and to come up with their own features, which help MySQL develop faster than traditional databases like Oracle, which is closed source.

The solution is also compatible with a lot of other databases, like Percona, and it's compatible with MariaDB. It's also compatible with a lot of other shared database solutions.

Since MySQL is mostly used as a relational database in a lot of organizations, a lot of other solutions are being merged with MySQL and it's a rather easy process.

Unlike a lot of closed source services, the new features are solely based on customer feedback. The customer feedback of open source is way larger than the closed source application.

The developers of MySQL, which are Oracle MySQL, Percona, and MariaDB, seem to not be focusing much on object-oriented replication. Basically, replication is based on a text level of replication. There is a text level replication in Oracle, that is so similar it can be implemented in MySQL, however, it needs to pull a lot of resources. They have altered their approach for replication. Still, more focus on object-oriented replication would be good. 

They should come up with a better solution than the NDB cluster for better scaling. If they could come up with a better solution for write scaling, apart from the NDB cluster, which is supported by all open source communities, that would be great. Although the NDB cluster, is an open-source tool, it's not widely supported as a solution.

The latest 8.0 version has come up with whole new features. 

I've been working on Relational Database MySQL throughout my career, i.e. for 14 years. This relational database MySQL is evolved from its MyISAM only engine to InnoDB and is now compatible with other database engines too. e.g. NDB, Galera. 

MySQL is reliable. If you are talking about it in terms of relational databases, MySQL is pretty stable. If you want to go ahead with a quite secure database like any PCI database or a customer-related database or even financial data, it's still feasible to migrate to MySQL. 

There are a lot of features provided by Oracle MySQL, Percona, and MariaDB. They all have their own replication cluster. Percona has XtraDB, MariaDB has GaleraDB, Oracle MySQL has its own cluster as well. MySQL replication is common in all three MySQL flavors. MySQL replication is an excellent read-scalable feature, which has also evolved a lot from its earliest versions to the latest 8.0 version.

The NDB cluster, which has been supported and developed by Oracle, and is based on MySQL, is different than all of the other MySQL replication cluster solutions. It's both read and write scalable. All other cluster features work well for read scaling. NDB cluster is the only cluster feature recorded by Oracle MySQL, which is write scalable as well as re-scalable.

The solution seems to have plenty of technical support due to the fact that there are three companies who are product owners, and therefore there are three companies who are supporting MySQL. They are: Oracle, Percona, and MariaDB. They're doing pretty well. 

There are a lot of companies also that support their customers. This is the good thing about any software which is open-source. A lot of open source communities come up with their own features and they try to patch up with the original source. 

The initial setup has evolved a lot. It's pretty straight forward whether you're using Mac, Windows, Linux, etc. You can set it up on almost every operating system. 

It's supported by the open-source community, and they have plenty of documentation online that users can reference for assistance. If you are working in almost any operating system and you have any questions related to the installation, you'll find the documentation you need.

I am not sure, what the licensing costs are for the solution. From my experience, there is no straightforward cost. You can get that cost from the Oracle website about the Oracle MySQL licensing costs, however, it's not a straightforward price quote for everyone.

If you are an existing customer, you can negotiate and you can get a better quote. The pricing on the website may be for new customers. That said, you can still negotiate. The same is true for Percona and MariaDB as well. 

We are using MySQL 5.6, 5.7, and MySQL 8.0. 

In terms of advice, I'd say when implementing MySQL, if a company has been using any previous relational database, like Oracle, Microsoft SQL or DB2, the easiest way to migrate from any database is from Oracle to MySQL. There'll be some challenges from Microsoft SQL, as well as from DB2 to MySQL. Any existing application which is working with the Oracle database as a backend database, DB2 database as a backend database, or Microsoft as the backend database, should still work fine with MySQL, with minimal code changes. 

MySQL is a product supported by a lot of applications and a lot of organizations. Almost every client and every API would be able to support MySQL. There would still need to be a lot of testing, however, I feel almost all of the applications which need a relational database for their database solution, could leverage out of MySQL. 

We are using MySQL for backend operations since we are a software backend developer. We are using this tool in our backend application for acquiring the data.

We mainly use MySQL for our Relational Database Management System(RDBMS). We are maintaining our customer data in a defined way. We have to create various schema levels. We are presenting the customer data, such as name, mobile number, what was purchased, and what they like or dislike. Once we create the schema, a set of data, we need to maintain the unique constraints.

For example, for customers, we'll assign a unique ID to each record, that will be a primary key. All these SQL constraints we'll use and there should no variance or replication of data isolated. When we perform any update operations, it should not affect any of the data isolated. 

We need to take care of many things, such as consistency, isolation, and variability for constructing any database. There are a few more concepts as well, such as normalization and PL/SQL. For example, if I want to run a job at a particular time, the product will use PL/SQL. We are like implementing our coding skills to databases.

Our operations are on-premise. However, we are in the process of moving everything to the cloud.

We have many repositories in one table that we are completing for customers' data that are store product data. There are various pieces of data and data should be in the same format. For this purpose, we are using RDBMS. The data in the repository should be able to be accessed in one place which is Oracle SQL Developer. MySQL can store data for a longer duration as compared to other data solutions, such as MariaDB, which can only store data for one day. MySQL can store data for a longer period of time, and we can have primary and secondary data as well for backup purposes.

MySQL is easy to use, has fast performance, and it is comfortable for end-user to use. The schema level and structure we are using are very simple and easy to understand. Additionally, packaging tool development is straightforward and the data is presented in a way that is very simple to understand.

MySQL can improve some of its functions. However, it is dependent on the use case. For example, if we are having multiple database connections in this tool, and we are performing one operation in one database, it takes a lot of time due to the reason we are selecting and processing the data. When we have a lot of data it takes a longer time. The transaction gets stuck in a queue and if we try to stop that particular transaction, it won't abort until all the selected records have been processed. This sometimes can be a lot of time and it can hold up our live processing of transactions. This product should be able to handle multiple processing at a time.

In an upcoming release, there should be something added similar to EPL. For example, when using the flow diagram, we can create a schema. We have two useful features to add or create the table, but there should be some UI features to allow us to drag and drop to create other schemas. This would be very helpful.

I have been using MySQL for approximately four years.

I have found the development tools to be highly stable in MySQL.

The scalability of MySQL is very good. There are no barriers to it. It can be used and accommodated in any particular language. We can use it with Java and Python.

We have almost everyone in my organization using the solution. We have developers and support teams all using it. If my organization has 1,000 people, almost 900 people out of them were using the service.

I have evaluated MariaDB.

We use a solution called Jenkins to help us with all the pipelines. The pipelines are all created and configured in the Jenkins. We are in a distributed server architecture and the full process can take approximately 20 minutes for one server.

If we have a large amount of data we have to take care of it. If this particular data is not used over the years, we have to make maintenance decisions on it after we use it. The developer administrator and the team will be responsible.

We are using the licensed version of MySQL.

I would advise others that this is a useful tool.

I rate MySQL an eight out of ten.

I use MySQL as middleware to get the extracted data from the database. I work with MySQL as an administrator to set up the whole platform. And I document the recipe for setting up the MySQL database.

We are working with the latest version.

SQL is just a relational database. It is open source. It's pretty good. I have been using it for a long time.

Because I am the middleware guy I'm not the SQL database administrator. If I have any issue with it, I'm going to contact the right person. Sometimes, not because the version is not the latest version, there are some issues with it. Sometimes there's an issue with the server which creates issues with it. Then, when the administrator checks the status and makes notes, it works normally and the problem is fixed. With a big company you are not going to work directly with the MySQL database. We are the end user and not the administrator of the SQL database.

For MySQL, in terms of the usage or as the end user, I don't have much to recommend, as long as the query latency meets your requirements, it will be great. Otherwise, it's the horizontal scalability and you get more parallel in the implementation in terms of the SQL database regardless of the usage. This is probably much better than the vertical in terms of scalability.

I have been using MySQL this year.

If you are working in the cloud platform then you do have scalability because the cloud platform is usually AWS or GCP, and they provide this kind of scalability. If you get some issues with the query and latency or something like this, that is an issue of scalability and you can just adjust the horizontal or vertical scalability to meet your requirements.

But the company I was working with was a very big company. It's more than several thousand people and they usually have a lot of data that they are going to store in the MySQL database. They gather the data from the SQL database and then transfer it like ETL and you get data from all the different distributed systems and then put them into the centralized MySQL database. After that you're going to visualize this kind of data so that you can use the Power BI or that kind of tool to generate reports or to create a dashboard for the system. This company had its platform on-premises, but right now they are moving these technologies to cloud. That's why I'm talking about the scalability in two different ways cloud and on-prem.

For technical support, I'm the end user so I extract data or visualize the data from the SQL database. I didn't get too into the daily maintenance of the database.

The initial setup for the SQL database is not complex and it even integrates into the platform. You set up the recipe and then just follow the build book. Then it works as long as you follow the procedures.

Regarding the price, because it's the open source they have different licenses. Even for open source there's a license for the enterprise. I don't think it is expensive. Also for the scalability in the cloud, the price is based on the usage, such as, how much data you transfer.

For the best usage right now, the trend is to move the platform from on-premise to cloud. Then, you you really have the best flexibility to scale down or scale up based on your usage. You can make full use of the resources and then pay for whatever you use. Because if you have it on-premise you always pay the same price no matter how much usage you have. So one of my suggestions is if you plan to set up the platform for MySQL, it would be best to go directly to the cloud solution.

On a scale of one to ten, in terms of the usage for the middleware team and the end user of the SQL database, I would say it's around an eight at least. I cannot say from a  database administration perspective.

To determine what would allow me to give it a 10, I would first have to get more experience using it on the cloud version.

Mostly, we're using it as a database behind a machine learning application.

For starters, it's free, which is always nice, and it's also pretty straightforward to use. It's a nice conventional database. We don't need the sort of flexibility that you get with most SQL databases and stuff like that, so we are happy with a good old-fashioned relational database. It's totally good for that.

It works. It's reliable. We haven't done any configuration management for probably about two years, but as far as I remember, that was pretty straightforward as well. It's doing what it needs to do as far as we're concerned.

The workbench could be improved. In particular, error messages can be improved, which are horrific and completely unhelpful. I'd like to see improved parsing of errors. When you write SQL and it crashes, it usually is something completely irrelevant and not helpful. I've started to use GPT 3.5 for finding out how to do things. I got to do something a bit different, and that I found to be very useful. If there was some way to tie it into one of the new AI tools, that would probably be a good idea. There were a couple of things that I've found difficult to do in the past, and I remember they were fiddly. I set them into ChatGPT, which is GPT 3.5, and it gave first-class answers.

I find it clunky. It just doesn't feel very modern. It feels as if you have to go through multiple steps to get to places, and it's not clear, but operationally, I find it fine.

I've been using this solution for about five years.

It's reliable. I never lost any data, which you anyways shouldn't. I'd rate it a ten out of ten in terms of stability because we never had the slightest problem. We are not in a challenging environment, but I haven't had any problems.

We've had absolutely no limitations. However, we haven't got enormous data. It's not very vast, so scalability hasn't been an issue. At our level, it's not even a question. It's absolutely perfect. I'd rate it an eight out of ten in terms of scalability, which I describe as very good

I've never contacted them, but technical support within the environment itself isn't good. I'd rate it a three out of ten, but now if I can use my own technical support with GPT 3.5, it comes up to about an eight out of ten. It's a kind of hybrid support.

We weren't using a similar solution previously. We would prototype from things like Excel or straight-off .TXT files. I had some experience and so did my business partner, and we just decided this looked like the right answer.

That was pretty straightforward as I remember. It was a while ago now, but I don't remember any difficulties at all. I'd rate it a nine out of ten in terms of the ease of setup. 

It's free.

We did look at MongoDB, but it wasn't what we needed, so we decided we go with something a little more conventionally established, and MySQL absolutely fitted the bill. We didn't need anything else. We got some colleagues who used Oracle, but it's expensive and quite difficult to use. 

If you don't have any unusual requirements or absolutely vast databases, it's ideal. We certainly have no problems at all. It just works.

Overall, I'd rate it a nine out of ten. Nothing is perfect, but it's as good as we could have asked for.

We use the product for database management, as a database engine.

We use it for different projects, mainly when we have lots of data and the customer can't afford to pay the license of SQL Server, which is not a cheap one.

That's the main reason you use MySQL or Postgres or other databases. It's less expensive. 

The solution is stable.

The scalability is very good.

It's a mature solution that's been around for decades.

It is very easy to set up the product.

The support in MySQL is horrible.

It isn't as reliable as an SQL Server.

I don't see MySQL being improved at all, like in the last 10 years. It has been at the same level for a long time.

Its stability is quite good. There are no bugs or glitches. it doesn't crash or freeze. 

The solution is scalable, however, sometimes you might have issues. You need to have the knowledge to make sure that you can scale. That said, there are a lot of used MySQL implementations all around the world, which shows that it's a proven product. It has been there for more than 20 years or so.

The support is not ideal. It could be better. It runs under Oracle, and Oracle support is not the best company when it comes to supporting - especially since MySQL used to be a free, open-source solution, and remains free. Oracle doesn't have this approach in its DNA. It's an enterprise and they're not into open-source ways of working. That's why sometimes we move from MySQL to Postgres, which is similar yet has the support in the community.

I've also used Postgre and SQL Server.

This product is not as solid as SQL Server. It's not like it's a lesser quality thing, however, it's not as reliable as SQL Server. The engine is a whole different engine. SQL Server is a full-featured database engine, and MySQL is based on what we call a file-based database. It's like flat files as a database engine, so it's an underdog, if you can call it that, when it comes to database engines. That said, it works fine.

The initial setup is not that complex. It's simple and straightforward for the most part.

The solution is open-source. We don't pay for it.

There are options to get professional support from Oracle and, for that, the pricing really comes up, therefore, it's not competitive anymore. For that reason, it might be even wiser to get Oracle Database than get MySQL and pay for the premium support.

We are just end-users. However, we are happy to work with them.

With Microsoft, we are a customer, partner, and vendor. We aren't partners with Oracle. 

I would rate the solution at a six out of ten.

They just need to assign a great team to MySQL, basically, and Oracle should just leave them alone to improve the product as the product hasn't been improved in the last 10 years. Since Oracle acquired it, it has been in decline. They need to do a lot, not in terms of features. In terms of the mindset.

I would recommend Postgres which is similar to MySQL, over this product. Even the clients are coming to us with such requests. They will flat-out tell us: "we hear that MySQL is having issues and we don't want to deal with Oracle and all that kind of stuff, so let's use Postgres." It's easy to migrate over. It's almost seamless, which makes it a very attractive option.

MySQL can handle multiple rules of a database within seconds and extract required information for the business case, especially with well-optimized queries.

There should be an arrangement for end-users to get trained to use the tool. End-users don't know many things which MySQL offers to its users. So, there is a need for the end-users to upgrade themselves. Also, the tool is already good the way it is currently owing to its features like multithreading which helps with the queries quickly. In short, if one goes for the complex part, if one uses it for a very specialized case, then that person needs to write a very complex query involving multiple tables, multiple joints, and multiple conditions based on whatever scenario one uses.

Improvement-wise, a graphical interface could be added for new users, eliminating the need to memorize the complex syntax.

I have used MySQL for five and a half years in my company, but I have used the tool for around ten years.

MySQL is a stable tool. Stability-wise, I rate the solution a nine out of ten.

MySQL is a scalable tool. Scalability-wise, I rate the solution a nine out of ten. My whole company directly or indirectly uses the tool since we are involved in analytics. My company is an enterprise-sized one.

The solution's technical support is good. I rate the technical support a nine out of ten.

Positive

Since everyone in the industry we are a part of uses MySQL servers, we have also used the same.

The solution's initial setup depends upon the use cases. If you're using it for a simple thing, it's a simple process. But, my problems and statements are quite complex, and I use them to get information, like how the customers perform based on cohort analysis. Also, my use cases are complex, so I have to write complex queries. Overall, the setup process depends upon the scenario.

The installation process is not difficult since it gets pre-installed in all the machines after it is done once. Since the installation process is neither very easy nor difficult, I can rate it somewhere around seven out of ten.

The IT Department handled the deployment process in my current company. Based on my experience deploying the solution in my previous company, its deployment was not difficult. Since everything was already deployed in my current company, we are using the tool as front-end users. When planning to start using the solution, we need to launch SQL server before using it. Also, based on whatever datasets are there, we need to get the permissions for those data sets, after which we are good to go.

MySQL requires maintenance, while the IT department handles the maintenance of SQL server. I am not involved in managing the upgrading part of the tool. Every year, MySQL keeps releasing new versions with new functionalities.

My suggestion to those planning to use the solution is to learn about it and utilize it for their specific scenarios. It is a powerful tool that can perform multiple analyses and reveal hidden insights within multi-million or billion-row datasets that may not be immediately visible to the human eye. The tool also offers many use cases for machine learning. I encourage users to plan and explore the tool to discover its full potential. I rate the overall product a nine out of ten.

We use MySQL for customer management authentication in our company.

The use of MySQL is really dictated by the software we use. So we have put software that dictates the use of MySQL and MongoDB. We think we've found the goal of the company related to strengthening its business systems.

Since we started the development, like, three years ago, it's just been improving, so there are no areas that need to improve. It is easy to use.

The licensing cost of the solution is expensive, which MySQL needs to consider improving.

I have been using MySQL for three years. It's based on the call systems or based on the console.

I rate the solution's stability a ten out of ten since it has been running flawlessly.

It works well. So, I rate its scalability a ten out of ten. Our company is managing hundreds to thousands of clients, but we use MySQL for different projects. So, around 50 users work on it.

In terms of increasing the solution's usage, I think we've done enough, like, stabilizing MySQL.

Our company has contacted the technical support of MySQL. It was very easy to get connected to them. However, it cost us a fortune. For SMBs in South Africa, a thousand or ten thousand dollars an hour is a lot of money. It was expensive, but it was worth it.

We have previously used a solution for location and mapping-related stuff. Our choice to move to MySQL was dictated by software. So, we use different programs for applications.

The initial setup is straightforward. The deployment process takes a few seconds.

We had to seek the help of some consultants to implement the product since there was some difficult stuff. But that was long ago. Nowadays, we avoid seeking help from consultants since it has become pretty simple. So, better experienced and well-trained people would do it for us. It's not a problem.

I believe we have a few cluster solutions. I think that MySQL is a premium product. But I don't manage that part.

The solution's documentation and support are awesome. Also, its speed has increased in the last few years. So, we have never had any issues with it. If there were any errors, then they were human errors.

Today with many other options, we stick with MySQL and recommend it to others. There are so many other things that are more suitable for different purposes, and I will have to do research to know more about them. MySQL has been around for a decade, so something cannot go wrong. Its big support communities make it easy to resolve problems since there is always somebody who can help.

I rate the solution a ten out of ten.

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.