PlanetScale Boost is a transparent query caching layer built into the database connection. You enable it, point your connection string at the Boost endpoint, and frequently-run queries are served from cache without code changes. This guide covers setup, cache invalidation, and the queries that benefit most.

How Boost Works

Boost sits between your application and the MySQL database. When a cacheable query runs, Boost stores the result. Subsequent identical queries return the cached result without hitting the database. Cache invalidation is automatic — when the underlying tables change, Boost invalidates affected cached queries.

Boost is not a general-purpose cache. It's specifically designed for read-heavy queries on tables that change infrequently. Think: analytics queries, configuration lookups, and reference data — not per-user real-time data.

Enabling Boost

  1. In the PlanetScale dashboard, go to your database > Boost
  2. Enable Boost for your main branch
  3. Copy the Boost connection string (different endpoint from the standard one)
  4. Update your DATABASE_URL to use the Boost endpoint
# Standard connection string
mysql://user:password@aws.connect.psdb.cloud/mydb?ssl={"rejectUnauthorized":true}
 
# Boost connection string (note the different host)
mysql://user:password@aws.connect.psdb.cloud/mydb?ssl={"rejectUnauthorized":true}&boost=1

Queries That Benefit Most

Query Type Cache Benefit Example
Config/settings lookups High SELECT value FROM config WHERE key = 'model_name'
Reference data High SELECT * FROM categories ORDER BY name
Aggregation queries High SELECT COUNT(*), AVG(score) FROM evaluations
User-specific reads Medium SELECT * FROM documents WHERE user_id = ?
Leaderboards High SELECT user_id, score FROM scores ORDER BY score DESC LIMIT 10
Real-time inventory Low SELECT stock FROM products WHERE id = ?

Recipe: Caching AI Model Configuration

# Without Boost: this query hits the database on every request
# With Boost: served from cache after the first call
 
def get_model_config() -> dict:
    row = db.execute(
        'SELECT model_name, temperature, max_tokens, system_prompt '
        'FROM ai_config WHERE is_active = 1 LIMIT 1'
    ).fetchone()
    return dict(row)
 
# This config table changes rarely (when you update model settings)
# Boost caches it and serves hundreds of requests per second from cache
# Cache is invalidated automatically when you UPDATE the ai_config table

Monitoring Cache Hit Rate

PlanetScale's Insights dashboard shows query-level analytics including cache hit rate. A healthy Boost deployment shows 90%+ cache hit rate on cached queries. Low hit rates indicate queries with high cardinality parameters (different values each call) that don't benefit from caching.

Boost Limitations

  • Boost only caches SELECT queries — writes always go to the primary
  • Queries with non-deterministic functions (NOW(), RAND()) are not cached
  • Very large result sets may not be cached
  • Cache invalidation happens at the table level — one write to a table clears all cached queries on that table
Do not use Boost for queries on high-write tables. If a table receives writes every few seconds, cache invalidation will prevent Boost from ever serving cached results. Use Upstash Redis for those cases instead.
Metadata Value
Title PlanetScale Boost: Query Caching That Actually Works in Production
Tool PlanetScale
Primary SEO keyword planetscale boost query caching
Secondary keywords planetscale caching, planetscale boost setup, planetscale performance
Estimated read time 6 minutes
Research date 2026-04-14