What is the main reason for your technology selection from MySQL to TiDB?

Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: 你们从MySQL到TiDB的技术选型,最主要的原因是什么?

| username: Jellybean

[TiDB Usage Environment] Production Environment / Testing / PoC
[TiDB Version] All

As the title suggests, I would like to know from the community experts, what are your reasons for choosing TiDB?

Is it because the storage capacity of the original standalone database is limited?

Is it because there is a performance bottleneck in the business?

Is it to gain flexible scalability?

Or is it to learn and explore new technology in advance and make technical preparations?

| username: Jellybean | Original post link

There is a saying that if your business table can be kept below 50 million rows, it is recommended to use MySQL. Its performance will be better. If there are larger data storage and access performance requirements, such as storing a single table that may have 100 million rows, 1 billion rows, 10 billion rows, etc., it is recommended to consider using TiDB.

| username: ShawnYan | Original post link

Perhaps it’s all about cost considerations. For small data volumes, a single database is sufficient, and the costs of manpower and resources are manageable.

For a single table with hundreds of millions of rows, a distributed system is beneficial for smooth horizontal scaling.

| username: 春风十里 | Original post link

xc+ better technical support services.

| username: zhanggame1 | Original post link

Domestic, with enterprise services.

| username: TIDB-Learner | Original post link

MySQL is open-source and widely used. TiDB is compatible with MySQL. It’s ready to use, the community is active, and TiDB’s technology updates are frequent.

| username: Kongdom | Original post link

  1. Relational database
  2. To meet future business needs and support big data
  3. Requirements for information innovation
| username: 沧浪之水 | Original post link

Made dumplings just for this vinegar.

| username: dba远航 | Original post link

HTAP, dynamic scalability, big data, etc.

| username: 随缘天空 | Original post link

High performance, easily scalable, suitable for HTAP analysis, and avoids sharding and partitioning due to large data volumes.

| username: tidb菜鸟一只 | Original post link

To handle larger concurrency, easy to scale, and possibly support OLAP requirements in the future, these should be the main points…

| username: 像风一样的男子 | Original post link

The simplest point is that I have a table with more than 20 billion records, and partitioning it in MySQL would exhaust me.

| username: wangccsy | Original post link

We haven’t used this yet. We are using the SQL Server Express version.

| username: 路在何chu | Original post link

There are no strict requirements for this. When MySQL can no longer meet the current business needs, that’s when you should consider other databases.

| username: Kongdom | Original post link

:joy: Does your company put all the data in one table?

| username: 托马斯滑板鞋 | Original post link

Eliminate sharding, multi-node read/write, maximize host resource utilization, more SSD-friendly LSM, better multi-table association, and integrated HTAP.

| username: 连连看db | Original post link

Capacity, scalability, OLTP. Distributed databases will be mainstream in the future, rather than sharding. Small businesses use MySQL, large businesses use TiDB or OB, and they can also perform data analysis, making them very suitable for most enterprises.

| username: forever | Original post link

Sharding is too painful, it’s fake distributed.

| username: 像风一样的男子 | Original post link

There are a few tables that are particularly large, and every time I see them, I really want to drop them.

| username: forever | Original post link

Do you have any tables with a dozen or so CLOB fields? :sweat_smile: