Skip to content

serverless-limitations.md

Latest commit

 

History

History
82 lines (49 loc) · 6.28 KB

serverless-limitations.md

File metadata and controls

82 lines (49 loc) · 6.28 KB
title Limitations and Quotas of {{{ .starter }}} and Essential
summary Learn about the limitations of {{{ .starter }}}.
aliases
/tidbcloud/serverless-tier-limitations

Limitations and Quotas of {{{ .starter }}} and Essential

{{{ .starter }}} and Essential work with almost all workloads that TiDB supports, but there are some feature differences compared with TiDB Self-Managed or TiDB Cloud Dedicated clusters. This document describes the limitations of {{{ .starter }}} and {{{ .essential }}}.

We are constantly filling in the feature gaps between {{{ .starter }}}/Essential and TiDB Cloud Dedicated. If you require these features or capabilities in the gap, use TiDB Cloud Dedicated or contact us for a feature request.

Limitations

Audit logs

Connection

  • Only Public Endpoint and Private Endpoint can be used. You cannot use VPC Peering to connect to {{{ .starter }}} or {{{ .essential }}} clusters.
  • No Firewall Rules support for Private Endpoint.
  • Your database client connections might be terminated unexpectedly if they remain open for more than 30 minutes. This can occur when a TiDB server shuts down, restarts, or undergoes maintenance, potentially causing application disruptions. To avoid this issue, configure a maximum connection lifetime. It is recommended to start with 5 minutes and increase it gradually if it affects tail latency. For more information, see Recommended settings for connection pools.

Note:

Due to a limitation of AWS Global Accelerator, the idle timeout for a Public Endpoint connection on AWS is 340 seconds. For the same reason, you cannot use TCP keep-alive packets to keep the connection open.

Encryption

  • Data persisted in your {{{ .starter }}} or {{{ .essential }}} cluster is encrypted using the encryption tool provided by the cloud provider that manages your cluster. For {{{ .starter }}} (with spending limit > 0) and {{{ .essential }}} clusters, an optional second layer of encryption is available during the cluster creation process, providing an additional level of security beyond the default encryption at rest.
  • Using customer-managed encryption keys (CMEK) is currently unavailable.

Maintenance window

Monitoring and diagnosis

Self-service upgrades

  • {{{ .starter }}} and {{{ .essential }}} are fully managed deployments of TiDB. Major and minor version upgrades of {{{ .starter }}} and {{{ .essential }}} are handled by TiDB Cloud and therefore cannot be initiated by users.

Stream data

  • Changefeed is not supported for {{{ .starter }}} currently.
  • Data Migration is not supported for {{{ .starter }}} currently.

Time to live (TTL)

  • In {{{ .starter }}} and {{{ .essential }}}, the TTL_JOB_INTERVAL attribute for a table is fixed at 15m and cannot be modified. This means that {{{ .starter }}} and {{{ .essential }}} schedule a background job every 15 minutes to clean up expired data.

Others

  • Transaction can not last longer than 30 minutes.
  • For more details about SQL limitations, refer to Limited SQL Features.

Usage quota

For each organization in TiDB Cloud, you can create a maximum of five free {{{ .starter }}} clusters by default. To create more {{{ .starter }}} clusters, you need to add a credit card and set a monthly spending limit for the usage.

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

The Request Unit (RU) is a unit of measurement used to track the resource consumption of a query or transaction. It is a metric that allows you to estimate the computational resources required to process a specific request in the database. The request unit is also the billing unit for {{{ .starter }}} service.

Once a cluster reaches its usage quota, it immediately denies any new connection attempts until you increase the quota or the usage is reset upon the start of a new month. Existing connections established before reaching the quota will remain active but will experience throttling.

To learn more about the RU consumption of different resources (including read, write, SQL CPU, and network egress), the pricing details, and the throttled information, see {{{ .starter }}} Pricing Details.

If you want to create a {{{ .starter }}} cluster with an additional quota, you can set the monthly spending limit on the cluster creation page. For more information, see Create a {{{ .starter }}} cluster.

After creating a {{{ .starter }}} cluster, you can still check and edit the spending limit on your cluster overview page. For more information, see Manage Spending Limit for {{{ .starter }}} Clusters.