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.
1. RLS Policies Are Not Optional (Even in Development)
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.
2. Database Indexes Are Not Premature Optimization
"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.
3. N+1 Queries Will Kill Your Performance
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.
4. Server Components Are Your Friend (Use Them)
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 <div>{/* render posts */}</div>
}
The fix:
// ✅ Server Component
export default async function PostsPage() {
const supabase = await createClient()
const { data: posts } = await supabase.from('posts').select('*')
return <PostList posts={posts} />
}
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.
5. Caching Is Not Optional
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 <div>{post.title}</div>
}
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 <div>{post.title}</div>
}
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.
6. Connection Pooling Matters More Than You Think
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.
7. Migrations Are Not Scary (But Skipping Them Is)
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.
The Bottom Line
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