-
Notifications
You must be signed in to change notification settings - Fork 253
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reusing types from Supabase #461
Comments
This is nice! But I haven't decided whether to keep generating the schema via Kysely. What dialect adapter are you using? Have you written a driver? The driver looks like it might be complex enough that it ought to be its own repo, if not included with Kysely itself. |
AFAIK you can use |
I have Kysely working with Supabase using pg's So I think all we need is a non-pooling Postgres driver for Kysely, one that uses pg's |
I guess I could just be using a max pool size of 1, but if that's all I need to do, I wonder why pg bothered to provide a single-connection |
I posted the question on Stackoverflow and have so far received two comments:
|
A single lambda function instance, if keeps receiving requests, can stay alive for 2-3 hours. |
I'm not sure what to do with this. I don't think Lambda or Vercel will throttle when all connections in the pool are in use. I think each HTTP request has to open and close its connection. Here's something else. At present, to use Kysely with Supabase, we have to use the postgres protocol. But that protocol is not secure by default. In fact, Supabase has this to say:
This has me wondering if Kysely (or any ORM) should even be used with Supabase at this time. |
Okay, I've learned that multi-query transactions have to use Supabase's direct postgres port, which does not pool DB connections, while non-transactional queries are free to use Supabase's pgBouncer port, which pools connections. So we do need a special Supabase adapter. I might as well code it to use pg's single-connection UPDATE: I'll write this tomorrow. I'm seeing people have trouble with local development when they assume only a single connection, so I'll support connection pooling as well, using |
I'm backtracking. Supabase provides a "transaction" mode on its pgBouncer port, which preserves a pg connection for the duration of a transaction, but not across multiple transactions. A Supabase client therefore is not necessary. However, I've looked through the node-postgres code for pooling, and it's quite a bit on top of also creating individual client connections. The thought of doing this unnecessary work on each HTTP request is driving me crazy, so I'm inclined to create a serverless postgres dialect anyway. I'll leave it to the app to decide whether to use the native pooling dialect or this serverless dialect for rigid single-connection access. Also, I noticed that Supabase automatically gives me an SSL cert for postgres connections, so the doc I read must be out of date, as it seems it's not necessary to contact support to enable this feature. |
@gilbert where did the |
@o-az Kysely. |
Just in case anyone needs it, here's how to reuse your generated Supabase types for Kysely:
This transforms e.g. the following Supabase type:
into the following for Kysely:
Not sure if it's perfect but it's a great starting point!
The text was updated successfully, but these errors were encountered: