Your Supabase app says "too many connections" — here's what that actually means

Why did my app work an hour ago and not now?

Your app was fine. Now people are messaging you. The page loads but nothing appears, or the login spins forever, or a red box mentions something about connections. Nothing you did caused this and nothing you click fixes it.

Your database can hold a fixed number of open conversations at once. Not requests per second — conversations. Each one is a door that stays open while it is in use.

Your app opened doors faster than it closed them, and eventually there were none left. When the next person arrived, the database turned them away. It did not lose your data. It ran out of seats.

What do the exact error messages mean?

The message rarely says anything as friendly as "too many connections". You are more likely to see wording about remaining connection slots being reserved for non-replication superuser connections, or a blunt "sorry, too many clients already". Both mean the same thing: the room is full.

Supabase's own support docs describe the first one in a line: it usually occurs when the database reaches the maximum number of connections allowed based on the compute add-on.¹ Translated: your database hit its own ceiling, and that ceiling depends on the size of the machine you are paying for. Their guidance for both messages is the same — use the waiting-room address instead of the direct one.²

The reason it mentions superusers is that the database always keeps a couple of seats in reserve for its own staff, so the people who maintain it can still get in when everything is full. That reserved-seat wording is why the message sounds like it is about permissions. It is not. It is about capacity.

How many connections do I actually get?

Supabase publishes two figures for each machine size. One is how many direct conversations the database will hold. The other is how many visitors can queue up in front of it in the waiting room.⁴ The same pairs appear on their pricing page.⁵

So on the free plan or the smallest paid machine, your ceiling is sixty open conversations. Sixty is not sixty users. A single badly-behaved page can hold four or five of those doors open on its own. Sixty is closer to a dozen people using the app at once, if your app is careless about closing up behind itself.

Why does this hit AI-built apps so often?

Not because your app is bad. Because of a default nobody showed you. Supabase gives you more than one address for the same database.

One is the direct address, where every visitor takes their own seat. The other is the waiting-room address — Supabase calls the waiting room a connection pooler, meaning a small program that sits in front of the database, holds a handful of seats and lends them out for a moment at a time.⁶

Supabase explains the difference with a chess tournament: sixty boards, and a player sitting down at a board is a visitor connecting to the database. When the tournament fills up, new players are turned away and told to check back later. Then the organisers expand the venue to hold two hundred people without adding tables, so nobody has to leave — they wait in the wings and take a board the moment one opens.⁷

If your app is pointed at the direct address, there is no waiting area. Sixty players, sixty boards, and the next person is told to come back later. That person is your user.

The other common cause is code that opens a door for every single visit and never closes it. This is easy for an AI tool to write, because it is not wrong — it works perfectly at ten users and fails at eighty, and the failure arrives on a Tuesday afternoon rather than as a bug report.

How do I fix it?

1. 1
   Wait a minute before changing anything

   These pile-ups often clear themselves as old conversations time out. If the app comes back on its own, you have not fixed it — you have confirmed the diagnosis. It will happen again at the same amount of traffic.
2. 2
   Check which address your app is using

   In the Supabase dashboard, look at the connect or database settings screens. If the address your app uses does not include the word pooler, that is your headline problem — and it is the first fix Supabase recommends for exactly this message.²
3. 3
   Hand the job to the tool you built with

   If you built with Lovable, Bolt, Replit, v0 or Cursor, this is a change your tool is genuinely good at making. Paste the prompt below.
4. 4
   Resist raising the ceiling first

   You can raise the number of allowed connections, but Supabase warns twice about it. Configuring the count manually hard codes it, so if you upgrade or downgrade your database the count will not auto-resize and you have to update it yourself.³ And allowing too many direct connections can overburden Postgres schedulers and other internal modules, resulting in a noticeable decrease in query throughput despite having more connections available.³ In plain terms: adding chairs to a room with one waiter makes the meal slower for everybody.
5. 5
   If you are genuinely at capacity, buy a bigger machine

   That is the honest answer once the waiting room is in place and connections are being released properly. The table above tells you what you get for it.

My Supabase database is refusing new connections with "remaining connection slots are reserved". Switch every database call to the pooled connection string from my Supabase settings, use one shared client instead of creating a new one per request, and make sure every connection is released after use.

Why did I find out from a user instead of a tool?

The technical fix here is an afternoon. The part that stings is different: your app was refusing people for however long it took someone to bother telling you, and everyone who hit that screen before them just left.

That is a watching problem, not a database problem, and this failure is a nasty one to catch. Your homepage may load perfectly while the database turns people away, because the front page is often just files on a server. Anything that only checks whether your site loads will report all clear while your signups are dead.

Which tool should watch my app?

The engineering tools give you more knobs and more places to check from, and if you want fine-grained control they are the right choice. Fomio gives you a sentence you can act on and a prompt you can paste, which is what this particular failure needed.

On the free plan, Fomio watches one app from outside, checks every five minutes, emails you when it breaks and keeps seven days of event history, with no card needed. Builder watches three apps, checks every minute, keeps thirty days and includes the fix prompts. Pro watches fifteen, keeps a year and gives your users a public status page. Being told happens by email. Current prices are on fomio.ai/pricing.

What should I do today?

Open your Supabase settings and look at whether your app is talking to the pooled address or the direct one. If it is the direct one, that is your fix, and your AI tool can make the change from a single prompt.

Then put something in front of your app that watches a page which touches the database. The next time the seats run out, the message should come to you, not to your users.