TiDB Community Quarterly Roundup: The Most Popular Discussion Topics in Q4 2025

Key Takeaways

• MariaDB and MySQL migration dominated discussions, with schema compatibility as the top concern.
• A community member open-sourced a tool for automated MariaDB-to-TiDB schema testing.
• TiDB Cloud pricing and Request Unit (RU) tracking were frequent questions from new evaluators.
• Feature boundary questions highlighted the importance of validating requirements early.

Every quarter, our Discord and Slack communities surface questions that reflect what teams are actually working through. These include such topics as migration blockers, cost modeling unknowns, and the everyday friction of running a distributed database in production. Between October and December 2025, we collected the most in-depth discussions and distilled them into the themes below.

Three areas dominated the conversation: 

1. Migrating from MariaDB and MySQL
2. Understanding TiDB Cloud pricing and RU consumption
3. Navigating feature boundaries. 

Here’s what came up—and what the community learned.

Migrating from MariaDB and MySQL to TiDB

Migration was the single most active discussion area during the quarter. Community members evaluating TiDB as a replacement for MariaDB or MySQL consistently raised the same question: How much of my existing schema will just work?

MariaDB to TiDB

The answer depends on how closely your MariaDB usage aligns with standard MySQL syntax. If your schema is fully MySQL-compatible, you can migrate schema and data directly using TiDB DM (Data Migration) and standard MySQL-compatible workflows—no special conversion required.

If your schema relies on MariaDB-specific features—such as unsupported collations, non-standard DEFAULT expressions, or proprietary syntax—you’ll need to address those parts manually before migration.. The official Migrate from MariaDB to TiDB guide is essential reading for understanding where the boundaries are.

It’s also worth noting that DM’s support for MySQL is more mature than for MariaDB. When using DM with MariaDB sources, you may encounter edge cases or known issues that require manual intervention. The community’s advice: Validate early and validate often.

A community-contributed approach to compatibility testing. One member, @LexusRules, shared a practical pipeline for evaluating schema compatibility before committing to a full migration. His approach automates three steps: transforming MariaDB-specific DDL into TiDB-compatible syntax, spinning up a local TiDB cluster via Docker Compose, and validating applications against the transformed schema. He open-sourced the schema transformation component as mariadb2tidb, which handles common issues like collation mismatches, unsupported DEFAULT expressions, and engine syntax differences. If you’re planning a MariaDB migration, it’s a useful starting point for catching problems early in the process.

MySQL to TiDB: Charset and Collation Control

For MySQL-to-TiDB migrations, data synchronization itself is typically straightforward. The friction point that generated the most discussion was charset and collation behavior during migration.

A common request: “Can I tell DM to ignore the source database’s collation and apply utf8mb4_0900_ai_ci instead?”

Today, TiDB DM follows the upstream schema by design. If source tables explicitly define a charset and collation, DM syncs them as-is. If the source doesn’t specify, TiDB’s default (utf8mb4_bin) applies. DM does not support overriding the target collation during migration.

The recommended workaround is to pre-create your downstream tables. Define the target tables with the charset and collation you want, then point DM at the existing schema and let it load data into those pre-created tables. This gives you full control over the downstream schema without modifying the migration tool itself.

TiDB Cloud Pricing and RU Consumption

Pricing and Request Unit (RU) usage was another recurring theme, particularly among teams evaluating TiDB Cloud for the first time.

How Pricing Works

TiDB Cloud offers multiple service tiers with different pricing models. TiDB Cloud Starter uses a pure pay-as-you-go model—you’re billed based on actual usage with no minimum commitment. On the other hand, TiDB Cloud Essential includes a minimum monthly spend (roughly ~$500 USD), even if the cluster is mostly idle; this baseline ensures reserved capacity and stable performance, while usage beyond the baseline scales with workload demand.

Storage and Request Units primarily drive total cost. You can find unit pricing on the official pricing details page.

Understanding RU Consumption

RU cost is composed of three factors: reads, writes, and SQL CPU time.

In the TiDB Cloud console, navigate to Overview → Metrics to view aggregated RU consumption. RU is reported per second, so a rough daily estimate looks like:

RU/s × 3,600 = RU per hour

RU per hour × 24 = RU per day

To understand where your RU spend is coming from, start with query volume (QPS). As long as queries are executing, RU will accrue from the associated reads and writes. 

Use EXPLAIN ANALYZE to estimate the RU cost of individual SQL statements—the Billing and Metering FAQ has more detail on interpreting these results.

One common source of confusion: The Slow Query and SQL Statement views in the console are optimization tools, not exhaustive query logs. They surface high-impact SQL (often sorted by RU cost) to help you prioritize tuning efforts. 

Keep in mind that the RU shown per statement reflects a single execution—total impact depends on how many times that query runs—and not all RU from reads and writes is fully captured in these views.

Feature Gaps, Limitations, and Workarounds

The third major discussion area centered on understanding what TiDB supports today, where limitations exist, and what alternatives are available. Here are some representative topics from the quarter:

• Kubernetes monitoring (TidbNGMonitoring). A user deploying TiDB with the v2 Operator asked about enabling TidbNGMonitoring. This feature is not yet supported in the current release. The “v2.1 alpha” version that some users encountered is an internal test build and not intended for production use.
• JOIN ON subqueries. Native support is on the roadmap but won’t be available in the short term. As a workaround, users can explore alternative query patterns by enabling non-evaluated scalar subqueries.
• TiCDC and BLOB fields. When using TiCDC with the canal-json protocol, BLOB fields appear as unreadable strings. This is expected behavior—TiCDC does not currently support Base64 encoding for BLOBs, so any transformation needs to happen downstream.
• DM and foreign key constraints. DM handles most foreign key scenarios, but CASCADE operations still have known limitations. Full support is being explored.
• Stored procedures in TiDB Cloud. Several users migrating from MySQL asked about stored procedure support. TiDB Cloud does not plan to support stored procedures in the near future. The recommended approach is to move that logic to the application layer.

Join the Conversation

This quarterly roundup reflects the real-world challenges teams face when evaluating, migrating to, or running TiDB in production—from schema compatibility testing and cost modeling to understanding where feature boundaries are today.

If you have questions, insights, or migration stories to share, we’d love to hear from you. Join the conversation in our Discord or Slack communities.