Your startup just closed a seed round. You have an 18-month runway. Your MVP on Supabase works like a charm... until you open your email to find a $4,200 bill for just one month. Why? Your sales dashboard is executing 2.6 million queries daily. No one touched anything; they just left the tab open.
Situations like this are more common than you think in startups. It's not a scalability issue, but a case of uncontrolled polling. Supabase's real-time architecture encourages subscribing to changes, but many founders still query the database every second, "because that's how they did it with Firebase." The big difference is that Firebase charges by GB transferred, while Supabase charges per read operation. A setInterval(fetchData, 1000) is a ticking time bomb.
Supabase's Cost Model That No One Reads Until It's Too Late
Supabase runs on Postgres. Each query is a read operation that gets billed. The free plan includes 500MB of database and 2GB of transfer, but the real limit is 50,000 monthly queries. It sounds generous, but the devil is in the details.
A dashboard polling every second executes 86,400 queries a day. With just three users leaving the tab open during 8 work hours, you exceed the free limit in just two days.
The Pro plan costs $25/month, including 5 million queries. That might seem sufficient, but in my experience, it isn't. A typical SaaS application with 500 active users, real-time dashboards, and auto-sync can execute 15-20 million queries monthly without much trouble. Each additional million costs $2.50. The $4,200 I mentioned earlier is no hypothetical case: a logistics tech startup with 30 employees using live dashboards hit that figure in March 2026.
The Trap of Poorly Implemented "Real-Time"
Supabase Realtime is designed to work with persistent websocket subscriptions. This lets you detect changes without constant queries. However, the documentation presents a problem: the initial examples show supabase.from('table').select() without explaining when and how to use it properly.
Many developers copy this pattern and wrap it in useEffect with React:
useEffect(() => {
const interval = setInterval(async () => {
const { data } = await supabase
.from('orders')
.select('*')
.eq('status', 'pending');
setOrders(data);
}, 1000);
return () => clearInterval(interval);
}, []);
This code works, but honestly, it also wrecks your budget. 86,400 queries daily per component. If you render this component on three different pages of your admin panel, it ends up being 259,200 queries daily. Monthly: 7.7 million queries. Cost: $67.50 just for this component.
The correct architecture uses Realtime:
useEffect(() => {
const channel = supabase
.channel('orders-channel')
.on('postgres_changes', { event: '*', schema: 'public', table: 'orders', filter: 'status=eq.pending' }, (payload) => {
setOrders(prev => [...prev, payload.new]);
})
.subscribe();
return () => supabase.removeChannel(channel);
}, []);
A single websocket subscription. Zero recurring queries. You only pay for actual updates. If your orders table gets 1,000 new orders daily, that's 1,000 events, not 86,400 queries.
The Invisible Problem: N+1 Queries in Your Middleware
Polling is obvious, but what's curious is the silent killer: N+1 queries in your business logic. It happens when iterating over results and executing a query for each item.
This pattern often appears in applications with complex relationships:
// β N+1 Queries
const users = await supabase.from('users').select('id, name');
for (const user of users.data) {
const { data: orders } = await supabase
.from('orders')
.select('*')
.eq('user_id', user.id);
user.orders = orders;
}
If you have 100 users, you run 101 queries (1 for users + 100 for orders). With 1,000 users, it's 1,001 queries each time you load this endpoint. If your dashboard queries it every 30 seconds, you execute 2.8 million queries monthly just here.
Supabase supports native Postgres joins. The right solution uses a single query:
// β
Single Query
const { data: users } = await supabase
.from('users')
.select(`
id,
name,
orders (
id,
total,
status
)
`);
One query. Identical result. The cost difference is significant: from 1,001 queries to 1 query. For 1,000 users queried 100 times a day, you go from 10 million monthly queries ($12.50 in the Pro plan) to 3,000 monthly queries (included in the base plan).
The ORM Illusion: When PostgREST Isn't Your Friend
Supabase uses PostgREST to turn your database into an API. It's great for prototyping, but risky in production without understanding the limits.
A real case: a fintech in Colombia had a system checking transaction changes every 5 seconds. They used this pattern:
const checkChanges = async () => {
const { data } = await supabase
.from('transactions')
.select('*')
.gte('updated_at', lastCheck.toISOString());
if (data.length > 0) {
sendNotifications(data);
}
};
setInterval(checkChanges, 5000);
It ran in production for two weeks, and no issues were noticed until a bill for 12 million queries arrived. The system queried the entire table every 5 seconds, filtering on the client side. With 50,000 transactions, each query scanned all the data.
The mistake: they didn't use indexes and queried without limits. The solution was simple:
- Create an index on
updated_at - Switch to Realtime triggers
CREATE INDEX idx_transactions_updated
ON transactions(updated_at DESC);
And replace polling with a trigger:
const channel = supabase
.channel('transaction-changes')
.on('postgres_changes', { event: 'UPDATE', schema: 'public', table: 'transactions' }, (payload) => sendNotifications([payload.new]))
.subscribe();
Final cost: from $35/month in extra queries to practically $0. Notifications now arrive in under 200ms instead of up to 5 seconds.
Row Level Security: When Security Blows Up Your Queries
RLS (Row Level Security) is one of Supabase's big attractions. It defines access policies directly in Postgres. But beware, each policy executes a subquery. If you design your policies poorly, you could triple your queries without realizing it.
An example of a poorly optimized policy:
CREATE POLICY "Users can read own orders"
ON orders FOR SELECT
USING (
user_id IN (
SELECT id FROM users
WHERE auth_id = auth.uid()
)
);
Every time you query orders, Postgres executes that subquery. If you have 10 stacked policies on a table, each SELECT runs 10 additional subqueries. Your dashboard loading orders actually executes 11 queries per load.
The optimized version uses direct joins and caches relationships:
CREATE POLICY "Users can read own orders"
ON orders FOR SELECT
USING (auth.uid() = user_id);
You eliminate the subquery. Postgres can use indexes directly. For an app with 500 active users checking their history, the difference is going from 5.5 million monthly queries to 500,000. Savings: $10/month that adds up as you scale.
The Nested JOINs Problem in RLS Policies
Things get complicated with many-to-many relationships. Suppose you have teams, users in teams, and shared projects:
-- β Costly Policy
CREATE POLICY "Users can read team projects"
ON projects FOR SELECT
USING (
id IN (
SELECT project_id
FROM team_projects
WHERE team_id IN (
SELECT team_id
FROM team_members
WHERE user_id = auth.uid()
)
)
);
Three levels of subqueries. Each query to projects runs these three nested queries. With 1,000 projects and 50 users querying, that's 150,000 additional subqueries daily.
A solution is to partially denormalize or use materialized views:
-- Create a materialized view
CREATE MATERIALIZED VIEW user_accessible_projects AS
SELECT
tm.user_id,
tp.project_id
FROM team_members tm
JOIN team_projects tp ON tm.team_id = tp.team_id;
-- Simplified policy
CREATE POLICY "Users can read accessible projects"
ON projects FOR SELECT
USING (
id IN (
SELECT project_id
FROM user_accessible_projects
WHERE user_id = auth.uid()
)
);
-- Refresh the view every hour
SELECT cron.schedule(
'refresh-user-projects',
'0 * * * *',
$$REFRESH MATERIALIZED VIEW user_accessible_projects$$
);
Materialized views have a cost because you need to refresh them. However, for data changing every hour (not every second), you reduce queries from millions to thousands. A project management startup in Mexico applied this and reduced their queries by 89%.
Pagination: The $800 Monthly Detail
Most Supabase tutorials show basic queries without pagination. New developers load entire tables:
const { data } = await supabase
.from('products')
.select('*');
If your products table has 10,000 items, each load transfers 10,000 records. This might not seem so bad initially, but imagine your admin panel reloads every time you switch tabs. An active user might trigger 50 loads daily. With 20 internal users: 1 million records transferred per month.
Supabase charges for read operations and also for egress (data transfer). The Pro plan includes 50GB. With average records of 2KB, those 10,000 products are 20MB per load. 50 daily loads Γ 20 users Γ 30 days = 600GB monthly. You exceed your limit by 550GB. Additional cost: $55/month just in transfer.
The correct pagination uses range:
const PAGE_SIZE = 50;
const { data, count } = await supabase
.from('products')
.select('*', { count: 'exact' })
.range(page * PAGE_SIZE, (page + 1) * PAGE_SIZE - 1);
Load 50 records (100KB) instead of 10,000 (20MB). You reduce transfer by an impressive 99%. The savings scale exponentially with your table size.
Infinite Scroll: The Deceptive Pattern
Many implement infinite scroll like this:
const loadMore = async () => {
const { data } = await supabase
.from('posts')
.select('*')
.range(posts.length, posts.length + 20);
setPosts([...posts, ...data]);
};
Seemingly efficient, but the trick lies in how Postgres executes range. Internally, Postgres scans from the start to your offset, discarding rows. If you're on page 100 (offset 2,000), Postgres reads 2,000 rows and discards 1,980.
With 100 users scrolling to page 50, you're scanning 100,000 rows daily when only 2,000 are shown. The solution is to use cursor-based pagination:
const loadMore = async () => {
const lastPost = posts[posts.length - 1];
const { data } = await supabase
.from('posts')
.select('*')
.lt('created_at', lastPost.created_at)
.order('created_at', { ascending: false })
.limit(20);
setPosts([...posts, ...data]);
};
Postgres uses the index on created_at. It doesn't scan prior rows. Constant queries regardless of scroll depth.
Monitoring: Discover the Disaster Before the Bill
Supabase doesn't offer detailed query analysis on its dashboard. You see total queries, but not which endpoints are causing issues. By 2026, tooling improved, but manual setup is still needed.
The solution is to use Postgres itself. Enable pg_stat_statements:
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;
-- Query the most costly queries
SELECT
query,
calls,
total_exec_time,
mean_exec_time,
rows
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 20;
This shows exactly which queries consume the most resources. An e-learning startup discovered their "active users last 30 days" query executed 400,000 times a month and took 3 seconds each time. The query scanned the entire user_sessions table.
The optimization was simple: add an index and a computed column:
-- Index on sessions
CREATE INDEX idx_sessions_recent
ON user_sessions(created_at)
WHERE created_at > NOW() - INTERVAL '30 days';
-- Computed column in users
ALTER TABLE users
ADD COLUMN last_active_at TIMESTAMP;
-- Trigger to update
CREATE TRIGGER update_last_active
AFTER INSERT ON user_sessions
FOR EACH ROW
EXECUTE FUNCTION update_user_last_active();
Result: query reduced from 3 seconds to 40ms. 76% reduction in Postgres load. Monthly bill from $180 to $42.
Automated Alerts with Supabase Hooks
Set up webhooks to alert you when something goes wrong. Edge Functions can monitor your metrics:
import { serve } from 'https://deno.land/std@0.168.0/http/server.ts';
import { createClient } from 'https://esm.sh/@supabase/supabase-js@2';
serve(async (req) => {
const supabase = createClient(
Deno.env.get('SUPABASE_URL'),
Deno.env.get('SUPABASE_SERVICE_KEY')
);
// Query stats metrics
const { data } = await supabase.rpc('get_query_stats');
const queriesLastHour = data.filter(d =>
d.timestamp > Date.now() - 3600000
).reduce((sum, d) => sum + d.calls, 0);
// Alert if you exceed threshold
if (queriesLastHour > 100000) {
await fetch(Deno.env.get('SLACK_WEBHOOK'), {
method: 'POST',
body: JSON.stringify({
text: `β οΈ Query spike: ${queriesLastHour} queries in the last hour`
})
});
}
return new Response('OK');
});
Schedule this function with pg_cron every hour. If your queries spike, you get a Slack alert before the problem spirals out of control.
The Hidden Cost of Custom RPC Functions
Supabase allows creating Postgres functions exposed as RPC endpoints. It's powerful but dangerous if not optimized correctly.
A common function is to calculate aggregate statistics.
CREATE OR REPLACE FUNCTION get_dashboard_stats()
RETURNS JSON AS $$
DECLARE
result JSON;
BEGIN
SELECT json_build_object(
'total_users', (SELECT COUNT(*) FROM users),
'active_users', (SELECT COUNT(*) FROM users WHERE last_active > NOW() - INTERVAL '7 days'),
'total_orders', (SELECT COUNT(*) FROM orders),
'revenue', (SELECT SUM(total) FROM orders WHERE status = 'completed')
) INTO result;
RETURN result;
END;
$$ LANGUAGE plpgsql;
Each call runs 4 aggregation queries. If your dashboard calls this every time you load the main page, with 50 internal users querying 20 times a day, that's 4,000 daily queries just from this function. In a month: 120,000 queries.
The optimization is to use cache tables updated by triggers:
-- Cached stats table
CREATE TABLE dashboard_stats_cache (
id INT PRIMARY KEY DEFAULT 1,
total_users INT,
active_users INT,
total_orders INT,
revenue DECIMAL,
updated_at TIMESTAMP DEFAULT NOW()
);
-- Function to update cache
CREATE OR REPLACE FUNCTION refresh_dashboard_stats()
RETURNS VOID AS $$
BEGIN
INSERT INTO dashboard_stats_cache VALUES (
1,
(SELECT COUNT(*) FROM users),
(SELECT COUNT(*) FROM users WHERE last_active > NOW() - INTERVAL '7 days'),
(SELECT COUNT(*) FROM orders),
(SELECT SUM(total) FROM orders WHERE status = 'completed'),
NOW()
)
ON CONFLICT (id) DO UPDATE SET
total_users = EXCLUDED.total_users,
active_users = EXCLUDED.active_users,
total_orders = EXCLUDED.total_orders,
revenue = EXCLUDED.revenue,
updated_at = NOW();
END;
$$ LANGUAGE plpgsql;
-- Update every 5 minutes
SELECT cron.schedule(
'refresh-stats',
'*/5 * * * *',
$$SELECT refresh_dashboard_stats()$$
);
-- Simplified RPC function
CREATE OR REPLACE FUNCTION get_dashboard_stats()
RETURNS JSON AS $$
BEGIN
RETURN (SELECT row_to_json(dashboard_stats_cache) FROM dashboard_stats_cache WHERE id = 1);
END;
$$ LANGUAGE plpgsql;
Now each call is a simple SELECT to a one-row table. From 4 aggregated queries to 1 indexed query. 95% reduction in execution time and database load.
In Conclusion: Your Supabase Bill Is the Feedback Your Architecture Needs
Supabase costs aren't a mistake, but an opportunity. They force you to design more efficiently. Every extra dollar on your bill points out an architectural problem: polling where you should use websockets, N+1 queries when you should be doing joins, and full scans where you need indexes.
Many startups find this out too late. They'd rather pay an extra $200 a month than invest two days optimizing queries. This works until they scale. When you have 10,000 active users, those $200 turn into $2,000. And the problem is 10 times harder to solve with traffic in production.
The right mindset: treat every query as if it costs $1 per execution. Do you really need to query this table every second? Could you cache this result? Should it be a websocket instead of polling? Honest answers will save you thousands of dollars.
So, how many queries is your application running right now? Do you know without opening the Supabase dashboard?