MySQL Reviews

I use MySQL for database-related things. In my company, the main use is for storing and managing business-critical data related to payment, refund, booking, user transactions, and service metadata. Since these systems require strong consistency and reliable transactions, MySQL has been a good fit. I have worked with MySQL for designing database schemas and relationships, writing and optimizing SQL queries, and creating indexes to improve query performance.

MySQL serves as a source of truth for refund transactions and their state transitions. We maintain transaction records, refund metadata, processing status, timestamps, and reconciliation information in relational tables. The key challenge was handling high transaction volume while ensuring consistency. We use proper indexing on frequently queried columns such as transaction ID, refund ID, and status fields to keep lookups efficient.

My experience with MySQL has been mainly around transactional systems rather than AI-specific features. From a governance and security perspective, one of MySQL's strengths is its mature access control and data management capabilities. Features such as role-based permissions, authentication mechanisms, auditing, encryption support, and backup recovery processes help organizations manage sensitive data. For AI-related workloads, governance is especially important because AI systems are only as trustworthy as the data they use. MySQL provides a strong foundation for managing data quality, access control, and compliance requirements.

In my organization, MySQL is deployed on cloud-based infrastructure. It is a part of the cloud-based infrastructure that supports our backend microservices and transaction systems.

The best features offered by MySQL include ACID properties. For MySQL, ACID transactions and data consistency are important. For our system with cases involving payments, refunds, and bookings, we had to maintain accurate transaction state. There is also performance and maturity; MySQL is a very mature database with proven performance characteristics. Relational modeling makes it easy to represent business entities and relationships while maintaining data integrity through constraints and normalization.

Out of the features, the one I find myself using most day-to-day is in systems involving payments, such as refunds and bookings, where maintaining an accurate state is critical. When multiple updates happen across related tables, transactions help ensure that either all changes succeeded together or none of them do. This greatly reduces the risk of data inconsistency. The other feature I use frequently is query optimization through indexing and SQL capabilities. A lot of backend performance data was fixed using that. MySQL stands out compared to many NoSQL solutions with its combination of strong consistency, mature relational modeling, and a powerful query language.

One of the features is reliability and predictability at scale. In MySQL, the behavior is very well understood. There are established best practices for schema design, indexing, replication, backups, and performance tuning, which make it easier to operate at a production-level scale. One of the more useful features is replication support. It allows read-heavy workloads to be distributed across replicas while keeping the primary focused only on writes. This can be very useful as our application grows.

We were able to support growing transaction volumes. I cannot share exact internal numbers, but I can talk about improvements that we observed. As transaction volume grew, a lot of work was around query optimization, indexing, and reducing unnecessary database load. For example, we reviewed slow queries, added indexes on frequently searched fields such as transaction ID and the status column, and optimized join and filtering conditions. The bigger improvements we noticed were faster response times for high-traffic APIs, reduced execution time for reconciliation and reporting queries, better handling of peak transaction volumes, and lower database load during heavy processing periods.

Regarding MySQL improvements, a pain point is horizontal scalability. MySQL scales very well vertically and can support read replicas, but as a system grows significantly, sharding and distributed data management can become complex compared to databases that are designed to scale horizontally from the beginning. This is one of the areas where I think MySQL should work more.

Another area is handling very large analytic workloads. MySQL is excellent for transactional systems, but for large-scale analytics or reporting, specialized analytic databases may sometimes be a better fit. Apart from that, one area is performance troubleshooting. As the database grows, diagnosing things such as slow queries, lock contention, and deadlocks becomes complex.

I have been using MySQL for all four years.

MySQL is highly stable. I have used it for business-critical systems involving payments and refunds, and it performed very well.

Regarding MySQL's scalability, we can easily scale it vertically. MySQL performs very well by optimizing additional CPU, memory, and storage resources. For read-heavy workloads, MySQL supports replication. Overall, I would say MySQL scales very well for enterprise transaction systems.

Personally, I have not had much direct interaction with official support for MySQL because most of the issues I encountered were resolved through internal expertise, documentation, or community resources. However, the documentation, community, and available expertise around MySQL are among the strongest I have worked with.

Before MySQL, we tried other solutions. The choice of MySQL was due to the requirement for strong transactional consistency, relational data modeling, mature tooling, and reliability. I was involved in the migration from other database platforms to MySQL. In some systems, we also use complementary technologies such as Kafka for streaming events, but MySQL remained the system of record for transactional data.

I can tell you about some positive return on investment for using MySQL. The biggest return comes from reliability, developer productivity, and lower operational risk. Because MySQL is mature and widely used, teams can build features faster, onboard engineers more easily, and resolve issues more quickly compared to less familiar technologies.

I was not directly involved in the payment aspect. Overall it was positive from a cost perspective. MySQL has generally been cost-effective due to its open-source ecosystem, mature tooling, and relatively low barrier to adoption compared to many commercial database solutions.

I was not personally involved in the original database selection process. The kinds of alternatives that are commonly evaluated alongside MySQL include relational databases such as PostgreSQL or Oracle, or sometimes NoSQL, depending on the use case.

The advice I would give to others who want to use MySQL is to first design your schema carefully from the beginning. Second, invest in indexing and query optimization early. Monitor proactively and plan for future scale. Finally, understand the transaction and consistency model well.

MySQL is a great tool for using in data-consistent applications. It is a highly mature, reliable, and practical database. Its consistency, ecosystem, and proven track record make it an excellent choice for transactional and business-critical applications. I would rate this product an 8 out of 10.

My opinion on MySQL is that it is the second most popular database after Oracle, and we are using MySQL for several of our customers. So far, my experience with MySQL is very good for organizations that consider database security and availability as priorities. These features are already available with MySQL. Security is inbuilt with the database, and clusters are also possible using MySQL. Availability and sharding features are present, which is why this is a larger database.

I think its replication capabilities are very good.

MySQL has helped my customers' database management by providing better RTO and RPO. The RPO can be less, RTO can be less, using this replication software. It's an inbuilt feature of the database itself, and you don't have to purchase an additional license for the replication.

Regarding their documentation and interface, there is room for improvement. Documentation is definitely required when running multiple databases on a cluster system. The load balancer, MySQL LB, which is used to connect to the application, lacks clear documentation. When there are multiple application servers connecting to the MySQL cluster and going through the MySQL load balancer, the documentation is not user-friendly. It's there, but only technical persons with deep knowledge of the MySQL database can implement it. Most of the community users or ISVs who use MySQL don't have many technical persons or DBA experts, so they face some challenges for the high availability of connecting high available databases from high available applications. That documentation should be simplified.

When we talk about their performance, I never hear from any of my customers about bugs, problems with stability, or updates.

I would rate the technical support for MySQL as very limited since normally everything is available on the blog post. I have never reached out to the support team or Oracle support team for MySQL-related support, so I cannot comment on this.

Neutral

In my opinion, this is not a pretty expensive tool. It is reasonable because it does not base on different components. Oracle has different components, so if you need security, you have to procure a different license, but here everything is inbuilt and it's not costly.

From their competitors, they could learn from PostgreSQL. Recently there was a discussion where a customer was planning MySQL to PostgreSQL migrations, but finally, they decided to stop moving out from MySQL because of benefits such as sharding features, availability, and clusters. These are not apple-to-apple comparisons between both products. There are some other similar options such as MariaDB, but it's not that popular. Though the base is the same for MySQL and MariaDB, it is not as widely used.

I would assess the value of ACID compliant transactions in MySQL as good, pretty good.

When it comes to spatial extensions, I haven't used spatial extensions for MySQL database, so I cannot comment at this stage.

It's difficult to say how many user transactions MySQL handles for my customers who have applications. I don't have that figure at this stage, but I know big organizations are using MySQL where up to 10 to 20,000 transactions per five to six hours are processed.

The main weaknesses of MySQL depend on the context. For critical workload and financial transactions, customers don't use MySQL; they use Oracle. Talking about our customers, I don't get any complaints that they are facing challenges with MySQL that make them want to move to other databases.

There is no problem with their marketing strategy, as they have been very active for the last two to three years. Initially when Oracle took over this database, there was no dedicated team. Now there is a dedicated team, and they are doing very well with their marketing strategy for MySQL.

Their implementation is very easy.

I believe they have all the features which the segment of customers using this database requires. All the features are available, and MySQL is releasing new features regularly, such as enhancing the security postures. I don't think any new features are required at this stage.

I rate MySQL a nine out of 10, and there is no limit to what they could do to make it even better. Whatever performance or new features you're going to add, somebody else will ask for different features.

I used MySQL mostly for college projects. I have used Postgres, but for the use case that I utilized it for, I do not think it was interchangeable with MySQL. To be frank, I do not really know the nuances.

The best features with MySQL are the fact that it is open source and a relational database. The best part about using MySQL was that it was open source, so it was pretty easy to understand and get materials to learn.

MySQL has good documentation and online support. It is pretty good in terms of integrations, continuous integrations with different tools, and customization options.

MySQL was not scaled up, so I did not use the replication capabilities. I do not think MySQL's data security features were at an industrial level for my project, so I did not make use of them. I was mostly using indexes.

I would advise people thinking about using MySQL to look up if the indexing mechanism is useful for their needs and then accordingly select the right database, and also consider if relational databases make sense for their use case. MySQL uses B-trees, so indexing could not be relevant to some use cases.

I did not use any ACID compliant transactions with MySQL.

From my experience, MySQL was pretty stable.

I know MySQL has been used in industries by a lot of companies, which means that it is scalable. That is the extent of my knowledge. It should be good because MySQL has been used by industries. I know Facebook uses it.

I would rate the documentation and online support a 10 out of 10.

Positive

I do not deal with Oracle products anymore. That was just a one-time thing that I had for college.

Unfortunately, I do not deal with AWS, Google products, or Azure products because they are usually paid.

MySQL is a very useful database which is used by a lot of companies, so it should be really good. I mostly dealt with MySQL in the last 12 months. My experience with MySQL overall was pretty good. I would rate this review a 10 out of 10.

In my current role as a software developer, we are using MySQL in one of our old projects and in the new project as well, specifically for storing the device data from energy meters that send voltage, current, and other related information.

Basically, in our project, we have some APIs that our device calls. Once the data is received by the API server, we put it in BullMQ, and from BullMQ, we have set up the consumer that consumes the data and puts it in MySQL. Over MySQL, we built a dashboard to show the energy trend, users, and load averages both device-wise and in groups based on averages. We have created an analytics dashboard for the energy meters using MySQL.

In my work, we use materialized views by running a cron job over the server, utilizing it in two ways: one is from the application server that inserts data into another table for analysis, and the second is for making materialized views where we aggregate data such as daily averages for devices and groups of devices. Inside those views, we store group-wise metrics such as average current, average voltage, peak load, and average kilowatt usage per hour. We also present these views on our dashboard, providing users the flexibility to select devices and create views for real-time rendering.

We use Tata Communications as our cloud provider for this hybrid cloud deployment.

We have used MySQL from the start, as we had experience with it, and it is straightforward to set up and easy to manage with fewer people.

One of the best features MySQL offers is the materialized view that I use. Additionally, as it acts as a transactional database, its transactional properties are useful, although they are not much of a concern in our use case since we focus on device data.

The main feature we utilize in MySQL is the view, and I can say that it is the most valuable feature for our needs.

My organization has experienced positive impacts from MySQL, as it provides exceptional capabilities.

MySQL can be improved. While I do not see any significant improvements needed for MySQL in my use cases, I would consider it if any arise in the future.

I have been using MySQL in the industry for two and a half years, and I used it for approximately three years during my college time.

MySQL is stable.

MySQL's scalability is currently adequate, as we have increased operations from ten thousand to twelve thousand devices, and it is working fine for us, but we will monitor for any future issues.

We have not needed to reach out for MySQL's customer support, as the community provides solutions for any issues we face.

I have evaluated other options such as PostgreSQL, as it is better for analytics queries, but its primary and secondary index concept makes updates slower compared to MySQL, which leads us to use MySQL.

The initial setup for MySQL is straightforward and easy to manage with fewer people.

I have seen a return on investment with MySQL, as it allows us to manage with fewer employees, focusing on business logic rather than database management.

My experience with pricing, setup cost, and licensing for MySQL has been good.

I rate MySQL a nine out of ten. I choose nine out of ten because while there should always be room for improvement, I do not see any necessary adjustments in my use case since it is working fine.

I advise others considering MySQL to start with it if they have small teams and are undecided about which database to use. It is easy to set up and allows you to focus on your business logic initially without going for more complicated databases.

MySQL meets our expectations for our use case so far. We will see what the future holds. My overall rating for MySQL is nine out of ten.

We are using two or three types of databases in our organization, such as Oracle and MySQL. We usually use the MySQL database for the business applications that we develop in-house.

The most valuable feature is the on-premises data encryption facilities. By default, we can provide encryption, and this feature in MySQL is why we prefer it over other databases. The native encryption in MySQL encourages us to use this database model more frequently compared to Oracle and other databases. 

With Oracle, we have to buy another solution for encryption and masking, but MySQL supports native encryption, which enhances our return on investment. It perfectly supports our ROI, and we have no issues with its functionality.

The data masking functionality should be improved as well as the native encryption functionality in the MySQL database. It could be more beneficial if MySQL can enhance its data masking functionality in the same way it has improved data encryption.

I have been using it for around ten years.

We face certain integration issues, especially when we integrate the database with security solutions like IBM QRadar, which affects database performance.

We have a local vendor available here in Pakistan, who provides service. As far as the principal is concerned, we do not directly communicate with them. We have a vendor here, so we have no issues and usually receive timely responses. I would rate customer service nine out of ten.

Positive

We are working with Oracle, and we also use a file database called GT.M.

It is a pretty simple deployment process that can take around two to three hours.

We have a dedicated database administration team responsible for implementation. We have around five to ten people in the team.

We estimate the ROI to be around 40%.

With respect to BAM, database activity monitoring, when we integrate BAM solutions, we face certain integration challenges. These are mainly compatibility issues, like when IBM Guardian is integrated with MySQL for database monitoring. Despite these challenges, the availability of support from IBM helps us to overcome them. 

The product is highly recommended for its compatibility with other platforms like dot net framework. It easily integrates with in-house development functionalities and provides excellent relational database functionality. 

Overall, I give it an eight out of ten.

Right now, I don't work very effectively with the tool. I am more like an architect currently, so I don't have to go deep into MySQL. In my company, we don't use Azure yet. Teamcenter PLM software is set up using Oracle or MySQL. We need to install Oracle or MySQL.

I used the tool for technical things for ten to twelve years. Right now, I have lost touch with how to use it.

The product is cost-effective, less expensive, and much faster, considering the way my company structures the data and the solution handled. The only thing is that if there are 10,000,000 or 20,000,000 records, it will slow down a bit. If the data is less, the performance is good. Once the data keeps on increasing, such as if we work with five terabytes of data and go up to nine terabytes of data, MySQL finds it difficult to handle the data. Huge amounts of data can only be managed by Oracle.

The performance issues in the product can be considered as an area where improvements are required.

I have experience with MySQL.

It is a stable solution. Stability-wise, I rate the solution a nine out of ten. Once the data increases, the tool will face some issues.

Scalability-wise, the product works very well. I rate the solution's scalability an eight out of ten.

My company usually deals with big companies having a minimum of around 2,000 people.

I have not contacted the product's support team since everything is available on the internet.

I used Dropbox when it was initially introduced. I had put so many documents into Dropbox, but I stopped using it. It has been a long time since I have used the product. I had used the product when it was launched, and the tool was giving two GB or three GB for free.

The product's initial setup phase is very easy. I rate the initial setup phase a nine to ten out of ten.

My company uses MySQL's corporate licenses.

In terms of our organization's data management strategy, especially if I talk about PLM software, which is about data management and can be regarded as the core data management of the products that we make. When we are designing something, specifically a new product, it is a critical area, especially considering that I am in the energy sector. In the energy sector, when we are building huge turbines and other things, the data might have intellectual property aspects attached to it. Even within the company, one region cannot see other regions to the extent to which the product offers security. In my company, we use PDM and PLM from Teamcenter effectively.

MySQL is not a tool my company uses in production. When we create some small demos, we use MySQL. For production, we would use only Oracle because it is the most stable tool in the market.

When we install Teamcenter, we don't need to touch the database. We just need to make some references to figure out this is the database, and it automatically creates everything. The basic thing about PDM and PLM systems is that the user should never touch the database because people may corrupt the data model or do anything that will have a very bad impact on the system. Database modifications only have to be made to the PLM system. We are not supposed to interact with the database directly.

The tool is very lightweight, less expensive, and sometimes it is free. It is a very usable tool that is preferred by a lot of people. Only for production use, I may ask people not to use it.

Integration of MySQL is like how we don't directly integrate PLM with Oracle. We have to use PLM's APIs to talk to the database. As a part of the best practices, we should not directly integrate anything with the PLM database. Feature-wise, the integration capabilities of the product are easy to use. It is like any other tool where if there is a table, there is a property. If you want to map a property using any middleware, then we can easily do that.

I recommend the product to others. For medium-sized companies, MySQL is one of the best solutions. Medium-sized companies can choose not to go for Oracle, which is very expensive.

In terms of the value or benefits derived by our company from the use of the product, I would say that it is not very expensive and provides performance along with scalability. The product can cater to the needs of customers ranging from 2,00,000 to 6,00,000 to 10,00,000 records. Even 20,00,000 records are fine, but after that, users may get into trouble. It is the best tool for mid-sized companies with a reasonable amount of data.

I rate the tool an eight out of ten.

Positive

I use MySQL as a metadata database to store information about our product and transactions from other platforms. We extract and store these transactions daily.

I find MySQL's relational data storage format very useful for data management. Our structure is well-defined and easy for end users and business stakeholders to read. I appreciate the tool's simplicity and ability to integrate with our backend tools.

Performance optimization techniques in MySQL are foundational and very useful. Many big database tools are based on their techniques. We use basic optimization methods like indexes and constraints, which should be set up early when designing the database schema. These optimizations are important for us and work well with MySQL.

As for areas that could be improved, the tool is often used as a local database on laptops. But now, we're moving to cloud-based solutions that are more scalable and highly available. I think the tool should offer a cloud database option. This would let users keep a local copy of data if needed, but also have their data available across different regions through a cloud account. 

The product's stability is high. 

I rate the tool's scalability as about six out of ten. It's moderate since it's a relational database, so scalability depends on the data volume we can store. We use MySQL mainly for structured data in its final state. About 1800 people use MySQL in our organization. Around 1200 use it daily, and about 600 developers use it for local databases or small project tasks.

MySQL has been in the market for a long time, and its community keeps growing. As developers, we've gotten full support from them since we started using it. This includes help from their support team and software team and assistance with any technical issues we encounter.

Positive

I'd rate the initial setup as nine out of ten for ease, with ten being the easiest. It's very simple for beginners to set up because the documentation is thorough, and each step is well explained. The deployment usually takes minutes to hours, depending on the data volume we're putting into the database. It typically doesn't take longer than a day.

MySQL has had a moderate impact on our cost efficiency so far. We mainly use it for local development in our internal environments. For production, we use other cloud solutions. However, MySQL's impact on our operational productivity is significant. It's very reliable for all the solutions we're building.

I rate the solution's pricing as four out of ten, where one is cheap, and ten is expensive. For our basic needs, it's quite affordable. However, the cost increases when we need to scale up or require high availability. Our developer team of about 600 people uses MySQL without much issue. The pricing becomes more of a concern on the business side, as we have more end users and need constant database availability and scaling. In those cases, the solution gets a bit more expensive, even though it provides good value for the business.

I rate the overall solution a nine out of ten. 

MySQL was open-source at the beginning until Oracle acquired it in 2010. I started working with MySQL because I was an Oracle expert, having worked for Oracle for eight years. That's why I added MySQL to my skills as an administrator. MySQL is a powerful database engine that is easy to install, manage, and work with. It's ideal for fast application deployment and is cost-effective as well.

MySQL is for metadata and data. My organization has used it to store data about hardware servers and their configurations, including network and storage configurations. MySQL is an RDBMS engine, so it can be used for any business application.

MySQL has a straightforward installation process, is lightweight, and easy to manage. Compared to its competitors, it is more accessible and user-friendly. While competitors like Oracle are known for their extensive features, they are often more complex to install, configure, and maintain, requiring experts to manage them, which can be costly. MySQL, now owned by Oracle, may not have the same feature set as Oracle's flagship database, but it is simple to install, manage, and cost-effective. MySQL is a viable option that can be enhanced with additional features, making it reliable for small to medium-scale applications and capable of effectively handling substantial amounts of data.

MySQL is now in a real application cluster. In terms of high availability, MySQL can be configured for active-active or as a real application cluster.

I have been using MySQL for ten years.

When MySQL is involved in the metadata, it never gets down. It's very stable.

It's secure. MySQL supports large databases that can contain nearly fifty million records. It also supports up to sixty-four indexes per table.

They provide 24/7 support. It provides faster resolution and identification.

Positive

It is very easy to install and takes an hour to complete.

I rate the initial setup a ten out of ten, where one is difficult and ten is easy.

It is open-source and supported by Oracle.

Oracle occupies it, so Oracle added more security features, such as password system improvements, host-based verification, and encryption, to the MySQL engine. It's developed and managed by a big company, and they keep adding new features.

I recommend another solution for large data, like billions of records. However, MySQL is a good option for data up to about fifty million records.

Overall, I rate the solution an eight out of ten.

We use MySQL in multiple projects for storing, task management apps, and dating apps.

MySQL is the best option for the Laravel PHP framework. It supports multiple model systems, and it's very easy to call MySQL compared to other languages like MongoDB. I prefer MySQL for the Laravel PHP framework.

The solution's security features depend on where we host our server and database. We have some preventive measures to reduce attacks. We have taken authentication and only allow a particular IP address.

In MySQL, we need to define every table beforehand.

I have been using MySQL for four to five years.

In MySQL, we need to define every table beforehand. However, we don't need to do so in MongoDB. We can add a new row or column in MongoDB anytime, making it much easier. If you purchase MongoDB's plan, it supports many security features, and you don't need to check about security. They will handle everything.

The solution’s initial setup is very easy. For the first time, the solution's implementation will take some time. However, you can use it multiple times after you configure it.

MySQL is a cheap solution.

Maintaining the database is a task. We take a weekly backup for each database so that we can upload it to the server if anything happens to the data. We created a cron job so that the data can be taken and then uploaded to a specific space so that we can go back to the particular big data whenever we want. I prefer MongoDB for scalability because it's much easier to maintain MongoDB.

Just one person is enough to maintain the solution. The solution has good documentation available on Google.

Overall, I rate the solution six and a half out of ten.