| title | {{{ .starter }}} FAQs | |
|---|---|---|
| summary | Learn about the most frequently asked questions (FAQs) relating to {{{ .starter }}}. | |
| aliases |
|
This document lists the most frequently asked questions about {{{ .starter }}}.
{{{ .starter }}} offers the TiDB database with full HTAP capabilities for you and your organization. It is a fully managed, auto-scaling deployment of TiDB that lets you start using your database immediately, develop and run your application without caring about the underlying nodes, and automatically scale based on your application's workload changes.
TiDB Cloud Starter is the new name for TiDB Cloud Serverless, effective August 12, 2025.
Before it was renamed to Starter, the Serverless tier of TiDB Cloud served as the entry point for thousands of developers, providing a production-ready database that scales automatically, starts in seconds, and costs nothing until you exceed a generous free quota.
While "serverless" accurately reflects how the service works behind the scenes, many first-time users found the term abstract and overloaded with different meanings.
To make the purpose of this entry tier clearer, we’ve renamed it to Starter, the fastest way to begin building with TiDB Cloud. Everything you know about the Serverless tier remains the same:
- A fully managed database with both row-based and columnar storage, ideal for hybrid OLTP and OLAP workloads.
- Automatic and request-driven scaling, no capacity planning or manual tuning required.
- Built-in vector search and full-text search to power GenAI retrieval, chatbots, and other AI applications.
- Always-free monthly quota for up to five clusters per organization (5 GiB row data + 5 GiB columnar data + 50 million RUs per cluster).
Get started with the 5-minute TiDB Cloud Quick Start
For each organization in TiDB Cloud, you can create a maximum of five {{{ .starter }}} clusters by default. To create more {{{ .starter }}} clusters, you need to add a credit card and set the spending limit for the usage.
Some of TiDB Cloud features are partially supported or not supported on {{{ .starter }}}. For more information, see {{{ .starter }}} Limitations and Quotas.
When will {{{ .starter }}} be available on cloud platforms other than AWS, such as Google Cloud or Azure?
We are actively working on expanding {{{ .starter }}} to other cloud platforms, including Google Cloud and Azure. However, we do not have an exact timeline for now as we currently focus on filling gaps and ensuring seamless functionality across all environments. Rest assured, we are working hard to make {{{ .starter }}} available on more cloud platforms, and we will keep our community updated as we progress.
I created a Developer Tier cluster before {{{ .starter }}} was available. Can I still use my cluster?
Yes, your Developer Tier cluster has been automatically migrated to the {{{ .starter }}} cluster, providing you with an improved user experience without any disruptions to your prior usage.
Columnar storage in {{{ .starter }}} acts as an additional replica of row-based storage, ensuring strong consistency. Unlike traditional row-based storage, which stores data in rows, columnar storage organizes data in columns, optimizing it for data analytics tasks.
Columnar storage is a key feature that enables the Hybrid Transactional and Analytical Processing (HTAP) capabilities of TiDB by seamlessly blending transactional and analytical workloads.
To efficiently manage columnar storage data, {{{ .starter }}} uses a separate elastic TiFlash engine. During query execution, the optimizer guides the cluster to automatically decide whether to retrieve data from row-based or columnar storage.
Consider using columnar storage in {{{ .starter }}} in the following scenarios:
- Your workload involves analytical tasks that require efficient data scanning and aggregation.
- You prioritize improved performance, especially for analytics workloads.
- You want to isolate analytical processing from transactional processing to prevent performance impact on your transactional processing (TP) workload. The separate columnar storage helps optimize these distinct workload patterns.
In these scenarios, columnar storage can significantly improve query performance and provide a seamless experience for mixed workloads in your system.
Using columnar storage in {{{ .starter }}} is similar to using it in TiFlash. You can enable columnar storage at both the table and database levels:
- Table level: Assign a TiFlash replica to a table to enable columnar storage for that specific table.
- Database level: Configure TiFlash replicas for all tables in a database to use columnar storage across the entire database.
Once a TiFlash replica is set up for a table, TiDB automatically replicates data from the row-based storage to the columnar storage for that table. This ensures data consistency and optimizes performance for analytical queries.
For more information about how to set up TiFlash replicas, see Create TiFlash replicas.
When you connect via a Public Endpoint, your connection passes through various network providers and intermediate devices. These devices might have their own short idle timeouts, which can interrupt your connection prematurely. For more information, see Connection limitations.
{{{ .starter }}} adopts a pay-as-you-go model, meaning that you only pay for the storage space and cluster usage. In this model, all cluster activities such as SQL queries, bulk operations, and background jobs are quantified in Request Units (RUs). RU is an abstract measurement for the size and intricacy of requests initiated on your cluster. For more information, see {{{ .starter }}} Pricing Details.
For the first five {{{ .starter }}} clusters in your organization, TiDB Cloud provides a free usage quota for each of them as follows:
- Row-based storage: 5 GiB
- Columnar storage: 5 GiB
- Request Units (RUs): 50 million RUs per month
If the monthly spending limit is set for a {{{ .starter }}} cluster, usage beyond the free quota will be charged. For a free cluster, once the free quota is reached, the read and write operations on this cluster will be throttled until you set a monthly spending limit or the usage is reset upon the start of a new month.
For more information, see {{{ .starter }}} usage quota.
Under the free plan, cluster performance is limited due to non-scalable resources. This results in a restriction on memory allocation per query to 256 MiB and might cause observable bottlenecks in request units (RUs) per second. To maximize cluster performance and avoid these limitations, you can set a monthly spending limit for your {{{ .starter }}} cluster.
To get the RU consumption of individual SQL statements, you can use the EXPLAIN ANALYZE SQL statement. However, it is important to note that the RUs usage returned in EXPLAIN ANALYZE does not incorporate egress RUs, as egress usage is measured separately in the gateway, which is unknown to the TiDB server.
To get the RUs and storage used by your cluster, view the Usage this month pane on your cluster overview page. With your past resource usage data and real-time resource usage in this pane, you can track your cluster's resource consumption and estimate a reasonable spending limit. If the free quota cannot meet your requirement, you can edit the spending limit for additional resources. For more information, see {{{ .starter }}} usage quota.
Ensure that your queries have been carefully optimized for optimal performance by following the guidelines in Optimizing SQL Performance. To identify the SQL statements that consume the most RUs, navigate to the Diagnosis page of your cluster, and then check the SQL Statements tab, where you can observe SQL execution and view the top statements sorted by Total RU or Mean RU. For more information, see Statement Analysis. In addition, minimizing the amount of egress traffic is also crucial for reducing RUs consumption. To achieve this, it is recommended to return only the necessary columns and rows in your query, which in turn helps reduce network egress traffic. This can be achieved by carefully selecting and filtering the columns and rows to be returned, thereby optimizing network utilization.
The storage is metered based on the amount of data stored in a {{{ .starter }}} cluster, measured in GiB per month. It is calculated by multiplying the total size of all the tables and indexes (excluding data compression or replicas) with the number of hours the data is stored in that month.
This is because TiDB retains dropped tables and databases for a certain period of time. This retention period ensures that transactions dependent on these tables can continue execution without disruption. Additionally, the retention period makes the FLASHBACK TABLE/FLASHBACK DATABASE feature feasible, which allows you to recover dropped tables and databases if they were mistakenly deleted.
RU consumptions can occur in various scenarios. One common scenario is during background queries, including but not limited to synchronizing schema changes between TiDB instances, executing DDL jobs, refreshing privileges, refreshing SQL bindings, and refreshing global variables. Another scenario is when certain web console features generate queries, like loading schemas. These processes use RUs even without explicit user triggers.
A spike in RU usage can occur due to necessary background jobs in TiDB. These jobs, such as automatically analyzing tables and rebuilding statistics, are required for generating optimized query plans.
Once a cluster reaches its free quota or spending limit, the cluster immediately denies any new connection attempts until the quota is increased or the usage is reset at the start of a new month. Existing connections established before reaching the quota will remain active but will experience throttling. For more information, see {{{ .starter }}} Limitations and Quotas.
During the data import process of a {{{ .starter }}} cluster, RU consumption occurs only when the data is successfully imported, which leads to spikes in RU usage.
The pricing for columnar storage in {{{ .starter }}} is similar to that for row-based storage. When you use columnar storage, an additional replica is created to store your data (without indexes). The replication of data from row-based to columnar storage does not incur extra charges.
For detailed pricing information, see {{{ .starter }}} pricing details.
Columnar storage in {{{ .starter }}} incurs additional costs due to the extra replica, which requires more storage and resources for data replication. However, columnar storage becomes more cost-effective when running analytical queries.
According to the TPC-H benchmark test, the cost of running analytic queries on columnar storage is about one-third of the cost when using row-based storage.
Therefore, while there might be an initial cost due to the extra replica, the reduced computational costs during analytics can make it more cost-effective for specific use cases. Especially for users with analytical demands, columnar storage can significantly reduce costs, offering considerable cost savings opportunities.
The serverless technology is designed for multi-tenancy and the resources used by all clusters are shared. To get managed TiDB service with isolated infrastructure and resources, you can upgrade it to TiDB Cloud Dedicated.
- Your connections are encrypted by Transport Layer Security (TLS). For more information about using TLS to connect to {{{ .starter }}}, see TLS Connection to {{{ .starter }}}.
- All persisted data on {{{ .starter }}} is encrypted-at-rest using the tool of the cloud provider that your cluster is running in.
No. {{{ .starter }}} clusters are upgraded automatically as we roll out new TiDB versions on TiDB Cloud. You can see what version of TiDB your cluster is running in the TiDB Cloud console or in the latest release note. Alternatively, you can also connect to your cluster and use SELECT version() or SELECT tidb_version() to check the TiDB version.