Source: Dev.to

7 Things I Wish I Knew Before Scaling Next.js + Supabase to 100K Users

Six months ago, we launched our SaaS with Next.js and Supabase. The stack was perfect for our MVP: fast development, great DX, and it just worked. Then we hit 10K users. Then 50K. Then 100K. Everything that worked beautifully at small scale started breaking. Database queries that took 50ms now took 5 seconds. Our Supabase bill went from $25/month to $800/month. Users complained about slow page loads. Here’s what I wish someone had told me before we started. We skipped RLS in development. “We’ll add it before launch,” we said. Launch day came. We enabled RLS on all tables. The app broke in 47 different places. Queries that worked suddenly returned empty arrays. Inserts failed with permission errors. We spent 12 hours fixing RLS policies while users waited. What I’d do differently: Enable RLS from day one. Write policies as you create tables: CREATE TABLE posts ( id UUID PRIMARY KEY DEFAULT uuid_generate_v4(), title TEXT NOT NULL, user_id UUID REFERENCES auth.users(id) );

— Enable RLS immediately ALTER TABLE posts ENABLE ROW LEVEL SECURITY;

— Write policies now, not later CREATE POLICY “Users can view own posts” ON posts FOR SELECT USING (auth.uid() = user_id);

Test with RLS enabled. If it works in development, it’ll work in production. “We’ll add indexes when we need them.” We needed them on day 3. Our posts feed query went from 50ms to 8 seconds as we hit 10K posts. Users complained. We scrambled to add indexes during peak traffic. The query: const { data } = await supabase .from(‘posts’) .select(’, profiles()’) .eq(‘published’, true) .order(‘created_at’, { ascending: false }) .limit(20)

The fix: CREATE INDEX posts_published_created_at_idx ON posts(published, created_at DESC) WHERE published = true;

Query time dropped to 12ms. What I’d do differently: Add indexes for any column you filter or sort by: — Filter columns CREATE INDEX posts_user_id_idx ON posts(user_id); CREATE INDEX posts_published_idx ON posts(published);

— Sort columns CREATE INDEX posts_created_at_idx ON posts(created_at DESC);

— Composite indexes for common queries CREATE INDEX posts_user_published_idx ON posts(user_id, published);

Indexes are cheap. Slow queries are expensive. Our user dashboard loaded 47 separate queries. One for the user, one for each post, one for each comment count, one for each like count. Page load: 4.2 seconds. The problem: // ❌ N+1 query hell const { data: posts } = await supabase .from(‘posts’) .select(’*’) .eq(‘user_id’, userId)

for (const post of posts) { const { count: commentCount } = await supabase .from(‘comments’) .select(’*’, { count: ‘exact’, head: true }) .eq(‘post_id’, post.id)

const { count: likeCount } = await supabase .from(‘likes’) .select(’*’, { count: ‘exact’, head: true }) .eq(‘post_id’, post.id) }

The fix: // ✅ Single query with joins const { data: posts } = await supabase .from(‘posts’) .select( *, comments(count), likes(count) ) .eq(‘user_id’, userId)

Page load: 180ms. What I’d do differently: Use Supabase’s join syntax. Fetch related data in a single query. If you’re making queries in a loop, you’re doing it wrong. We built everything as Client Components because that’s what we knew from React. Our bundle size: 847KB. First Contentful Paint: 3.1s. The problem: // ❌ Client Component fetching data ‘use client’

export default function PostsPage() { const [posts, setPosts] = useState([])

useEffect(() => { async function fetchPosts() { const { data } = await supabase.from(‘posts’).select(’*’) setPosts(data) } fetchPosts() }, [])

return {/* render posts */} }

The fix: // ✅ Server Component export default async function PostsPage() { const supabase = await createClient() const { data: posts } = await supabase.from(‘posts’).select(’*’)

return }

Bundle size: 124KB. First Contentful Paint: 0.8s. What I’d do differently: Default to Server Components. Only use Client Components when you need interactivity, browser APIs, or hooks. Fetch data on the server. Send HTML to the client. Your users will thank you. Every page load hit the database. Every. Single. Time. Our Supabase bill: $800/month for 100K users. The problem: // ❌ No caching export default async function PostPage({ params }) { const { data: post } = await supabase .from(‘posts’) .select(’*’) .eq(‘id’, params.id) .single()

return {post.title} }

The fix: // ✅ With caching export const revalidate = 3600 // 1 hour

export default async function PostPage({ params }) { const { data: post } = await supabase .from(‘posts’) .select(’*’) .eq(‘id’, params.id) .single()

return {post.title} }

Database queries dropped by 94%. Bill: $180/month. What I’d do differently: Cache everything that doesn’t need to be real-time: Blog posts: 1 hour User profiles: 5 minutes Static content: 24 hours Personalized data: No cache Use revalidatePath() in Server Actions to invalidate cache when data changes. At 50K users, we started seeing “too many connections” errors. Supabase has connection limits: Free tier: 60 connections Pro tier: 200 connections We were opening a new connection for every request. The problem: // ❌ New connection per request export default async function handler(req, res) { const supabase = createClient() // New connection const { data } = await supabase.from(‘posts’).select(’*’) res.json(data) }

The fix: Use Supabase’s built-in connection pooling. Enable transaction pooling in your database settings. For serverless functions, use Supabase’s connection pooler: // Use pooler URL for serverless const supabase = createClient( process.env.SUPABASE_URL, process.env.SUPABASE_ANON_KEY, { db: { schema: ‘public’, }, global: { headers: { ‘x-connection-pooler’: ‘true’ }, }, } )

What I’d do differently: Enable connection pooling from day one. Monitor connection usage in Supabase dashboard. Upgrade tier before hitting limits. We made schema changes directly in Supabase Studio. No migrations. No version control. Then we needed to deploy to staging. We had no idea what our production schema looked like. We manually recreated tables. We missed columns. We forgot indexes. Staging broke. What I’d do differently: Use migrations from the start:

Create migration

npx supabase migration new add_posts_table

Write SQL

supabase/migrations/20260314_add_posts_table.sql

Apply locally

npx supabase db reset

Push to production

npx supabase db push

Every schema change is version controlled. You can recreate your database from scratch. You can deploy to multiple environments confidently. Migrations seem like overhead. They’re actually insurance. Next.js and Supabase scale beautifully. But you need to: Enable RLS from day one Add indexes early Avoid N+1 queries Use Server Components by default Cache aggressively Enable connection pooling Use migrations for all schema changes These aren’t advanced techniques. They’re basics that save you from pain later. Start with good patterns. Your future self will thank you. What lessons have you learned scaling Next.js and Supabase? Drop a comment below. Originally published at https://www.iloveblogs.blog