Astrato recently launched native integration with Supabase. This post explores why analytics is the gap most Supabase teams don't see coming — and what to do about it.
There is a pattern playing out across thousands of small software companies right now.
A founder vibe-codes an app on Lovable in a weekend, plugs it into Supabase for authentication and a Postgres database, and ships it to early users. Or a seed-stage team, too lean to justify a DevOps hire, picks Supabase because it bundles everything they need – auth, real-time subscriptions, Edge Functions, storage – into a single platform they can set up in an afternoon.
The common thread is speed: Supabase has become the default backend for B2B SaaS teams that would rather build product than manage infrastructure.
Then the product starts working. Users arrive. Paying customers follow. And at some point – usually once the customer base starts growing, or when a key account asks to see their own data – the team discovers a gap they had not planned for.
The app works, but the analytics don’t exist.
This is the “Supabase analytics wall”, and it is where a surprising number of promising products stall.
Why do Supabase teams struggle to run analytics?
The short answer: in-product analytics has become table stakes for B2B SaaS, and Supabase was never designed to provide it.
This is not just an ‘enterprise problem’. It’s an SMB problem.
According to Dresner Advisory Services’ 2024 Embedded BI Market Study, embedded analytics adoption has been climbing steadily across companies of all sizes, with the fastest growth among smaller organisations that need to deliver data directly inside their products.
Your customers do not want to log into a separate reporting tool. They expect dashboards, usage metrics, and performance data inside the app they are already paying for. When they cannot find it, they ask for it. When they keep asking and nothing appears, they leave.
There is also an architectural reason the wall appears where it does. Supabase runs on PostgreSQL, which is an OLTP database — optimised for transactional operations like reads, writes, and updates. It is brilliant at powering your app. But analytics workloads are fundamentally different: they require aggregating large volumes of data across columns, computing historical trends, and serving concurrent dashboard queries.
These are OLAP operations, and row-oriented databases like Postgres are not built for them. Running heavy analytical queries on your production Supabase instance does not just return slow dashboards — it puts pressure on the same database your app depends on. The wall is not a limitation of Supabase. It is a mismatch between what transactional databases do and what analytics requires.
For founders who vibe-coded a Lovable app that suddenly found product-market fit, this wall hits especially hard.
They might have been testing an idea. It stuck. Now they have a working product and real revenue, but zero reporting infrastructure.
As one developer noted in a review of AI app builders, the platform is strong for rapid UIs and basic CRUD but falls short the moment you need dynamic features – filtering, export, multi-tenant views, anything resembling the analytics layer a paying customer expects.
The gap between a prototype that works and a product customers will renew is, more often than not, an analytics gap.
And then there is the revenue sitting in plain sight.
The SaaS companies that have figured this out are not just adding analytics to keep customers happy – they are packaging data as a paid product.
Think of the verticals where this is already standard: logistics platforms that charge for shipment performance dashboards, HR tech that upsells workforce analytics, fintech apps that gate detailed transaction reporting behind premium tiers, and healthtech products where compliance reporting is a feature customers will pay extra for.
"To build a premium branded analytics experience, we migrated to Astrato + Supabase. The migration was seamless, the performance impressive and the costs extremely fair." — Daniel Andersen, Founder, Elbiil.dk
In-product analytics is not a cost centre. It’s a monetisation lever. The wall, then, is also the moment you realise your Supabase data could be generating revenue, and it is not.
Why do the common workarounds fail?
The natural response is to reach for familiar tools. Each one solves one problem and creates two others.
Hardcoding dashboards in React is the first instinct. It works for two views. By the tenth, you are managing a parallel frontend product: charting libraries, responsive layouts, data aggregation logic, permission filtering. Every customer request for “one more view” becomes a sprint. The engineering team, hired to build your core product, is now maintaining someone else’s BI tool.
As one developer described it on Indie Hackers: “Custom analytics approaches result in slow-loading dashboards, and adding new charts or custom features for different clients is time-consuming.”
For a small team, the opportunity cost is brutal – every week spent on dashboard plumbing is a week not spent on the features that actually differentiate your product.
Exporting data to a legacy BI platform – Tableau, Looker, PowerBI – decouples analytics from product. But the dashboard is now stale, rebuilt from snapshots rather than live data. User context (which customer, which tier, which permissions) requires manual joins. And embedding these tools in your product feels exactly like what it is: a third-party tool bolted on.
Looker can run $5,000 a month or more. Tableau Creator licences start at $75 per user. For a ten-person startup, these numbers are prohibitive before you have even built a single customer-facing view.
Ben Pearson at Nexus Property Maintenance chose Astrato + Supabase exactly because of this: "We didn't want a new data warehouse, a consulting army, and a bigger license bill—we just wanted better BI. Astrato with Supabase gave us modern analytics without the enterprise baggage."
Some teams try to solve it within Postgres itself — materialized views to pre-compute aggregations, read replicas to isolate analytical queries from production traffic. These help, but they are workarounds, not solutions. Materialized views go stale between refreshes. Read replicas still run on row-oriented storage, so complex aggregations remain slow. And neither gives you white-labeling, multi-tenancy, or embeddable dashboards. You end up with faster queries but no way to put them in front of a customer.
The most expensive path is the one vendors push hardest: migrate to a data warehouse.
ETL your Supabase data into one of the enterprise-grade cloud data platforms, add a transformation layer, then query the warehouse from a BI tool. For a company that chose Supabase specifically for speed and cost efficiency, this is absurd.
Enterprise warehouses were architected for large-scale operations, not lean startup teams – they demand data engineers, ETL pipelines, separate BI licences, and extensive setup. A warehouse-and-BI stack can easily exceed $50,000 a year – more than many Supabase teams spend on their entire infrastructure combined. You did not choose Supabase to end up paying enterprise prices for customer dashboards.
What makes customer-facing analytics different from internal BI?
Customer-facing analytics differ from internal BI in three critical ways: white-label requirements, per-tenant data isolation, and embedded-first design.
Most analytics tools are built for the first problem — internal teams exploring their own data — and fail when embedded into a product customers use directly.
Internal BI answers questions for your team: revenue trends, operational metrics, ad hoc exploration. The audience is small, the tolerance for rough interfaces is high, and security means "login to the BI tool".
Customer-facing analytics is a fundamentally different problem.
Every dashboard must be pixel-perfect and branded. Every tenant must see only their own data. The interface must be production-grade — not a reporting tool your users have to learn. And the whole thing must embed seamlessly into your application, not redirect users to a separate URL.
Your customers are not data analysts. They need metrics baked into the workflows they already use, available the moment they need to make a decision.
Supabase handles the operational database layer with elegance. But the analytics layer — aggregations, historical trends, governed self-service, multi-tenant embedding — requires a purpose-built tool.
What embedded analytics actually requires
If you're evaluating options—build, buy, or something in between—here's what matters for customer-facing dashboards:
- Direct database connectivity. The closer your analytics layer sits to your production data, the fresher your dashboards. Tools that query Supabase directly (via the Postgres connection) eliminate sync lag entirely.
- Row-level security passthrough. Supabase already has RLS. Your analytics layer should respect it, not require you to rebuild permission logic in a second system.
- White-label capability. Your customers shouldn't know (or care) what tool powers their dashboards. Custom domains, logo replacement, colour theming—these aren't nice-to-haves for customer-facing use cases.
- Embeddability. The dashboard needs to live inside your product, not in a separate tab. This means iframe support at minimum, ideally with SSO so customers don't log in twice.
- Writeback (optional but powerful). The next generation of embedded analytics lets users take action from dashboards—approve a workflow, update a record, trigger an automation. If your Supabase app uses Edge Functions, this becomes a natural extension.
How does Astrato solve analytics for Supabase?
The workarounds fail because they all force a trade-off: speed versus quality, live data versus cost, engineering time versus customer experience. Astrato removes those trade-offs by sitting directly on your Supabase Postgres database — not beside it, not on top of a copy of it, but on it. Queries run against live data in real time. There is no ETL pipeline to build, no warehouse to provision, no second system to keep in sync.
That solves the infrastructure problem. But the engineering bottleneck is equally painful, and it requires a different kind of answer. Astrato's drag-and-drop builder is designed for product teams and data engineers. Your team defines business metrics — "monthly active users," "expansion revenue," "feature adoption rate" — once, in a semantic layer, and reuses them across every dashboard. When a customer asks for a new view, it is a morning's work for a product manager rather than a sprint for an engineer. AI-powered insights auto-generate queries and surface anomalies, so the people closest to customers can act on data without writing SQL.
And unlike the legacy BI tools that fall apart when embedded, Astrato was built for customer-facing use cases from day one. Every dashboard is white-labeled to match your product's design. Every tenant sees only their own data, automatically, because Astrato inherits your existing Supabase RLS policies. There is no duplicate permission system to maintain and no separate login for your customers to learn. The analytics feel native because, from your customer's perspective, they are.
One capability goes further than any of the workarounds can. Astrato integrates with Supabase Edge Functions, which means a dashboard interaction can trigger backend logic — a customer alert, a data export, a subscription upgrade. Combined with writeback, dashboards stop being passive reports and become operational tools your customers use to take action.
The architecture: how it works
Astrato connects to your Supabase Postgres database using a standard connection string. That's it. No agents to install, no data to export, no infrastructure to manage.
Every query runs directly against your database with full row-level security support. If a user can only see their own data in your app, they can only see their own data in dashboards. The permissions model you've already built just works.
For teams concerned about query performance, Astrato pushes computation to the database layer. Complex aggregations run as optimised SQL, not as post-processing in the browser. This matters when you're querying tables with millions of rows.
And because there's no data movement, your compliance story stays simple. Data never leaves your Supabase project. SOC 2, GDPR, HIPAA—whatever framework you're working within, the data residency question has a straightforward answer.
How much does it cost to add analytics to a Supabase app?
For Supabase teams, the financial logic matters as much as the technical fit. The entire point of choosing Supabase was to avoid premature infrastructure complexity. Astrato preserves that advantage: you do not need a data warehouse to offer production-grade customer analytics.
You query your existing Postgres database directly, which means no new infrastructure costs and no ongoing ETL pipeline to maintain. The difference for a growing SaaS company is stark – a lightweight analytics layer versus a $50,000-plus annual commitment to a warehouse-and-BI stack you do not yet need.
When your data needs outgrow a single Postgres instance, Astrato scales with you. Connect to any major cloud data warehouse when you are ready – same dashboards, same semantic layer, same governance. You do not rebuild your analytics every time your data infrastructure evolves. The investment you make today carries forward.
Embedded analytics: from cost centre to revenue line
Consider a growing B2B SaaS company built on Supabase.
They shipped fast, found product-market fit, and now have a customer base that expects in-product reporting as standard. Rather than spending three months building custom dashboards in React, or diverting $50,000 into an enterprise data stack, they connect Astrato to Supabase and ship customer-facing analytics in days.
Within weeks, the product team is iterating on new views without engineering tickets. Within months, the company packages advanced analytics as a premium tier – turning reporting from a cost centre into a revenue line.
A logistics company charges for shipment performance dashboards. An HR platform upsells workforce analytics. A fintech app gates detailed transaction views behind a higher plan. The same usage data that sat idle in Postgres now justifies higher contract values and reduces churn, because customers who can see their own data stay longer and expand faster.
That is the transition: from “we need analytics to keep customers” to “analytics is one of our most valuable product features.” Astrato lets you get there with a product team and a Supabase database – no enterprise infrastructure required.
Getting started with Astrato + Supabase
The integration takes minutes. Connect your Postgres credentials, design your first dashboard, and embed it in your product. Most teams deploy their first dashboard in under a day; a production-ready analytics suite – multiple dashboards, semantic layer, white-labeling – typically ships within a week.
We have published a step-by-step integration guide, where you can see it working against a Supabase database. For teams with specific architecture requirements, we offer guided technical walkthroughs [Request a demo].
Supabase handles the database layer. Astrato handles the analytics layer your customers now expect. The result: a product that retains accounts, opens new revenue streams, and turns data into a feature worth paying for.
.avif)
