Sync PlanetScale to Your Data Warehouse with Matia

Teams choose PlanetScale so they don’t have to manage MySQL servers themselves. The data in it still needs to reach the warehouse for reporting, models, and the business tools that depend on it.

Because PlanetScale manages the database for you, syncing changes works differently than it does on a self-managed MySQL server. Standard MySQL change data capture reads the binary log, which you’d normally configure on the server yourself.

PlanetScale streams through VStream, the change stream built into Vitess. To sync incrementally, a connector needs to read from VStream. Without that, keeping the warehouse current means reloading full tables.

Once the data lands in the warehouse, teams need to know whether it’s current, catch schema changes before they break a report, and trace a bad number back to its source. In most data stacks, each of those is a separate tool. In Matia, they’re part of the same platform.

Why we built it

This connector started with a customer. A team running PlanetScale as its primary database wanted to move to Matia, and syncing that database to their warehouse was the one thing in the way. It wasn’t on our roadmap for the quarter, but we like to build quickly when our customers are asking. We added it, built incremental sync on VStream, and now it’s shipped.

We built the connector ourselves, and we support it ourselves. If a PlanetScale sync needs attention, you talk to the same team that runs the rest of your pipeline, and they respond in minutes.

What we built

Matia now supports PlanetScale as an ETL source, along with self-hosted Vitess. The connector reads row changes directly from VStream, so incremental syncs work on PlanetScale the way change data capture works on MySQL. The connector supports:

• Full refresh, including views and tables without primary keys
• Incremental sync through VStream
• Column hashing for sensitive columns
• Automatic exclusion of system schemas and Vitess internal schemas like _vt

Why it matters

Setup doesn’t require any changes to your production database. You create a read-only password in PlanetScale, and that one password covers both the initial sync and every incremental sync after it.

Incremental syncs load only the rows that changed, so you aren’t reloading full tables to keep the warehouse current. Our post on CDC vs. ETL explains when each method fits.

Because Matia brings ETL, Reverse ETL, Observability, and Catalog together in one platform, the pipeline that syncs your PlanetScale data is the same one that monitors it, traces it, and sends it to the tools your teams use:

• Observability monitors the sync for schema changes and data quality issues, with alerts in Slack.
• The Catalog traces lineage from your PlanetScale tables through the warehouse and out to business tools, down to the column.
• If you send that data back out with Reverse ETL, a failed check can stop the sync before bad data reaches those tools, when configured to do so.

When a number in a report looks wrong, you can trace it back to the PlanetScale table it came from, in the same place you set up the sync.

That context also reaches the AI tools your team already uses through Matia MCP. Your AI assistant can look up a PlanetScale table, trace its lineage, check why a sync failed, and see what a schema change affects downstream. It works under each person’s existing Matia roles, so the assistant can only see what that person can see.

Every source you connect adds to that record. Run history, monitors, and lineage for PlanetScale sit next to the rest of your data. When a number looks wrong, your team or an AI assistant can trace it back to the source and fix it in one place.

How to set it up

In the PlanetScale console, create a read-only password on the branch you want to sync, usually your production branch.

In Matia, add a MySQL connection and choose Vitess as the server type. Enter the host, username, and password from PlanetScale, keep the default VStream port of 443, and set the keyspace to your PlanetScale database name.

Each connection syncs one keyspace, so a sharded database with several keyspaces needs a connection per keyspace. SSH tunneling isn’t available yet for PlanetScale or Vitess, so connect directly.

For self-hosted Vitess, point Matia at your VTGate gRPC port and keep full row images enabled, which is the Vitess default. The setup guide covers both.

Get access

The PlanetScale connector is available now for Matia customers. See the MySQL connector docs to get started. If you’re new to Matia, book a demo and we’ll walk through it with you. If you have questions during setup, our support team responds in minutes.