Using SQLAlchemy with Supabase #27071
Replies: 2 comments 5 replies
-
Could you clarify on this statement?
Why should we use the nullpool setting? I'd imagine having some client side pooling can help with limiting connection counts. |
Beta Was this translation helpful? Give feedback.
-
I have some questions about the recommended practices for sqlalchemy with supabase for a typical fastapi docker backend+autoscaler setup: Context: Since the number of running instances can be very high and every instance has several uvicorn workers, connecting directly to the database seems like a bad idea in this scenario, especially if we consider that there are background workers+postgREST clients connecting to postgres as well. We also need to be able to connect to the server using ipv4. To avoid reaching the connection limit, we configured supavisor to operate in transaction mode and followed the guidelines above on how to set up sqlalchemy for this case. However, using the How would you procede in this case? As you mentioned in your response above, I understand that using the QueuePool can be dangerous as the connection can be retired after some period of idleness, but taking a 4x latency increase is also undesirable. Could using Thanks in advance! |
Beta Was this translation helpful? Give feedback.
-
Deploying to auto-scaling servers:
If you are deploying to:
It is recommended that you connect with the pooler in transaction mode (port 6543), which can be found in the Database Settings:
# Example transaction mode string: postgres://[db-user].[project-ref]:[db-password]@aws-0-[aws-region].pooler.supabase.com:6543
When using transaction mode, you should use the NullPool setting:
When relying on Supavisor, it's important to pick an adequate pool size. This guide can walk you through the process:
Deploying to stationary servers
For stationary servers, such as VMs and long-running containers, it is recommended to use your direct connection string, which can be found in the Database Settings
The connection maps to an IPv6 address, and cannot operate in an IPv4 environment.
Checking IPv6 Support:
The majority of services are IPv6 compatible. However, there are a few prominent services that only accept IPv4 connections:
If you're still unsure if your network supports IPv6, you can run this cURL command on your deployment server:
If the command returns an IPv6 address, the network is IPv6 compatible.
If your deployment environment is not IPv6 compatible, then consider:
Choosing an internal pool size
Key Pool Settings:
max_overflow: Allows creating additional connections beyond pool_size for temporary bursts in demand. These temporary connections close after use.
As a rule of thumb, if you're using the Supabase Database REST Client, try to limit the connections used by your deployment to 40% of available connections. Otherwise, you can cautiously increase usage to around 80%. These percentages are flexible and depend on your application's usage and setup. Monitor connection usage to determine the optimal allocation without depriving other servers of necessary connections.
How to monitor live connections
Connection usage can be monitored with a Supabase Grafana Dashboard. It provides realtime visibility of over 200 database metrics, such as graphs of CPU, EBS, and active direct/pooler connections. It can be extremely useful for monitoring and debugging instances.
You can check our GitHub repo for setup instructions for local deployments or free cloud deployments on Fly.io. For a complete explainer on connection monitoring, you can check out this guide
Beta Was this translation helpful? Give feedback.
All reactions