To avoid frequent connection errors and get better performance from your Supabase PostgreSQL database, we recommend enabling connection pooling by switching to port 6543.
If you’ve been experiencing connection issues or performance instability in your Glide app, the likely cause is hitting PostgreSQL's maximum connection limits. Fortunately, PostgreSQL provides a built-in solution: connection pooling via pgBouncer.
To enable connection pooling, just update your database connection settings in Glide and use port 6543 instead of the default 5432. This small change can make a big difference.
Why Use Connection Pooling?
Here are the key benefits:
1. Drastically fewer open connections
Without pooling: Each client opens its own database connection, quickly eating up your connection limit.
With pooling: Dozens or even hundreds of clients can share just a few pooled connections.
Impact: Prevents “max_connections” errors and improves app stability under load.
2. Faster, more consistent connections
Pooled connections are already established—no need to renegotiate SSL, authentication, or other overhead.
Impact: Your app connects faster and more reliably, especially in serverless environments like Vercel or Netlify.
3. Handles traffic spikes gracefully
Without pooling, bursty usage (e.g., opening multiple tabs) can overwhelm your database.
pgBouncer smooths out spikes by queuing or reusing connections.
Impact: Your app stays responsive, even with sudden user activity.
4. Better performance in client-heavy apps like Glide
Glide may send multiple queries simultaneously for collections, filters, or actions.
Pooling lets these queries reuse existing connections.
Impact: Apps stay responsive, even with moderate to heavy usage.
5. More value from limited Supabase plans
Free and Pro Supabase tiers limit concurrent connections (e.g., 20–100).
Pooling helps you stay within those limits while supporting more users.
Impact: Serve more users without needing to upgrade your Supabase plan.