Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Congrats on the launch!

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.



> We're pretty satisfied with Supabase as an open source project

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


Hi.

Do you guys spin up individual Postgres instances for people or use some multi tenant approach?


Yes, it’s a full Postgres database.


Oh cool. Are each database instance on its own instance or shared instance?

I’m just curious, how does it work


on AWS: each a separate instance

on Fly: each in an isolated Firecracker instance


Tried Supabase but currently only use their Auth.

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.


I struggle to imagine projects that can do with a db latency of several hundred ms? Something fully async maybe, any human interaction would be incredibly slow


And functions often have multiple db calls not just one. The latency would be a deal breaker no?


How far was the server from the Supabase instance?

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


Same region, different provider. Also, their JS API has to do a round trip every time you set auth credentials on the backend, so it's at least 2 round trips for a single query.


same aws region as supabase instance using a single query.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: