This question is bigger than just Redwood, but I figured some people here might have some helpful thoughts.
I’m interested in deploying on Vercel but I’m worried about the scalability of using Postgres as a backend due to the overhead of database connections for each request. I know Prisma recommends using a connection pool such as pgbouncer, but even that sounds like it might not be good enough. I know Aurora Serverless has a Data API but it is not yet supported by Prisma.
Has anyone actually experimented with this or had any luck in production?
The production RW apps I know of all use Postgres. Making sure that your DB and your API lambda functions are all deployed in the same geographical location (like having it all on AWS us-east-1), and, as you say, using a connection pooler both go a long way to making DB access performant.
But I’m super interested in knowing where the limits are. What you could do is set up a basic app and run some load tests. If you do, and share the results, it’s something that would benefit the whole community. But only if you want, of course no pressure
I would love to be using connection pooling! Tons of years ago we were required to do it with our Java code. All of my attempts so far have failed.
I tried using these connection Urls with different combinations of Supabase pooling (session, transaction, statement) Statement seems to be the best option.
Note: If your project is very old, it may not have this option. You will have to create a new one and migrate over.
The docs in Redwood didn’t say that specifically (since their setup could change and they are the primary source for setup and config) but did link to the Supabase site with
I just created a new DB on SupaBase and connect to it using the connection pooling url. Works great!
But what’s RW’s solution to the migration issue?
Prisma Migrate uses database transactions to check out the current state of the database and the migrations table. However, the Migration Engine is designed to use a single connection to the database, and does not support connection pooling with PgBouncer. If you attempt to run Prisma Migrate commands in any environment that uses PgBouncer for connection pooling, you might see the following error:
Error: undefined: Database errorError querying the database: db error: ERROR: prepared statement "s0" already exists
To work around this issue, you must connect directly to the database rather than going through PgBouncer. How to achieve this depends on your setup or provider:
There is an open issue for this on Prisma’s GitHub and another issue explaining the problem in more detail. You’ll see a familiar face in the first link:
The workaround I was thinking of for now, is to override the database url in the migrate command only like:
in my CI
DATABASE_URL=$MIGRATE_DB_URL yarn prisma db migrate prod
