Data Panda brings the Supabase project 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.
Supabase is an open-source platform that gives every project a full Postgres database plus auth, file storage, realtime subscriptions, edge functions and a vector store on top. The team behind it has been shipping since 2020 and the platform is used by Mozilla, GitHub and 1Password as well as a long tail of SaaS startups and scale-ups that wanted a Postgres-native backend instead of a NoSQL one.
For a typical Data Panda customer the interesting tables are split across three Postgres schemas: the public schema where your app's domain tables live, auth where Supabase keeps users, sessions and identities, and storage where bucket and object metadata sits next to the files in S3. Joining those three together inside the warehouse gives a clean picture of who signed up, what they did, which files they uploaded and which features they touched, without writing a SQL query that has to satisfy your row-level-security policies first.
Auth, app and storage data joined in one place, without RLS in the way.
Let changes inside your Supabase project fire actions across the rest of the stack.
Score, classify and generate on the operational data you already capture.
Tools for support, finance and ops that read across your project without database credentials.
A list of concrete reports, automations and AI features we have built on Supabase data. Pick the one that matches your situation.
Who signed up this month and which of them used the product?
Auth.users joined to the public-schema tables that record real usage, broken down by source, plan and cohort. Marketing sees which channels brought activated users and which brought ghosts, on the same numbers product is looking at.
What is each tenant costing us in Supabase right now?
Storage object size, edge-function invocations and realtime channel volume aggregated per tenant, against the plan they pay for. Finance and product see who is loss-making before the next price review, not after.
Which dashboards will break the next time we change the public schema?
A change log on the public schema linked to the dashboards, automations and AI workflows that read each column. The Tuesday deploy stops being a surprise for reporting because the impact is visible before the migration runs.
Storage, edge-function and realtime usage per tenant lined up against the plan they pay for, and joined to Stripe revenue. The cost of serving each customer becomes visible on the same record as their MRR.
Auth and product-usage signal on every CRM account, sourced from the Supabase project rather than a custom export. Reps see who is on the verge of expanding and who is going quiet, before the renewal call.
Schema drift, edge-function errors and storage growth tracked in one place. Reporting stops being collateral damage of the next deploy and becomes part of the release check.
Public, auth and storage tables from the Supabase project replicate into BigQuery on a schedule that fits the tenant. The application keeps owning Postgres while reporting, finance and AI workflows run on a warehouse copy that stays out of RLS and out of production load.
Each Supabase auth.users row is matched to the Stripe customer and subscription that belongs to it, so product usage and billing state live on the same id. Churn scoring, billing reconciliation and plan-change alerts all run on one record instead of three exports.
Product events captured by PostHog are joined to the Supabase auth.users 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.
Edge-function error spikes, storage-quota alerts, big-account signups and churn-risk flags 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 Supabase to find out.
You keep the reporting tool you already have. We connect it to the warehouse where your Supabase 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.
RLS lives in your Supabase Postgres and is bypassed by the connector, which authenticates as a service role. Access control in the warehouse is handled by the warehouse's own roles and views, not by your application policies. Reports get a clean join on auth.users and your public tables without having to satisfy a policy first.
Yes. The interesting picture is the join across the three Supabase-managed schemas: public for your app, auth for users and sessions, and storage for bucket and object metadata. The connector replicates all three so the warehouse can answer questions about who signed up, what they did, and what they uploaded.
We review your Supabase setup and the systems around it. Together we pick the first thing worth building.