Skip to content

Latest commit

 

History

History
71 lines (43 loc) · 2.16 KB

0001-connection-pooling.md

File metadata and controls

71 lines (43 loc) · 2.16 KB
feature start-date author co-authors related-issues
Connection Pooling
2021-02-04
kiwicopple
steve-chavez, dragarcia
(will contain links to implementation PRs)

Summary

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

Motivation

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.

Detailed design

This is still in the "Gather Feedback" stage. To start the discussion:

1. Decide on a PG Pooler

2. Decide on configuration

Most poolers allow different configurations. We would need to decide on how we would configure the pooler by default

3. Decide if the user should be able re-configure the pooler

Should a user be able to change the configuration? If so, how would they do it?

Drawbacks

  • Security
  • Not directly relevant to the "supabase" stack, so it's additional non-core support

Alternatives

  1. 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.
  2. 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.

Unresolved questions

  • Add any unresolved questions here

Future work

  • Add any future work here