Comment by 999900000999 | Hacker News Reader

Comment by 999900000999 | Hacker News Reader

>Supabase is currently used by two million developers who manage more than 3.5 million databases. The startup supports Postgres, the most popular developer database system that’s an alternative to Google’s Firebase. Supabase’s goal: To be a one-stop backend for developers and "vibe coders."

How many of those users are paid. You can sign up for free without a credit card.

It's cool, for certain use cases. I ended up trying it for a few months before switching to Django.

If you ONLY need to store data behind some authentication, and handle everything else on the frontend, it's great. Once you need to try some serverside logic it gets weird. I'm open to being wrong, but I found firebase phenomenally more polished and easier to work with particularly when you get to firebase functions compared to edge functions.

Self hosting requires magical tricks, it's clearly not a focus for them right now.

I hope they keep the free tier intact. While it's not perfect, if your in a situation where you can spend absolutely no money you can easily use it learning ( or for portfolio piece).

> Self hosting requires magical tricks

Has anything changed recently? ~1year ago I installed a local instance (that I still use today for logging LLM stats) and IIRC all I had to do was "docker compose up". All the dockers are still starting for me at boot from that 1yo install, to this day. (I use it on 127.0 so no SSE & stuff, perhaps that's where the pain points are? Dunno, but for my local logging needs it's perfect).

Hosting it on an actual server with a URL is not a fun experience. You need to generate a specific type of string to get it to work.

This isn't documented anywhere. Deep deep in their GitHub issues you'll find a script for generating this magic string which needs to be set as an environment variable.

See https://github.com/supabase/supabase/issues/17164#issuecomme...

Looks like it is just an issue of correctly making a jwt token, if you are not using their client libraries, but you can also just do it via their docs https://supabase.com/docs/guides/self-hosting/docker#generat... now (not sure how long you've been able to do in the docs)

Sure "it's in the docs" but last time our devops tried the compose file with ~10 or so services it took several days of fiddling with all sorts of different issues. It is just not made for selfhosting at all. It can be so much simpler but JS devs like it different.

It can be set up in a day if you slap traefik infront of it, change the env and compose files a bit and run it with docker compose.

I admit, I already had a working mail server and wildcard LE cert... let's say you'd need the other half of the day too to set that up if wanted.

Personally I set it up in a way such that the studio is not publicly accessible but can be accessed using ssh port forwarding.

All in all, I still agree that it's not really user friendly to self host it. It's basically only one supabase project. But in reality, it shouldn't be that hard to create new template dbs in postgres to set up multiple projects and also provide a good UI for that. They don't bother to provide that functionality though for I believe obvious reasons.

Try using your own certificates. It's easy with Deno (for example) but as far as I could tell impossible with Supabase. Certainly it's undocumented, and that's a huge problem if you want to do real development.

If you are self hosting it, at least put a reverse proxy of it infront to control what is actually accessible. You can easily slap a traefik infront and get LE certs automatically, then terminate TLS at that level.

It has gotten a bit better lately, but it's still a pain.

Just recently the docker-compose stack from the current main branch would not start properly, because someone committed a faulty health check. Why does this make it to the main branch, does nobody there review PR?

Starting a new stack is nothing compared to maintaining it. Upgrading to newer images requires carefully checking which environment variables suddenly appeared in new versions or maybe were renamed. Upgrades never really went absolutely smooth for me in the past.

It’s normal Postgres. There’s no need to handle everything on the front end. The tutorials nudge you to learn RLS and use their SDKs for the client, but you can write perfectly normal server side code as well.

Yeah I’ve ran a small project where I just did everything with the “service account” credentials which operates like a normal Postgres connection.

If you're not supporting users, it's fine.

But if you usecase involves Supabase auth, using a service account to bypass RLS is kind of like hardcoding connection strings.

You can use both properly and together.

The service account should only be accessed on the service.

If using Auth+Server, you can check the verified user identity via Auth JWTs (or something, see the docs).

Yeah, don't use the server connection on the client, but they have many warnings against that.

I literally use it because it's a free hosted postgres database. I just connect via connection string on my backend and run the queries there.

Yeah, it's a bit wonky, especially when you are dealing with configuring specific combination of supabase/deno/typescript features (e.g. stage 2 vs stage 3 decorators)

How is Djanjo a replacement for Supabase?

For my current project I basically need a backend server for processing some basic game logic.

I had done something similar in Firebase and it was easy. Supabase wasn't straightforward here. It got to a point where I'm sure I could eventually get it working, but I also think I'm outside the expected usecase.

Django is much more flexibility in this regard.

Reply on news.ycombinator.com