PlanetScale Boost: Query Caching That Actually Works in Production

PlanetScale Boost is a query caching layer built into the database connection. You enable caching for specific query patterns in the dashboard, set a session variable on your connection, and matching queries are served from a memory-backed cache. 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. Click "Add a query cache" and choose the query pattern to accelerate (use Insights to find good candidates)
3. On the connection you want served from cache, run SET @@boost_cached_queries = true
4. Use a separate connection for boosted queries so you're explicit about what's cached

-- Boost is enabled per-connection with a session variable, not a special
-- connection string or endpoint. Run this once on the connection:
SET @@boost_cached_queries = true;

-- Subsequent queries on that connection use any cache you added in the dashboard.

Queries That Benefit Most

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.