FAQs

TiDB is a next-generation, distributed relational database. TiDB can independently scale both computing and storage capacity simply by adding new nodes. This makes infrastructure capacity scaling easier and more flexible compared to traditional relational databases that only scale vertically.

TiDB’s advantages over MySQL:

• TiDB has a distributed architecture with flexible and elastic scalability
• TiDB automatically takes care of dynamic distribution, allowing you to easily scale your TiDB cluster horizontally with just a few clicks
• TiDB supports high availability with automatic failover, ensuring business continuity with auto-backups regardless of disk or machine failures
• TiDB is a Hybrid Transactional Analytical Processing (HTAP) database that handles both Online Transaction Processing (OLTP) and Online Analytical Processing (OLAP) workloads within one database

TiDB supports the MySQL protocol and dialect. You can replace MySQL with TiDB to power your applications without changing any code in most cases.

TiDB is an open-source database and is the best option for organizations that want to run TiDB on-premises or in their own data centers.

TiDB Cloud is a fully managed cloud Database as a Service of TiDB. It has an easy-to-use web-based management console to let you manage TiDB clusters for mission-critical production environments.

Currently, TiDB supports the majority of MySQL 5.7 syntax with the exception of triggers, stored procedures, user-defined functions, and foreign keys. For more details, see Compatibility with MySQL.
If you use the MySQL 8.0 client and it fails to connect to TiDB, try to add the default-auth and default-character-set options:

mysql -h 127.0.0.1 -u root -P 4000 --default-auth=mysql_native_password --default-character-set=utf8

This occurs because MySQL 8.0 changes the default authentication plugin in MySQL 5.7. You need to manually add the options above to specify using the older encryption method.

You can use any language supported by the MySQL client or driver.

TiDB implements Snapshot Isolation consistency, which delivers REPEATABLE-READ for compatibility with MySQL. Data is redundantly copied between TiKV nodes using the Raft consensus algorithm to ensure recoverability should a node failure occur.

TiDB uses a model of replication log + State Machine to replicate data. For write requests, data is written to a Leader and the Leader then replicates the command to its Followers in the form of a log. When the majority of nodes in the cluster receive this log, this log is committed and can be applied to the State Machine.

TiDB is available for bare metal, cloud-based, or hybrid installs. A Kubernetes Operator is available for use with TiDB; you can also use TiUp, a tool that can be used to quickly and easily deploy a test environment on your laptop or an entire production-quality cluster across many nodes.

TiDB is trusted by over 2000 global enterprises across a variety of industries, such as financial services, gaming, and e-commerce. Our users include Square (US), Shopee (Singapore), and China UnionPay (China). See our case studies for specific details.

TiDB uses the Raft consensus algorithm to ensure that data is highly available and safely replicated throughout storage in Raft Groups. Data is redundantly copied between TiKV nodes and placed in different Availability Zones to protect against machine or data center failure. With automatic failover, TiDB ensures that your service is always on.

TiDB is supported by a team that has run mission-critical use cases for over 1500 global enterprises across industries including financial services, e-commerce, enterprise applications, and gaming. Support is available 24/7 for TiDB users.

PD, the Placement Driver is “the brain” of the entire TiDB cluster, as it stores the metadata of the cluster. It sends data scheduling commands to specific TiKV nodes according to the data distribution state reported by TiKV nodes in real-time.

TiDB is the SQL computing layer that aggregates data from queries returned from TiKV or TiFlash stores. TiDB is horizontally scalable; increasing the number of TiDB nodes will increase the number of concurrent queries the cluster can handle.

TiKV is the transactional store used to store OLTP data. All the data in TiKV is automatically maintained in multiple replicas (three replicas by default), so TiKV has native high availability and supports automatic failover. TiKV is horizontally scalable; increasing the number of transactional stores will increase OLTP throughput.

TiFlash is the analytical storage that replicates data from the transactional store (TiKV) in real-time and supports real-time OLAP workloads. Unlike TiKV, TiFlash stores data in columns to accelerate analytical processing. TiFlash is also horizontally scalable; increasing TiFlash nodes will increase OLAP storage and computing capacity.

TiKV divides the key-value space into key ranges, and each key range is treated as a “Region”. In TiKV, data is distributed among all nodes in the cluster and uses the Region as the basic unit. PD is responsible for spreading (scheduling) Regions as evenly as possible across all nodes in the cluster.

TiDB uses the Raft consensus algorithm to replicate data by Regions. Multiple replicas of a Region stored in different nodes form a Raft Group.

Each data change is recorded as a Raft log. Through Raft log replication, data is safely and reliably replicated to multiple nodes of the Raft Group.

Traditionally, there are two types of databases: Online Transactional Processing (OLTP) databases and Online Analytical Processing (OLAP) databases. OLTP and OLAP requests are often processed in different and isolated databases. With this traditional architecture, migrating data from an OLTP database to a data warehouse or data lake for OLAP is a long and error-prone process.
As a Hybrid Transactional Analytical Processing (HTAP) database, TiDB helps you simplify your system architecture, reduce maintenance complexity, and support real-time analytics on transactional data by automatically replicating data reliably between the OLTP (TiKV) store and OLAP (TiFlash) store. Typical HTAP use cases are user personalization, AI recommendation, fraud detection, business intelligence, and real-time reporting.
For further HTAP scenarios, refer to How We Build an HTAP Database That Simplifies Your Data Platform.

TIDB provides TiDB Lightning and a Data Migration Tool to migrate data from MySQL databases. TiDB implements MySQL wire protocol and you can use the MySQL client to TiDB. We also offer access to data using TiKV APIs with Java, Go, Rust, Python, etc.

Some features, like audit, are not included in the Community Edition. But the biggest difference is the inclusion of Enterprise Support at the Enterprise Subscription level.

Transport Layer Security (TLS) and Transparent Data Encryption (TDE) are included for encryption at rest. There are two different network planes: the application to the TiDB server and the plane for data communication. We include extended syntax to compare Subject Alternative Name for verification of certificates and TLS context for internal communication.