(no title)
jmeyer2k | 1 year ago
Here's our experience with Supabase at https://automark.io (Next.js + Supabase).
- First of all, Supabase let us launch fast which was amazing. Super powerful Postgres features without the pain of self-hosting (or so we thought).
- We started out using their hosted product for both our DB, storage, auth, and functions.
- Functions have a critical bug that prevent us from using in development so we decided to move to our own API servers: https://github.com/supabase/edge-runtime/issues/212
- Now, the connection between our API servers and the database was slow (a few hundred ms per query), so we moved to self-hosting Postgres which was pretty painful. We tried to use https://github.com/supabase/postgres, but the documentation was very lacking and we had to make a bunch of modifications to get it to work. After we got it working, it was pretty smooth though - pretty easy to implement backups, etc.
- Our latest issue has been around auth where the cookie name options change. We've spent hours debugging random cookie issues deep in the auth framework (they finally released `@supabase/ssr` which is pretty decent, but we're still thinking about moving to handling auth on our side so we know and can debug the logic).
One thing to mention: although our requirements didn't quite fit Supabase and we ran into these issues, we weren't locked into their hosting. We were able to completely move off of it over the course of a few weeks, but continue using the self-hosted version. This is a huge benefit over something like Firebase or Amplify. We're pretty satisfied with Supabase as an open source project, but not as satisfied with Supabase hosting.
kiwicopple|1 year ago
As an open source company, we'll take that as a mark of success.
Thanks for the details, I'll jump into that GH issue with the Edge Functions team after this week
moomoo11|1 year ago
Do you guys spin up individual Postgres instances for people or use some multi tenant approach?
k_vi|1 year ago
The server to database latency was very high(few hundred ms) whereas Planetscale DB in the same region gives sub 10ms.
Still great option for most projects that can do with these issues.
williamdclt|1 year ago
wirelesspotat|1 year ago
I have a toy project with a server on Fly.io and the DB on Supabase within the same city
When sending API requests to the server, my end user latency was around 25ms-100ms (depending on the endpoint and how many DB calls it was doing)
Now with Supabase on Fly, that API latency is down to 17ms-70ms. But Supabase on Fly is still in alpha so it's not relevant for production yet