Why does a SaaS Supabase bill get out of hand?

Blaming Supabase is easy.

When a higher-than-expected bill arrives at the end of the month, the first reflex is usually to decide the service is expensive. My first reaction was close to that too.

As Ordovia grew, Supabase usage climbed to roughly 2.6 million requests per month. Then a Supabase bill of about $62 landed. On its own, $62 is not dramatic. But the number was never the point.

Why was a product without a large user base yet generating that much backend traffic?

That question mattered far more than Supabase's pricing, because the answer lived in the product's architecture.

Was Supabase expensive, or were we simply talking too much?

One of the biggest advantages of modern backend services is development speed. You want authentication: there it is. PostgreSQL: there it is. Realtime: there it is. Storage, edge functions, row level security, API — all a few clicks away.

That remarkable convenience creates a small danger: you stop feeling the cost of talking to the backend. If you were writing a REST API from scratch you would probably design each endpoint more carefully. But this is very easy to write:

1const { data } = await supabase2  .from("tasks")3  .select("*")4  .eq("user_id", user.id);

One query. What could go wrong? The problem is not one query. The problem shows up in:

• how many components run it,
• how many times it repeats,
• how many users call it,
• whether it keeps running in hidden tabs,
• how often the same data is requested again by different contexts.

The cost of a SaaS usually comes from hundreds of small innocent decisions, not from one large architectural mistake.

First big mistake: accepting polling as normal

When you want real-time data you have options. Realtime subscriptions. An event-driven architecture. Caching. Or you can ask the backend at intervals: did anything change?

That last one is polling. It is simple, it works, and unchecked it grows fast.

1setInterval(async () => {2  await refreshTasks();3}, 30_000);

It looks innocent. One query every 30 seconds. For a single user:

12 requests / minute2120 requests / hour32,880 requests / day486,400 requests / month

And that is only one polling loop. If tasks, calendar, habits, notifications and other domains each poll separately, the number multiplies.

The user does not even have to be using the app. Tab open. Phone in the background. Desktop app running. Polling continues.

“Cloud-first” does not mean “pull everything from the cloud constantly”

Ordovia became cloud-first over time, for good reasons: I wanted a consistent experience across phone, web and desktop. A task created on one device had to appear on another. The calendar had to stay current. Notes had to sync.

But there is an important distinction here:

1cloudFirst !== cloudEverySecond

Cloud-first: the cloud is the source of truth. Cloud-every-second: keep asking the backend whether the user did something.

They are not the same. When I design a system today I ask this first:

1type SyncQuestion = {2  changed: boolean;3  reason: "user_action" | "remote_event" | "visibility" | "scheduled_refresh";4};

Why is this data being fetched again? Is there a real chance it changed? Or are we just asking in case it might have?

Second mistake: mistaking component lifecycle for a data strategy

There is a mistake that is very easy to make in React. A component mounts:

1useEffect(() => {2  loadData();3}, []);

Then another component does the same. Then another route. Then a context. Then a modal. All of them may be querying the same table.

Components that look independent in the UI are not independent to the backend. If they all want the same user data, they are all consumers of the same data domain. So data access should be centralised as much as possible.

Bad

1function TodayTasks() {2  useEffect(() => {3    fetchTasks();4  }, []);5}6
7function UpcomingTasks() {8  useEffect(() => {9    fetchTasks();10  }, []);11}12
13function TaskSidebar() {14  useEffect(() => {15    fetchTasks();16  }, []);17}

Better

1const tasks = useTasksStore();

with the store:

1const tasksStore = {2  data: [],3  lastFetchedAt: null,4  stale: true,5};

The question shifts from “should this component fetch?” to “is this data actually stale right now?” That small mental change can move backend traffic significantly.

Third mistake: treating cache as only a performance optimisation

Cache is usually explained as “make the page open faster”. True, but incomplete. Cache is also a cost control mechanism. If a user asks again for data they received ten seconds ago, you may not need to go to the backend at all.

Even a simple stale time makes a difference.

1const CACHE_TTL = 5 * 60 * 1000;2
3function shouldRefresh(lastFetchedAt: number) {4  return Date.now() - lastFetchedAt > CACHE_TTL;5}

Five minutes is not right for every kind of data, but the principle matters. Every data domain should answer these four questions:

1interface CachePolicy {2  sourceOfTruth: "cloud" | "local";3  staleAfter: number;4  invalidateOn: string[];5  refreshOnVisibility: boolean;6}

If you define none of them, the app naturally drifts toward this model:

1await fetchEverything();

Fourth mistake: refetching everything on every change

A task is completed. The UI behaves like this:

1await completeTask(taskId);2await refetchTasks();3await refetchProjects();4await refetchStats();5await refetchToday();6await refetchAchievements();

One user action, six backend calls. Later the XP system arrives. Then the calendar. Then notifications. The system cost of completing a task grows without anyone noticing.

Instead, model the effect of the mutation explicitly.

1type TaskMutationEffect = {2  task: true;3  project?: true;4  stats?: true;5  rewards?: true;6};

Then only the required domains are invalidated. Better still, return the updated canonical state from the server where possible.

Fifth mistake: letting an invisible app keep working

A browser tab can sit in the background. A PWA can be minimised. A desktop app can stay open for hours. So this check should not be underestimated:

1if (document.visibilityState !== "visible") {2  return;3}

It does not solve every polling loop, but it can sharply reduce moving data for a UI nobody is looking at. In apps like Ordovia, which stay open for long stretches, these details matter more and more.

A cost problem is really an observability problem

My real trouble was not the bill; the bill was only a symptom. The real problem was that I did not know, visibly enough, which app behaviour produced how many requests.

As a product grows, these are the metrics to watch:

1interface BackendTelemetry {2  requestsPerUser: number;3  requestsPerSession: number;4  requestsPerRoute: number;5  requestsPerFeature: number;6  cacheHitRate: number;7  mutationCount: number;8  realtimeConnections: number;9}

“We made 2 million requests this month” is not enough information on its own. The real question is why. If 1.5 million of those 2 million come from one visibility polling system, the fix is obvious. But if you do not measure, you only guess.

Should I leave Supabase?

That was not my conclusion. When an infrastructure cost rises, switching services feels very attractive. Supabase expensive? Move to Firebase. Firebase expensive? Let's do Cloudflare D1. Then something else.

At that point I realised that changing technology sometimes moves architectural debt elsewhere instead of solving the real problem.

1badArchitecture * cheaperInfrastructure

can still be a bad system — and once you add the migration cost, an even more expensive one. So today I follow three steps first:

1const optimizationOrder = [2  "measure",3  "fix architecture",4  "then evaluate infrastructure",5];

Measure first. Then cut unnecessary consumption. Only then evaluate pricing.

Why Cloudflare interests me here

What appeals to me about Cloudflare is not only that it is cheap. If significant parts of the app already run on Cloudflare, these can sit on one operational surface:

• edge caching,
• Workers,
• Pages,
• R2,
• various API layers.

But the same principle applies:

Infrastructure should be used to simplify, not to create a new hobby project.

Rewriting a working Supabase system into D1 + Workers + custom auth to save a few dollars can very easily stop being an economic optimisation and become engineering entertainment. I would rather not fall into that trap.

What would I do if I built the same system today?

I would define a sync policy per domain from day one. For example:

1export const syncPolicies = {2  tasks: {3    staleAfter: 5 * MINUTE,4    refreshOnFocus: true,5    realtime: true,6  },7  calendar: {8    staleAfter: 10 * MINUTE,9    refreshOnFocus: true,10    realtime: false,11  },12  profile: {13    staleAfter: 60 * MINUTE,14    refreshOnFocus: false,15    realtime: false,16  },17} satisfies Record<string, SyncPolicy>;

Then I would route the whole network layer through those policies. I would not let components talk to the database directly. And from the first week I would make this metric visible:

1requests / active user / day

Because as user count grows, total request count is simply a consequence of it.

The most important lesson

My Supabase bill taught me very little about Supabase. It taught me something about my own product:

Complexity you hide from the user does not disappear. It comes back somewhere as cost.

Sometimes that cost is UX. Sometimes technical debt. Sometimes latency. And sometimes it really is the bill.

The speed modern platforms provide is genuinely valuable. I still believe tools like Supabase give small teams and independent developers extraordinary leverage. But leverage works both ways: it accelerates a good architecture and it accelerates the cost of a bad one.

So when I choose a backend today, my first question is not “which one is cheaper?” It is: “why, when and how much will my app talk to this backend?” Most of the time, that is where the real answer to the bill lives.