MySQL Reviews

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.

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.

We use multiple models here because we do full development. What we deploy on MySQL is from the Helm chart or it's a Dockerized deployment of MySQL. So we're using the Helm stable chart right now. That's sort of the easiest way to deploy it - to say just one command and it bootstraps your whole database within your classical means or cluster. You can do it locally with mini-crews or developers, for organizational use, or Kubernetes. It's single-node Kubernetes.

Also, you can just deploy MySQL locally with a Helm chart. Regarding production, we have a kind of automated process which is similar to what Spinnaker deploys, with a Helm chart as well as within the cluster. Some other solutions we don't run within the cluster, we use the Cloud version of the database which is Cloud SQL, Google Cloud, and AWS. Those are fully managed ones, of which there are two versions. We have our self-managed version which we run locally and with our DEV cluster and then there is production, as well.

We also use a self-managed version since every cloud provider offers MySQL, even AWS. It depends on the client's needs, how flexible the client is, and also how comfortable they are with MySQL.

We either go with our managed version or the Cloud version. Both are supported because today the Mica server that's actually accessing the database or the piece of software just needs a connection string, it doesn't care if it's running within the Synchronous Cloud. If it's running somewhere else in the Cloud, it's still a private connection on the same network.

So the only differences here are in terms of money costs and whether it's managed or not managed. So for local development, you don't want to have a managed database in the Cloud. You don't need to be tethered to the Cloud, you'd rather just deploy locally. And because we have the same deployment scripts that run locally in DEV and testing, we use the same Helm chart and the same Docker version with MySQL to distribute that through our DEV environment to test the bills and run the test and there is a full QA environment for teaching, as well.

I treat these products kind of as a throwaway versus what a DBA would be. From an organizational point of view, it's difficult to actually define the most valuable features because we have so many different databases. For some of them, Postgres for example, which uses MySQL, is just personal preference with is no real difference. Unless you get to really high volumes or through-putting. So in our case, because of legacy reasons, we started using MySQL, which was a popular database. It's not a bad database, so there was no reason for us to change it to the Postgres. We do use Postgres right now for other tools, but for a main database for application purposes, we still stick to MySQL. And I think it's just because of legacy, there's no real advantage of one over the other right now.

We built up the scripts already. Because once you start integrating the scripts into your company, your deployment scripts, test scripts, etc. you just leave it over time because it takes effort to change. But in terms of advantages or features, you can go feature by feature with any database and if you add up the totals, there's no real advantage here between Postgres or MySQL.

We use it to meet the requirements of our customers while optimizing performance and reliability within the constraints provided.

The performance and scalability of our project have been influenced positively by MySQL. From what I've observed, performance has been satisfactory, and I haven't received any complaints from teams that have implemented it.

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.

I don't use MySQL extensively, but I use the code within MySQL for preparing some reports and all that.

Code is easy to write and code, it's easy to understand. That's why it's widely used. The queries are very easy to understand and [write the] code. For coding, it's very easy.

I would use MySQL for a medium project, with around 1,00,000 hundred thousand users, because of the indexing and stored procedures.

MySQL's performance needs to be improved for enterprise-level applications compared to Oracle and Postgres. That's the only drawback I found in MySQL. When the table storage is full, the solution's performance becomes slow. The solution's security needs improvement as DB2 is more secure than MySQL.

We are developers working on different types of projects. We use relational databases in some projects and non-relational databases in others. When we use relational databases, we use MySQL. When we use non-relational databases, we use our DynamoDB or MongoDB.

1. Ease of Use: MySQL is relatively easy to set up, configure, and manage, especially with tools like MySQL Workbench and command-line utilities. Its widespread popularity also means there is ample documentation, tutorials, and community support available for users.
2. Open Source and Cost-effective: MySQL is open-source software, which means it is free to use and can be customized according to specific requirements. This makes it a cost-effective choice for startups, small businesses, and projects with budget constraints.