SupaInsurTech · Supabase · CRM
How an InsurTech platform cut CRM database work by 93%.
An InsurTech platform’s CRM needed to show 25 records, a total count, and a few summary cards.
To assemble that screen, its backend kept rebuilding the same directory and repeating the same access checks.
SupaBeast’s review process identified the duplicated work. The resulting refactor brought the manager read path from 1,019 ms to 74 ms of SQL execution, while preserving the records and permissions the application depended on.
Here’s what was built, what the review caught, and what changed.
August 3: a focused lead list
The early adopter is an InsurTech platform built on Supabase. Its CRM lead-list and detail APIs first landed on August 3, 2026. Agents could retrieve the leads assigned to them, filter the list, and open an individual record. Managers could see their team’s leads.
That was a reasonable starting point: read the records for the task in front of the user, enforce their permissions, and return a page. The application did not yet have the unified CRM directory it would need in October.
By the time of this case study, the platform’s production database held more than 20,000 quote snapshots and had logged more than 80,000 quoting-service events. Its CRM’s responsibilities had grown too.
Ten weeks of features changed what one screen needed
September 29: native calling connected live calls, CRM leads, and quote intake. The CRM now had to carry a customer from a call into a quote, with the right ownership and contact information.
October 10: a unified workspace brought current outcomes, appointments, follow-up tasks, and attention queues into the CRM. A directory row increasingly represented a customer’s current work, rather than just an incoming lead.
October 12: the directory expanded again to include people with saved applications even when they had no corresponding CRM lead. Producing a row could now involve finding the current application, its stage, the latest intake session, and outstanding follow-ups.
Each addition served a real workflow. Together, they changed the cost of assembling the screen. The page, exact count, and summary still read the directory separately, even though building that directory now required substantially more work.
October 13: revisit the read path
The performance refactor landed October 13—71 days after the first lead-read APIs, three days after the unified workspace, and one day after the application directory expansion.
The APIs had evolved throughout that period. The missed architectural question was whether the newer screen should keep assembling its shared information separately for each answer.
SupaBeast’s review connected the page, count, summaries, and permission checks into one read path. It identified where work was repeated and reworked that path around a single authorized database operation.
The problem was behind an ordinary screen
The screen needed three related answers: which records belong on this page, how many match, and what the overall workload looks like.
The backend fetched a page with an exact count and requested the summary separately. Underneath, those operations revisited the same directory and its authorization logic.
Adding a summary or another record type could make sense as an individual feature. The combined read path still needed someone to ask: why are we paying to assemble the same information several times?
The displayed page contained 25 records. The count and summaries required work across a larger set.
What SupaBeast caught
The review connected two sources of repeated work.
First, the page, exact count, and summaries depended on the same directory. Separate reads meant repeating its joins and record calculations.
Second, SELECT policies used permission helpers that checked individual records. Caller-level facts—identity, agency, and authority—were mixed into work repeated across candidate rows and related tables.
Those checks were necessary. Their execution needed a better design.
SupaBeast’s fix derived reusable ownership sets within the database statement, structured caller-level checks for reuse, and returned the directory page and aggregates through one authorized read.
How the backend changed
SupaBeast consolidated those reads into one directory RPC that returned the records, matching total, summaries, workload, and sources together.
Inside that read, scoped and filtered common table expressions reused the directory work. Page and count came from the filtered records. Overall summaries came from the broader authorized scope, preserving what each part of the screen was supposed to mean.
The authorization changes reused statement-scoped ownership sets and caller-level checks. They kept agency boundaries, assignment rules, and current account authority intact.
The public RPC used SECURITY INVOKER, so underlying table RLS continued to apply. Requesting another agency’s data did not make it accessible.
The application kept its existing answers. The database did less work to produce them.
What improved
The original before/after measurements showed:
| Read path | Before | After | Less SQL execution time |
|---|---|---|---|
| Agent | 388 ms | 29 ms | 93% |
| Manager | 1,019 ms | 74 ms | 93% |
| Admin | 770 ms | 77 ms | 90% |
Comparing the same 180 leads across two agencies, one directory RPC replaced three separate reads for the page, count, and summary.
The wider refactor also included workspace facts in the record-detail response, removing a separate request when opening a record.
The checks that stayed in place
Performance was only half the result. The refactor also had to preserve access.
The database test compared complete rows, ordering, counts, and summaries for agents, managers, and admins. It checked foreign-agency requests, stale or forged role claims, demotion, reassignment, and archived, banned, or deleted accounts.
That mattered because an optimization that retains access after a role or ownership change would be a different kind of production problem.
The improvement came from reorganizing the work while keeping those rules enforced.
One example of the review Supabase apps need as they grow
This case was about repeated directory and authorization work. Other applications reach different limits: an RPC takes on too many responsibilities, joins multiply rows, or new callers turn an existing query into an expensive default.
A focused lead list had become a workspace for calls, quotes, applications, and follow-ups. The feature work changed what the original approach had to support. The performance review finally changed how the backend did that work.
SupaBeast’s review approach draws on more than 100 backend optimization patterns we’re codifying into an AI review agent. It asks what the application now needs—and which existing queries, policies, functions, and request paths should be consolidated, rewritten, or removed to support it.
This early-adopter platform is one place we’re putting that approach to work. Its CRM refactor is one concrete example of what that review can uncover.