feature | start-date | author | co-authors | related-issues |
---|---|---|---|---|
Connection Pooling |
2021-02-04 |
kiwicopple |
steve-chavez, dragarcia |
(will contain links to implementation PRs) |
We would like to explore connection pooling on Supabase. This RFC is intended to decide:
- Whether we should provide a pooler
- Which connection pooler we should use
- Where in the stack it would be installed - i.e. if should bundle it with the Postgres build
In Postgres, every connection is a process. Because of this, a lot of connections to the database can be very expensive on memory.
When connecting to Postgres database from serverless functions, there is no connection pooling, and so the server needs to maintain hundreds/thousands of connections.
This is still in the "Gather Feedback" stage. To start the discussion:
pg_bouncer
- https://www.pgbouncer.org/PG Pool II
- https://www.pgpool.net/mediawiki/index.php/Main_Pageodyssey
- https://github.com/yandex/odyssey- others?
Most poolers allow different configurations. We would need to decide on how we would configure the pooler by default
Should a user be able to change the configuration? If so, how would they do it?
- Security
- Not directly relevant to the "supabase" stack, so it's additional non-core support
- Since we already offer PostgREST and postgres-meta, this isn't entirely necessary for the Supabase stack. Bundling this is only beneficial for connecting external tools.
- We could hold back on this implementation until we move to a full Postgres Operator, which would include a pooler. It would be nice to have something for local development though.
- Add any unresolved questions here
- Add any future work here