How I Scaled My NextJS + Supabase App to 45,000 Users

App Overview and User Growth [00:00]

• The app, Yorby, an AI-native social media marketing tool, has reached 45,000 signed-up users.
• Yorby combines AI tooling with human experts, differentiating itself from other marketing tech.
• Previous scaling milestones include 10,000 and 25,000 users, with this video detailing optimizations for 45,000.

  "And in this video, I'm going to go over all of the tech and performance optimizations that I had to make in my app to make sure that it can handle that load of that many users and still be very performant."

Superbase and Initial Scaling Challenges [01:46]

• The hardest growth phase was from 0 to 10,000 users, where major inefficiencies surfaced.
• From 10,000 to 25,000 users, improvements were made, building on the foundation set earlier.
• At 45,000 users, significant infrastructure overhauls were not needed, but Superbase-based optimizations were essential.

  "The hardest part of our growth journey was from the 0 to 10,000 user mark. That's when the biggest inefficiencies came out."

Optimizing Row-Level Security [02:31]

• A key optimization involved being more careful with Superbase's row-level security (RLS) rules.
• RLS rules, written in SQL, determine database access at the database layer.
• Initially, RLS checks for team validity were slow, causing significant latency as the user base and data grew.

  "The problem was that rowle security check of team validity was always a little slow and it would rack up that latency would build up over many many queries over and over again."

Moving Away from RLS for Performance [04:26]

• To improve performance, the decision was made to move away from using RLS rules for all queries.
• Querying the database without RLS significantly boosted performance.
• The creator acknowledges that RLS is important for browser instances but less critical for server-side fetching.

  "So we actually ended up moving off of using rowle security rules and just querying the database without any rowle security rules in place and that significantly improved the performance."

AI for Site Reliability Engineering [04:35]

• The creator has been using AI to help fix bugs reported by Posthog.
• The current manual process involves feeding errors into a local LLM for investigation and fixes.
• The concept of an AI Site Reliability Engineer (SRE) powered by Hermes is introduced, which can automatically triage, investigate, and propose fixes.

  "And right now I do this all pretty manually where if post talk finds an error I'll then copy that error and feed it into my local LLM."

Hermes and Hostinger Partnership [05:29]

• Hermes is an AI system that runs on user infrastructure, available 24/7, and learns over time.
• Hostinger offers managed Hermes with one-click deployment and handles maintenance, security, and backups.
• Features include AI credits, direct web access for agents, and integration with communication channels like Telegram.

  "And Hostinger makes getting started with that much more approachable with their managed Hermes."

Server-Side vs. Browser-Side Superbase Usage [06:06]

• The creator discusses the difference between Superbase browser and server instances.
• RLS rules are crucial for browser instances where public and user-scoped keys are exposed.
• For server-side fetching using server or admin clients, RLS becomes less critical as security can be enforced on the API/server layer.

  "But if you're pushing everything and doing all your data fetching server side via a superbase server client or even a superbase admin client then I think the rowle security rules become a lot less important."

Migrating from get user to get claims [09:01]

• Another major performance improvement was migrating from Superbase's get user function to get claims.
• get user required a server-side round trip, potentially taking 1-2 seconds.
• get claims uses a JWT token locally, eliminating the round trip and significantly speeding up authentication.

  "Get claims instead just uses a JWT token locally on your application. So then you can still get the currently authenticated user and that authenticated user information, but you do not need to do that round trip to the Superbase API server using get user."

Final Optimizations and Future Thoughts [10:13]

• The two major changes were reducing RLS checks and migrating to get claims.
• The app runs on the same Superbase tier, with increased compute size costing around $200/month.
• The creator is considering migrating all data querying to the Superbase admin client for consistency with other database providers.

  "And honestly that's kind of it. Those are the two major changes that I made throughout my application."