PlanetScale system limits
Learn about system limits that PlanetScale puts in place to protect your database.
Database schemas are limited to a total of
2048 tables, including views.
Individual tables are limited to a maximum of
1017 columns each.
Database client connections that are held open longer than
24 hours may be terminated unexpectedly. We recommend that long running database connections are closed and reconnected at least once per day.
PlanetScale has enforced some system limits to prevent long-running queries or transactions from:
- Piling up and consuming all available resources.
- Blocking other important, short-lived queries and transactions from completing.
- Overloading the database to the point where it is not recoverable without a restart.
- Blocking planned failovers and critical upgrades.
The following table details these limits:
|Per-query rows returned, updated, or deleted
|Per-query DML timeout
These limits are enforced for the safety of your database. However, we do understand you may run into a situation where the limits are a blocker. Here are some best practices for solving common issues presented by the limits:
What should I do if I have a query that returns more than 100,000 records?
We recommend trying to break up large queries, e.g. through pagination.
What should I do if I have a query that runs longer than 30 seconds?
For queries that are running for longer than 30 seconds, we recommend breaking these up into multiple shorter queries. For analytics queries that are not possible to break up, see "How should I handle analytical queries?" below.
Keep your transactions small and short-lived. For transactional workloads that are inherently long-lived, consider replacing or complementing MySQL transactions with other techniques:
- For simple workloads (e.g. a
SELECT, followed by an HTTP request, followed by an
UPDATE), consider using optimistic locking instead of transactions.
- For complex workloads, consider using sagas to coordinate a series of small, short-lived transactions that possibly span multiple microservices.
How should I handle analytical queries?
We recommend using PlanetScale Connect (via Airbyte or Stitch) to extract your data to any compatible destination (e.g. BigQuery, Redshift, etc.). The analytics queries should then be performed at those destinations.
While it is possible to bypass these safety limits using
OLAP mode (
SET workload = OLAP), we do not recommend this for the reasons listed at the beginning of this doc. In OLAP mode, you may return more than 100k rows from a single query, but the 100k row limit will still apply to updates and deletes.
When the use of OLAP queries is strictly unavoidable, we recommend:
- Where possible, sending those queries to a replica.
- Carefully and regularly reviewing the performance of those queries with PlanetScale Insights.