Integrations
Integration

Use PlanetScale with Sazabi: Insights, schema and read queries

By Sazabi Team

Last verified on Nov 8, 2026.

A database is often the quiet cause of an application incident. Latency climbs, a handler times out, and the application logs only say that a query was slow. The question that matters is which query, on which branch, and whether it was always slow or only since a change.

Sazabi is AI-native observability and security. Connect PlanetScale and the Sazabi agent can put that database context into the same thread as your application logs, so you read the slow route and the slow query together.

What the Sazabi agent can do with PlanetScale

Sazabi offers two methods. Both are in the PlanetScale integration docs.

The MCP connector uses PlanetScale's hosted MCP server and authenticates with OAuth. PlanetScale's reference lists these tools, among others:

  • planetscale_list_organizations, planetscale_list_databases and planetscale_list_branches to find the right branch.
  • planetscale_get_branch_schema for table definitions.
  • planetscale_get_insights for query performance on a branch.
  • planetscale_list_query_error_patterns for failing queries with the error message, occurrence count and last run, and planetscale_list_query_error_executions for the individual executions behind one entry, including normalized SQL, tables and user.
  • planetscale_list_schema_recommendations for missing or redundant indexes and primary key exhaustion.
  • planetscale_execute_read_query for SELECT, SHOW, DESCRIBE and EXPLAIN.
  • planetscale_list_query_tag_summaries to attribute database time to an application, route, job or user, once you tag queries.

For Postgres branches there is also planetscale_get_postgres_logs, which filters server logs by level, time range, server role and pod. It is not available for Vitess.

Each query uses short-lived credentials that are created on demand and deleted right after. planetscale_execute_write_query exists too, and Sazabi's per-connection read-only toggle is the way to keep it out of reach.

The sandbox CLI puts pscale in the agent's sandbox, authenticated with a service token ID and service token. It covers databases, branches and deploy requests, which the agent uses to see what shipped.

Questions it answers

  • Which queries on the production branch got slower since yesterday?
  • Which failing query is behind these timeouts, and which user ran it?
  • Does the orders table have the index this query needs?
  • Which route is spending the most database time?
  • Is a pending deploy request touching the table that is slow?

A worked example: a checkout timeout traced to one table

An alert says checkout requests are timing out. You ask in a thread:

Using PlanetScale, look at the main branch of the shop database. Show the
slowest queries from Insights for the last hour, list failing queries with
their error text, and check schema recommendations for the orders table.

The agent resolves the organization and branch with planetscale_list_organizations and planetscale_list_branches, then calls planetscale_get_insights. Say one query against orders filtered by customer_email leads. It follows with planetscale_list_schema_recommendations, and an index suggestion on that column lines up. Last, it runs EXPLAIN through planetscale_execute_read_query to confirm the scan, since read queries go to a replica by default and leave the primary alone. Any query the agent runs carries a source=planetscale-mcp comment, so you can find its own traffic in Insights.

The result is a lead with evidence: the query, the missing index and the plan. Adding the index is a schema change for you to make through a deploy request, and the agent can look at the open deploy requests with pscale to see if one already exists.

Permissions worth planning

With OAuth you choose no, read-only or full database access per organization or database. With a service token, PlanetScale documents the grants for each tool. Insights and schema need read_database and read_branch. Read queries add connect_production_read_only_branch and delete_production_read_only_branch_password. If you only want Insights and recommendations, PlanetScale offers an insights-only server that leaves out both query tools.

How it fits with other integrations

The agent reads PlanetScale next to whatever else you connect. Your application's own logs arrive through OpenTelemetry, and a hosting provider such as Cloudflare adds the edge view of the same requests. Both kinds of tool are grouped under cloud platforms. The full list is on the integrations page, and pricing covers what Sazabi itself costs.

Ways to connect

  • PlanetScale (MCP connector): Give the Sazabi agent tools to query databases, inspect schema, and explore Insights data in your PlanetScale organization.

Frequently Asked Questions

Can the Sazabi agent change my PlanetScale database?

Only if you let it. PlanetScale has a separate planetscale_execute_write_query tool that needs full connect permissions, and Sazabi lets you connect in read-only mode. PlanetScale also blocks UPDATE or DELETE without a WHERE clause and TRUNCATE.

Does a read query hit my primary?

Not by default. PlanetScale routes read queries to a replica when the branch has one, and the agent only reaches the primary when use_replica is set to false.

What is the difference between the MCP connector and the pscale CLI?

The MCP connector uses PlanetScale's hosted server over OAuth. The sandbox CLI runs pscale inside the agent's sandbox with a service token ID and service token, and covers databases, branches and deploy requests.

Does PlanetScale send logs to Sazabi?

Not through this integration. The agent asks PlanetScale for data at question time. Telemetry from your own services goes to Sazabi through OpenTelemetry.

Sources

  1. PlanetScale connects to Sazabi two ways: an MCP connector and a sandbox CLI (accessed Nov 8, 2026)
  2. OAuth with dynamic client registration, agent abilities (organizations, databases, branches, schema, read and write SQL, Insights, deploy requests), short-lived ephemeral credentials per query, read-only toggle (accessed Nov 8, 2026)
  3. The pscale CLI is baked into the Sazabi sandbox image and authenticated with a service token ID and service token (accessed Nov 8, 2026)
  4. Tool names including planetscale_get_insights, planetscale_list_query_error_patterns, planetscale_execute_read_query; replica routing and use_replica; source=planetscale-mcp query comment; insights-only server; write-query safeguards (accessed Nov 8, 2026)
  5. Per-tool permission table: read_branch, read_database, connect_production_read_only_branch and the other permissions each tool needs when using a service token (accessed Nov 8, 2026)