database administrator at a tech services company with 51-200 employees
Real User
Top 20
Apr 9, 2026
While TiDB Cloud is good for high availability, I think there are some bugs when using the TiFlash feature, sometimes in the TiKV component as well. In TiFlash, I have discovered that it is not suitable for high concurrency since increasing the query concurrency causes TiFlash to overload, sometimes resulting in query failures, while TiKV handles concurrency better but is more focused on row-based data for smaller amounts of data. It would be great if these issues in TiFlash with high concurrency are effectively managed. According to user experience, I find TiDB Cloud to be more useful for bigger queries, but I also notice complications occurring at times. When going through the logs, I sometimes find that there are no details regarding errors. I have noticed that while the TiDB documentation lists some error codes to troubleshoot issues, it lacks workarounds or solutions for those error codes, making it not very customer-friendly. I experienced this when I faced an error and could find the error code but not the solution.
TiDB Cloud performance can be improved by enabling and tuning TiFlash. For example, use TiFlash replicas for heavy analytic workloads. This will impact query speed for dashboards and aggregation speed. Proper cluster sizing is important, such as adding more TiKV nodes for high throughput. Optimizing SQL and index optimization, such as removing unused indexes, are other ways. Region and data distribution tuning can also help. Monitoring with Grafana for things such as QPS, latency, and regional hotspots helps catch bottlenecks early, as does monitoring CPU and I/O usage. Utilizing horizontal scaling is also beneficial.
While using TiDB Cloud, I noticed things I don't like as a developer. For instance, it doesn't support functions and procedures, which Oracle and other databases do. This means that for table-to-table operations, like data manipulation and functionality, I need to take that data to the application side, process it manually, and then re-insert it. Oracle and other databases have functions and procedures to handle this within the database itself. This is a key feature that I, as a developer, would like to see in TiDB Cloud. We are implementing our product for a major bank in Malaysia and setting up a disaster recovery environment. The client requires the ability to replicate auto-increment sequences from the production environment to the disaster recovery environment. This is not currently possible. We had a call with TiDB, and they said this feature is not available. They advised us to handle the auto-increment indexes from the application side. This means we are doing most things from the application side, which is a challenge we face with TiDB.
If you are using a product managed by a cloud provider, such as AWS or Google Cloud, you benefit from various management tools. For instance, AWS offers CloudWatch for tracking metrics, while Google Cloud provides Time Series Insights. These tools are managed by the cloud providers. As an end user, you primarily need to pay for the service, and the cloud provider handles most of the management tasks. If you choose to use open-source tools like Prometheus, you will need to manage them yourself. It's a trade-off between convenience and cost. Opting for a managed service means you pay more but have less management overhead. On the other hand, using open-source solutions can reduce costs but requires you to handle the entire management of the infrastructure and database, such as ensuring uptime and provisioning resources. TiDB Cloud offers a reliable, managed solution that ensures availability and performance without the hassle of self-management.
TiDB Cloud offers scalable MySQL compatibility with high availability and hybrid processing capabilities. Its modern infrastructure supports elastic scaling and distributed systems, enhancing cloud-native database management.TiDB Cloud provides horizontal scalability, seamless integration with Prometheus and Grafana, and features automated partitioning and JSON functionality. A reliable option for e-commerce, financial systems, and more, it manages concurrency challenges and supports...
While TiDB Cloud is good for high availability, I think there are some bugs when using the TiFlash feature, sometimes in the TiKV component as well. In TiFlash, I have discovered that it is not suitable for high concurrency since increasing the query concurrency causes TiFlash to overload, sometimes resulting in query failures, while TiKV handles concurrency better but is more focused on row-based data for smaller amounts of data. It would be great if these issues in TiFlash with high concurrency are effectively managed. According to user experience, I find TiDB Cloud to be more useful for bigger queries, but I also notice complications occurring at times. When going through the logs, I sometimes find that there are no details regarding errors. I have noticed that while the TiDB documentation lists some error codes to troubleshoot issues, it lacks workarounds or solutions for those error codes, making it not very customer-friendly. I experienced this when I faced an error and could find the error code but not the solution.
I have not really noticed any areas where TiDB Cloud could be improved or faced any challenges.
TiDB Cloud performance can be improved by enabling and tuning TiFlash. For example, use TiFlash replicas for heavy analytic workloads. This will impact query speed for dashboards and aggregation speed. Proper cluster sizing is important, such as adding more TiKV nodes for high throughput. Optimizing SQL and index optimization, such as removing unused indexes, are other ways. Region and data distribution tuning can also help. Monitoring with Grafana for things such as QPS, latency, and regional hotspots helps catch bottlenecks early, as does monitoring CPU and I/O usage. Utilizing horizontal scaling is also beneficial.
TiDB Cloud can be improved, particularly because the interface is very old. I think it would be helpful to have a new interface.
While using TiDB Cloud, I noticed things I don't like as a developer. For instance, it doesn't support functions and procedures, which Oracle and other databases do. This means that for table-to-table operations, like data manipulation and functionality, I need to take that data to the application side, process it manually, and then re-insert it. Oracle and other databases have functions and procedures to handle this within the database itself. This is a key feature that I, as a developer, would like to see in TiDB Cloud. We are implementing our product for a major bank in Malaysia and setting up a disaster recovery environment. The client requires the ability to replicate auto-increment sequences from the production environment to the disaster recovery environment. This is not currently possible. We had a call with TiDB, and they said this feature is not available. They advised us to handle the auto-increment indexes from the application side. This means we are doing most things from the application side, which is a challenge we face with TiDB.
If you are using a product managed by a cloud provider, such as AWS or Google Cloud, you benefit from various management tools. For instance, AWS offers CloudWatch for tracking metrics, while Google Cloud provides Time Series Insights. These tools are managed by the cloud providers. As an end user, you primarily need to pay for the service, and the cloud provider handles most of the management tasks. If you choose to use open-source tools like Prometheus, you will need to manage them yourself. It's a trade-off between convenience and cost. Opting for a managed service means you pay more but have less management overhead. On the other hand, using open-source solutions can reduce costs but requires you to handle the entire management of the infrastructure and database, such as ensuring uptime and provisioning resources. TiDB Cloud offers a reliable, managed solution that ensures availability and performance without the hassle of self-management.