MySQL Reviews

It dramatically improved use for several of my customers.

This depends on my customers' use.

SQL and NoSQL use.

When configured correctly, no stability issues.

When configured correctly, no scalability issues.

Very good.

MySQL Support Services by Percona. I switched to Oracle MySQL services because of a better ROI.

There is no obvious answer. It depends.

Depends on the customer's needs. 

MariaDB, MySQL Support Services by Percona.

Stick with the source, stick with Oracle MySQL as the leading vendor for MySQL technology.

Due to the open source licensing model, it has allowed small businesses like ours to adopt enterprise-grade database systems without incurring significant licensing costs.

• Open-source
• Multi-platform
• Lightweight
• Simple to set up, configure and tune
• Support for enterprise-grade features like clustering, master-slave replication, even Sharding (to some extent) which is an advanced feature

It would be helpful if there were a graphical user interface to administer, configure, and tune it.

If it had something similar to Microsoft’s DTS engine then it would be the best database system out there.

For the scale at which my systems are operating, the software is stable. We are at most dealing with less than 10 million rows of data across all tables, and concurrent connections under 200 at our peak loads.

No scalability issues at the scale at which my systems are operating. One thing I did encounter with an earlier version of MySQL 5 – the mysql process will not automatically use available CPU cores on the server, even if it was a dual or quad core CPU. I was troubleshooting a scalability issue when I saw this, it maxed out just a single core and left the other three (in my quad core CPU server) idle. There was a specific condition / trigger that will make the mysql process span the other available cores (I can’t recall now but a quick googling likely will uncover this).

We did not subscribe to professional support from MySQL AB or Oracle. However, the wealth of community support is outstanding. Most of the issues faced could be resolved by knowledge shared by the MySQL community.

I’ve used SQL Server and Oracle for database systems. SQL Server is an excellent solution, in particular the DTS (Data Transformation System) which is not available for MySQL. Switching to MySQL for two reasons: 1) licensing costs 2) the application supports MySQL primarily, and has poor support for SQL Server.

Very easy to set up, relatively easy to configure, tune, and use the conf file, as long as you are comfortable mucking around in Linux conf text files and working from the command line (I am).

You could use the installer which would be the easiest way, but setting up by hand is not too difficult either – instructions can be found online and following them step by step usually works fine.

MySQL Enterprise Support is not cheap, though might still be cheaper than Oracle or SQL Server. They may not have local support depending on where you’re based, but there are many smaller agencies out there that will readily provide support. You’ll need to spend some time looking around.

I’d been using other database systems like Microsoft’s SQL Server and Oracle Database before trying out MySQL. There are forks of MySQL maintained outside of Oracle, like MariaDB and Aurora (by Amazon Web Services). I have not really tried them but I don’t expect very big differences; in fact, for most use cases you may not observe any difference. There would be the few unique features in MariaDB and Aurora that are not present in the original MySQL feature set (I know there are but don’t remember the specifics).

As long as your application supports it well, and you are familiar with the scaling options and its limitations, you can’t go very wrong with MySQL, as it is a very mature product by now. If you are fairly competent with servers and databases you could start off without subscribing to Enterprise Support, and may be able to get by quite well. If things get more complicated, or scalability starts to become a problem, then you may consider paying for help.

We use MySQL for enterprise data storage as well as part of the back-end of websites and web applications.

The most valuable feature of MySQL is the informative error outputs of command line interface.

MySQL needs improvements on its diagnostic features.

No issues.

MySQL is not easily scalable on cost effective consumer grade hardware.

I would rate technical support as a 10 out of 10.

Not applicable. No previous solution.

Setup is easy. MySQL of various flavours has community editions to easily test, deploy, and run.

Enterprise editions and support are definitely needed for the heavy users who need direct support. 

No.

One should ensure the availability of proper hardware before any optimization attempt from the software level.

Small to medium-sized business usage. The main advantage is the very large user base. This enables users to fix about any issue by answering any question. From a technical viewpoint, MySQL is on par with the other open source database solutions.

Due to the large user base, a large amount of software modules and plugins for rapid application development are possible. From an operational viewpoint, this is also a very big advantage.

The large user base and the amount of available plugins and modules. A lot of the software components have been trialed and tested for often more than 10 years. It is rock solid from that viewpoint.

It does not stand out regarding scalability. When the company size increases, the user base having actual experience with (very) large MySQL solutions is reduced.

No, it is rock solid.

Yes, other solutions have better features and better performance.

Not applicable.

No.

The initial setup is very easy with very good online support.

Implementation was done in-house.

Not applicable.

When you know the setup will continue to grow, make sure you have the paid support. 

MariaDB/Galera.

Primary DBMS solution for web apps developed on either ASP.NET MVC or Zend / PHP for customers.

The community version of MySQL only offers simple backup and restore tools, but it is OK for many web dev projects for customers that want a low budget solution.

We do software development for our customers on both Windows and Linux. Since these tools are available for both Windows and Linux, we can leverage the knowledge of these tools for development on both platforms.

We design web solutions for customers with PHP (Linux) and ASP.NET MVC (Windows). MySQL offers a simple, no frills, but effective DBMS solution with a very low hardware footprint. Since it has no licensing fees, it offers great TCO for our customers.

Only one of the engines, InnoDB, supports ACID transaction control. The best performance engine, MyISAM, has no transactional control support.

It would make a lot of sense to include one engine that offers both very good overall performance and transactional control support.

All versions of MySQL, including the Community Server version include in its design as a Pluggable Storage Engine Architecture.

This architecture allows for the support of multiple options of Storage Engines, so, a software architect can design a sofware solution with MySQL based on a specific Storage Engine that is capable to cater to a particular type of storage use case requirements, like for instance, web applications with heavy read workloads and moderate write workloads, or intranet desktop applications with heavy write workloads.

Depending on the version of Community Server installed is the list of available Storage Engines: All it takes is the execution of the command SHOW ENGINES to retrieve the list of installed Storage Engine plugins.

When you create any given table in MySQL, you have the option to select what Storage Engine (among the engines available) will be applied to said table. If this option is no explicitly mentioned at the end of the "CREATE TABLE" command, the current default storage engine will be assumed.

For web apps with intensive read workloads and moderate write workloads, the engine that offers a good overall performance is the MyISAM engine, but this does not support ACID transaction control, and it uses a table-level locking mechanism (thus, from a performance standpoint, this is not proper for apps with heavy write workloads).

The InnoDB engine uses a record-level locking mechanism, so, it is proper for apps with heavy write workloads. It also supports Isolation Levels, which is important for applications that have many clients doing read and write operations concurrently.

The other storage engines offer support for very specific use cases, like for instance, flat file tables (CSV engine) or memory-only tables (Memory engine).

Getting back to the InnoDB engine, it offers features that are similar to the database engine in SQL Server, and according to some of benchmarks that we have run, SQL Server Express provides overall better performance than MySQL Community Server with InnoDB tables.

My "Room for Improvement" comment is that it would be great if in the future Oracle were to provide with the Community Server edition a version of InnoDB with better overall performance, while still requiring a small hardware footprint.

As with any good DBMS, MySQL requires periodic DBA maintenance. If you leave a MySQL database with no supervision of a DBA for enough time, files become too fragmented and they may turn corrupt beyond rescue.

The version of the product with free licensing does not offer stellar scalability support. We only use these tools for solutions that do not require such a level of scalability.

The version of the product with free licensing only offers community forum support. Because it is a very popular product, there are many free resources on the internet to search for solutions to most issues.

This kind of "free support" is OK, because we do not use these tools for mission critical solutions.

For Windows development of non-critical solutions, we previously used SQL Server Express exclusively. However, now we use either SQL Server Express or MySQL, depending on the customer. We have not switched from SQL Server Express to MySQL.

The admin tools offered by MySQL Workbench are very good. For an experienced DBA, it is rather easy to setup a (MySQL) server for development, testing, pre-production, or production environments.

Implementation was done with in-house team.

With no licensing fees, the business opportunity is great for both the customer and an ISV like my company. This is the case, as long as you use these tools for non-critical solutions.

We did evaluate other solutions, mainly PostGreSQL, which is also a very good product.

We run a benchmark comparison first, then we run a small lab with the development of a small solution with both toolsets (MySQL and PostGreSQL).

In this development comparison, we found that the winner is MySQL. MySQL toolset for development offers much more coverage for both PHP and C# development.

Most small and medium enterprises require many non-critical solutions. They clearly they do not have large budgets for these kinds of solutions, so it makes a lot of sense to consider MySQL as a good option for this kind of development.

The advice is to make sure that it works for your company and for your customers.

Used as a data store for RESTful web services and other web applications. Was deployed to store RSS feeds, and for 100 joomla instances. 

MySQL is widely supported. We were able to integrate it with several different projects using various different programming languages with no issues.

Worked with Java, Perl, PHP, C# and C code. 

MySQL’s strength is in its fast connection, query and insert performance. I’ve benchmarked MySQL against several NoSQL and SQL databases and found it to be faster for getting lots of data inserted quickly.

The weakest link is replication. MySQL’s replication is touchy and doesn’t support master-to-master setups.

MySQL’s replication was implemented by playing back SQL statements getting executed on the master database node. That means if a slave node gets behind, it has to catch up by running every SQL query that has executed on the master. When the slave gets too far out of date, it is unable to catch up because the replication log is lost. 

Master to master replication is used to allow writes to either node in the cluster (INSERT, UPDATE, DELETE).  Since MySQL does not support this, you can only safely send SELECT queries to slave nodes.  If you run an insert, update or delete against the slave node, then it is out of sync with the master and may break if a later replication event comes from the master on the same table.

I’ve had an issue where an InnoDB database grew too big and got corrupted. I was unable to recover it because there was not enough space on the server either. Be sure to have enough space.

We did encounter some scalability issues as it has limited clustering support, it requires scaling up rather than out to some degree. Of course, you can have read replicas. It also has a fall-off on performance with very high workloads, but it takes awhile to get there.

MySQL has replaced Microsoft SQL Server in several cases. MySQL is easier to manage and much more cost-effective.

The security model is different than the other databases.

There are tuning and monitoring benefits for people who purchase MySQL rather than using the free version.

Looked at Microsoft SQL Server and PostgreSQL. 

The porting code to or from MySQL is not that complicated, but the date type/format and functions are the biggest hurdles. Handling booleans data type is less efficient than the BIT type in the SQL Server.

• Vertical scalabity on hardware
• Better hardware usage
• Access performance
• Addressing consistency, scalability and performance issues

Storage and searching quickly on data is no longer an issue facing us using Excel.

Hardware scalability and parallel treatment can and will be improved in the next few years.

For 15 years now.

No, there are only strategies applied by a data scale interval (less than 200 go, less than 1 to, and more than 15 to).

Always due to architecture, data storage, and data requesting irrelevant strategies.

High. There is a lot of documentation, a lot of expertise, and a lot of projects in the world.

We switched to a different solution because of data access issues, speed, and consistency.

Don't use the license version. Open source is enough.

There are a lot of alternative to paid features. It's very hard to find support for this feature.

You will have a lot of work, but you will also avoid a lot of issues due to product immaturity on the database market.