Delay to access the database

[michael]

Hey there!

I'm just checking out the supabase slack clone example, and I've found that there's a quite a bit of delay before the queries come back.

I think this is due to the example being deployed on vercel which needs to talk to (possibly) far away Supabase. Is this something you are thinking of addressing?

I'm searching for a good serverless solution for SQL, and the prospect of using a ready made solution for signup etc sounds promising. Here's a related thread to what I'm looking for: https://github.com/vercel/vercel/discussions/5696

Thanks much!

Michael

[kiwicopple]

Hey @michael. Lee shared the discussion with me, nice to see you here too.

Are you deploying the database and frontend in the same region as discussed in that thread? It looks like they are deploying to US_EAST now, and you you can do the same for our database.

Also note that there is some warmup on serverless functions, but once they are going it should be faster

[michael]

Hi Paul! Thanks for your responses. You are on a great mission btw! 😊

I took Supabase for a spin and I have a few more questions:

In the examples all requests are made from the client. It pretty much exposes the structure of the database. I feel that this could be a security issue. The way I had in mind for using Supabase would be from serverless functions (deployed on vercel). Is that a bad idea as it adds another layer and may compromise performance? The good thing would be that I can "hide" the low-level backend details from the client. Errors like "new row for relation "todos" violates check constraint "todos_task_check" is something I don't want to see on the client. 🥴

How do you deal with migrating the database? I'm a bit worried that using the Admin panel (which is handy) leaves me running out of sync with my incremental schema changes (I do migrations just as manual SQL scripts). Can you export the current schema as sql create statements from the interface? Would you recommend me in my case to do schema changes with SQL instead of the UI?

Do you think using Row-level security policies would make sense for me, even when going with Postgres directly. I find it a promising concept but I'm hesitant to jump on it immediately. I'm a solopreneur at the moment, so i really need to spend my time wisely and "just get the product to a stable launch" ;). Also I have the rule to use the least possible amount of concepts needed to build the system reliably. Makes it easier for other dev's to onboard. I don't need realtime, just fetch data as the user interacts.

Lastly could you do me a great favor and check out my current signup flow and let me know if you could build that same thing using Supabase (haha this is a very smart way to trick you into signing up to my platform, right ;))?

https://www.letsken.com/signup

Thanks a lot for your time!

[kiwicopple]

In the examples all requests are made from the client. It pretty much exposes the structure of the database. I feel that this could be a security issue.
The way I had in mind for using Supabase would be from serverless functions (deployed on vercel).
...
Do you think using Row-level security policies would make sense for me, even when going with Postgres directly.

It sounds like you want to roll your own data access which is 100% doable with Supabase. Just enable RLS, but don't add any policies. This will restrict anonymous access to your database. Then you can use the service_key, which can bypass RLS and access the data from the serverless functions.

How do you deal with migrating the database?

We're "just" postgres, so you can use whatever tool you currently use. You can access the Postgres connection details from the settings in the dashboard. We are working on a CLI now which will hopefully include migrations.

Lastly could you do me a great favor and check out my current signup flow and let me know if you could build that same thing using Supabase

I can't read it 😂 . But our Auth is quite feature-full! https://supabase.io/docs/guides/auth