I like supabase very much, but their network latency in China is too high. I have tried nodes in Singapore and Tokyo. It doesn't matter as a personal blog, but I can't consider it for business purposes. I had to host it myself on Alibaba Cloud, but I had to face many complexities. I like the simplicity of supabase. Maybe, when will they be able to host within China?
We are moving to General Availability
101–106 of 106 posts
Re: We are moving to General Availability
#102Earlier quoted context omitted.
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.
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 produc…
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.
Re: We are moving to General Availability
#103I'm not supabase client, so I guess my wishes do not matter much, but I'm self-hosting it and the experience was not pleasant. They just gave me some huge docker-compose with barely any documentation about it and that's about it. My approach to self-hosting software is carefully learn about every service I'm going to run, disabling everything not needed for my use-case. That was not possible with supabase without sig…
> one golang binary which embeds everything supabase offers I understand the sentiment here, but truthfully we chose an architecture that scales , then made it as easy as possible to run. Each service has very different scaling requirements: connection poolers, auto-generated APIs, Auth servers, etc. Putting them in a single binary would trade one problem for another (IMO, bigger) problem > Also I think that I even h…
Look at Grafana Loki. They have single binary which serves many different roles. You can launch it with different flags for scalable setup, so each instance would serve a different role. Yet you can just launch one instance and it'll do it all by default. I'm using it with this approach and it works just fine for my log volume. And I have the way to scale if I would hit limits. May be it's not elegant to have multiple services in the one binary, but disk space is cheap and code does not take much amount.
> I think you're referring to the "Securing your services"[0] section right? These are all stored as env vars - perhaps that's not clear from the docs?
I'm talking about docker/volumes/logs/vector.yml. There's "api_key=your-super-secret-and-long-logflare-key" which is supposedly should be replaced by the actual logflare api key value. The guide does not instruct to change LOGFLARE_API_KEY but I guessed this key is there for a reason and should be changed.
Re: We are moving to General Availability
#104Re: We are moving to General Availability
#105Earlier quoted context omitted.
> one golang binary which embeds everything supabase offers I understand the sentiment here, but truthfully we chose an architecture that scales , then made it as easy as possible to run. Each service has very different scaling requirements: connection poolers, auto-generated APIs, Auth servers, etc. Putting them in a single binary would trade one problem for another (IMO, bigger) problem > Also I think that I even h…
Look at Grafana Loki. They have single binary which serves many different roles. You can launch it with different flags for scalable setup, so each instance would serve a different role. Yet you can just launch one instance and it'll do it all by default. I'm using it with this approach and it works just fine for my log volume. And I have the way to scale if I would hit limits. May be it's not elegant to have multipl…
> I'm talking about docker/volumes/logs/vector.yml
I've flagged this to the Logs team to fix immediately
> Look at Grafana Loki
I'll check it out thanks. My gut is that running Postgres + 4/5 other services (many different languages) is a harder beast than Loki, but understand the sentiment and we'll see what we can do here
edit:
we've fixed the yml file: https://github.com/supabase/supabase/pull/22860#pullrequestr...
thanks for flagging this. If anyone else spots things like this please feel free to open a GH issue so we can amend it asap - given enough eyeballs, all bugs are shallow