Database schemas are limited to a total of
2048 tables, including views.
Individual tables are limited to a maximum of
1017 columns each.
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 DML timeout||30s|
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.
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.