Database guides

TiDB

Updated 2026-08-01 · 3 min read

MySQL-compatible distributed SQL with an HTAP twist. AddisDB drives it with the MySQL driver, monitoring included.

TiDB speaks the MySQL wire protocol on port 4000, so AddisDB connects with its MySQL driver — schema browsing, in-grid editing, live monitoring and mock data all come along.

Who it is for

TiDB separates SQL from storage and can serve transactional and analytical workloads from the same cluster: rows for OLTP, a columnar replica for OLAP. That means you can run reporting queries against live data without building a pipeline into a separate warehouse.

Three components do the work: stateless TiDB servers parse and plan, TiKV stores rows and replicates them with Raft, and TiFlash keeps a columnar copy in sync. The optimizer decides per query which replica to read from, which is what makes the analytical half free of a nightly load job.

It fits a MySQL application that has hit a single-node ceiling, or a team tired of maintaining a nightly ETL job just to answer analytical questions about production data.

Set up the cluster

  1. On TiDB Cloud, create a Serverless or Dedicated cluster.
  2. Click Connect, then create or reveal a password. Serverless usernames are prefixed with your cluster identifier (something like 4Bx9pQ2.root) — copy the whole thing.
  3. Serverless clusters require TLS. Note the public endpoint host shown in the Connect dialog.
  4. For a Dedicated cluster, add your IP under Network Access first.
  5. Local: tiup playground starts a full cluster with TiDB on 4000.
# A whole local cluster, TiDB on 4000
tiup playground --db 1 --kv 1 --pd 1

Connect from AddisDB

  1. New Connection → TiDB. Port prefills to 4000 and the database to test.
  2. Paste the host and the full prefixed username from the TiDB Cloud Connect dialog.
  3. Set SSL mode to require — TiDB Cloud Serverless refuses plaintext connections.
  4. Test, then Save.

The prefixed username is the field people get wrong. Dropping the part before the dot produces an access-denied error that looks like a bad password but is actually a cluster the server could not identify.

Where it differs from MySQL

  • Foreign keys are supported but relatively young; older clusters treat the clause as a no-op, so a diagram can show fewer relationships than your schema file implies.
  • AUTO_INCREMENT allocates in per-server chunks, so ids are unique and ascending within a session but not globally gapless.
  • Some DDL is executed online and asynchronously; ADMIN SHOW DDL tells you what is still catching up.
  • Optimizer hints and analytical routing are TiDB’s own — a query plan will not read like MySQL’s.

What AddisDB gives you

  • Schema introspection and the foreign-key diagram.
  • In-grid editing of cells and rows behind the Edit toggle.
  • Live Monitor — active queries, sessions and connection stats through the MySQL-compatible views.
  • Mock data from your real schema, tracked and removable.
  • AI querying grounded in your actual tables and columns.
  • The Chart view, ⌘K search, and the full safety model.