Data Panda brings the PlanetScale database behind your application together with the data from the rest of your business. From one place, we turn it into dashboards, automations, AI workflows and custom apps your team uses every day.
PlanetScale is a cloud database platform built on Vitess, the same MySQL sharding layer that Slack, GitHub and HubSpot run their primary databases on. The platform gives a SaaS team a fully managed MySQL with horizontal sharding, branching that copies the schema (not the data) into an isolated branch, and deploy requests that gate every schema change behind a review and a queued, non-blocking migration.
For a typical Data Panda customer, the interesting tables sit on the production branch behind a Vitess router that may already shard a few of the larger ones by tenant or customer id. Pulling that database into a warehouse means reporting reads against a copy that joins to Stripe, HubSpot and the accounting ledger without putting load on the shards your application traffic is hitting. It also gives you a place to look at what changed across deploy requests, instead of finding out on Monday morning that the dashboard column quietly disappeared on Friday.
Application data joined to the rest of the stack, without touching the production cluster.
Let changes in PlanetScale fire actions in the tools around it.
Score and classify on the same tables your application writes.
Tools for support, finance and ops without raw branch credentials.
A list of concrete reports, automations and AI features we have built on PlanetScale data. Pick the one that matches your situation.
Are our dashboards running directly against the PlanetScale production branch?
A survey of which dashboards query the production branch, with cluster load, query cost and shard hotspots flagged. Highlights the reports that should move to the warehouse first and the queries that are pinning a single shard at peak hour.
Which dashboards is the next deploy request going to break?
Schema diff from each open deploy request mapped to the dashboards, automations and AI workflows that read the affected columns. The review conversation stops being theoretical because the impact is visible before the migration runs.
Which tenants are loss-making at our current PlanetScale plan?
Tenant-level activity, row counts and shard load lined up against the Stripe revenue and PlanetScale plan cost. Finance and product see who is loss-making before the next price review, not after.
PlanetScale plan cost lined up per tenant against the Stripe revenue and the activity each tenant generates. The cost of serving each customer becomes visible on the same record as their MRR.
Product usage and account engagement on every CRM record, sourced from the PlanetScale production branch. Reps see who is about to expand and who is going quiet before the renewal call.
Shard load, schema drift and deploy-request impact tracked in one place. Reporting becomes part of the review on every deploy request, instead of a Tuesday morning surprise.
Tables from the PlanetScale production branch replicate into BigQuery on a schedule that fits the tenant. The application keeps owning the Vitess cluster while reporting, finance and AI workflows run on a warehouse copy that stays off the live shards.
Each PlanetScale deploy request is matched to the GitHub pull request that introduced the schema change, and the warehouse layers the dashboards, automations and AI workflows that read the affected columns on top. Engineering reviews the technical diff in GitHub and the business impact in one place.
Product events captured by PostHog are joined to the PlanetScale user and tenant tables in the warehouse, so behaviour analytics and back-end truth share the same identifier. Funnels, retention curves and feature-adoption charts read from one number, not two.
Open deploy requests with high downstream impact, shard-hotspot alerts, plan-cost spikes and big new accounts from the warehouse land in the right Slack channel for the team that owns them. The on-call channel sees infra signal, the CS channel sees account signal, and nobody has to log into PlanetScale to find out.
You keep the reporting tool you already have. We connect it to the warehouse where your PlanetScale data lives.
OAuth authentication. Read-only by default. We sign a DPA and your admin keeps the keys.
Data flows into your warehouse on your schedule. Near real time or nightly, your call. You own the data.
We build the first dashboard, workflow or AI feature with you, then hand over the keys. Or we stay on for ongoing delivery.
We set up the foundation. Your team builds on top.
Best fit Teams that already have a BI analyst or data engineer and want to own the build.
We build the whole thing, end to end.
Best fit Teams without in-house BI or dev capacity. You tell us what you need and we deliver it.
You do. It lands in your warehouse, on your cloud account. We don't resell or aggregate it. If you stop working with us, the warehouse stays yours and keeps running.
Near real time for most operational systems. For heavier sources we schedule hourly or nightly. You pick based on what the reports need.
No. If you don't have one, we help you pick one and set it up as part of the first delivery. Common starting points are Snowflake, Microsoft Fabric, or a small Postgres start.
The connector reads through the Vitess router, so a sharded keyspace lands as a single logical table per source table in the warehouse. Per-shard row counts and load are kept as a side table for ops reporting, but the analytical join in the warehouse looks like one table, not n shards.
The diff inside each PlanetScale deploy request is mapped to the dashboards, automations and AI workflows that read those columns, before the migration runs. Added columns appear in the warehouse on the next sync, renamed ones link to their history, and removed ones stay read-only so older reports still run instead of silently returning null.
We review your PlanetScale setup and the systems around it. Together we pick the first thing worth building.