What is our primary use case?
My main use case for Percona Server was for an e-commerce platform, operating as a webshop. The customer had a migration underway where they wanted to move from a certain service provider to managing things themselves. They previously used MariaDB, which did not work, so we needed to move to MySQL, and Percona has a MySQL derivative that worked for us. The use case also involved running this within a Kubernetes cluster.
A specific example of how Percona Server was used in that e-commerce platform is that the state was managed through the database, and the entire hydration process occurred there as well. We had server-side rendering happening, and the client-side renders were hydrated through whatever lived in Percona Server database, which resulted in a huge amount of read operations. For redundancy and performance reasons, we worked with about three instances of Percona Server running to ensure that we got the read performance we needed. One issue was the contention and locking that occurred during write operations, and this is where I think Percona showcased that their system was better than other MySQL derivatives.
We used Kubernetes installed on VPS in Hetzner for that project, and it was very important for us to have a platform that was MySQL compliant, along with all the CRDs, the custom resource definitions, required to use it properly in Kubernetes. We also needed support in managing the service, so having a specialist to tweak those parameters for good database performance was really good to have.
My experience with the Kubernetes-native features was that getting it into Kubernetes was really easy. It is just a Helm chart that you throw in there, and it kind of works. Of course, Helm charts have many intricacies, so parameterizing it correctly was essential, but it provided an out-of-the-box experience for getting it into our cluster.
A cool thing to call out is that they have an observability dashboard for Grafana to see what is going on, which works seamlessly. It is not just about getting everything in there, but also having visibility into how it works, and we had lots of interesting metrics available to use.
What is most valuable?
Percona Server offers excellent features including its compliance with the MySQL/Maria dialect, which was essential for our existing application. We faced the challenge of deploying it redundantly in a way that ensured the application would work now and in the future, which involved different replication strategies. Additionally, we needed it to be Kubernetes-native with an operator to check if the database was running and to manage redeployments. Percona provided all of that, along with optimization recommendations from a specialist. There were not many alternatives available, and we also wanted to stay on an open-source stack, which Percona supports to keep everything transparent while providing support as well.
Impact of Percona Server on my organization has been positive. The database was a mess and did not run well, and we suffered a loss of revenue in that project. The website needed to work, as it was a legacy system with lots of Java applications depending on it. If that database did not work, the website could not even start up, making it extremely important for the e-commerce side to have a well-functioning database.
After switching to Percona Server, we were able to resolve those issues quickly. The platform originally worked with MariaDB, so we spent about three months refactoring the software to accommodate features that MariaDB does not support or supports differently compared to MySQL dialect. The implementation for Percona Server took less than a month, and we have not encountered issues since then.
What needs improvement?
Percona Server seems great to me overall. If I had to think of any small area for improvement for Percona Server, it would be around the proxy story. When adding a proxy to manage traffic better, we first tried SQL Proxy, but it never really worked for us, which was unfortunate because SQL Proxy offers better optimizations for read performance. We did have success with HAProxy, but it works on a network level, while SQL Proxy was designed to be SQL-aware and distribute parts of the query across the database cluster. The performance gain we were hoping for with SQL Proxy did not materialize, so we remained on the network level with HAProxy.
Databases can be finicky regarding the performance they need. We had some disk I/O latency issues, which led us to use different types of nodes in our Kubernetes cluster where we provisioned Percona Server explicitly. There is a lot of IOPS happening under the hood, and while I suspect the application was not very efficient, it was also challenging to identify that we were experiencing performance issues due to disk performance. It would be helpful to clarify the metrics related to disk I/O latency so we could understand where our bottlenecks are.
For how long have I used the solution?
I used Percona Server in a project for about a year.
What do I think about the stability of the solution?
Percona Server is stable.
What do I think about the scalability of the solution?
Percona Server's scalability is great, which is its core feature.
How are customer service and support?
Percona Server's customer support is excellent with very responsive and friendly service.
Which solution did I use previously and why did I switch?
We initially struggled with getting MariaDB working, which took a team of six people several months. This was time wasted, whereas with Percona Server, once it is up and running, you really have to do very little.
How was the initial setup?
We evaluated different solutions such as MariaDB and MySQL, but we only evaluated them without implementing them. Our experience with MariaDB was that it did not work for us.
What about the implementation team?
My advice for others looking to use Percona Server is that while it is a great product for making things work, it does not eliminate the need for a database administrator. You still need to know what you are doing, and it can alleviate a lot of the pain of running a database. However, it does not equate to a fully managed database, at least in our use case where we run it in our own Kubernetes cluster. That knowledge is also beneficial when working with a consultant for setup and database optimization.
What's my experience with pricing, setup cost, and licensing?
I was involved on the sideline when it comes to pricing, setup cost, and licensing. I think the pricing was good. What I appreciated was that they packaged support with the licenses, ensuring that we ended up with a working database, which is powerful because it shows that they are focused on solving a problem rather than just selling a product.
Which other solutions did I evaluate?
We evaluated different solutions such as MariaDB and MySQL, but we only evaluated them without implementing them. Our experience with MariaDB was that it did not work for us.
What other advice do I have?
My advice for others looking to use Percona Server is that while it is a great product for making things work, it does not eliminate the need for a database administrator. You still need to know what you are doing, and it can alleviate a lot of the pain of running a database. However, it does not equate to a fully managed database, at least in our use case where we run it in our own Kubernetes cluster. That knowledge is also beneficial when working with a consultant for setup and database optimization. If you want to go open-source and are knowledgeable about databases, Percona Server is great and will provide everything you need. But if you are looking for a solution without needing to understand databases, this might be too advanced. I would rate this product an 8 overall.
Which deployment model are you using for this solution?
Public Cloud
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Other