We are moving to General Availability

> 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 had to edit some configs for api keys or something like that. It should not be like that, everything should be passed down via envs.

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?

[0] https://supabase.com/docs/guides/self-hosting/docker#securin...

Look how nicely davetron5000's comment below can be read. Proper capitalization makes text much more readable.

> the good stuff, the useful stuff was behind the cloud subscription paywall

can you share more? everything is open source, the code available, and all OSI-compliant

> Much of the logic should be server side also for security reasons and that wasn't possible when I tried it.

This is possible in very many ways:

    1. Write an RPC function and use PostgREST

    2. Use Edge Functions

    3. Use whichever frontend framework you are developing with (they all integrate well with supabase)

    4. Connect a server directly to the Postgres data ase in a 3-tier architecture

> I think the appeal is to people who like doing frontend but don't like doing backend.

Perhaps! We also have a large number of customers using us as a traditional Postgres host. And we have a lot of "Postgres maxis" who love the RLS + PostgREST combo. You choose your level of comfort with Postgres: https://supabase.com/docs/guides/platform/shared-responsibil...

My feedback on Supabase: I would like to see a separate PGS offering instead of it being bundled with your other services. I already pay Vercel for hosting and functions, so the problem is already solved there. I can't move my hosting and functions because of the first-class support for Next.js by Vercel (vendor lock-in is strong here). I use Firebase for authentication, which is free for unlimited MAU. The only thing I'm looking for is PGS. I know the current cost is not much even if your other services are bundled together, but that may not be the case in the future. A separate PGS offering makes more sense for users like me.

I've tried briefly both, but mostly selfhosted versions. If you're interested only in managed versions then skip this comment.

Both have docker based setups and getting them up and running is documented clearly enough.

The biggest difference right off the bat (ignoring PosgtreSQL vs MariaDB) is that Supabase selfhosted just gives you default project and that's it. If you want to host several projects you either spin up new instance or make use of table prefixes. With Appwrite you can create new projects that are independent of each other, including auth. You can have organizations -> projects -> databases granularity. For sideprojects that's a huge win for me.

Supabase gives you a way to run raw SQL on your tables via web interface which I really like, it gives a better way to gain insights into your data without wrestling with client side queries which may or may not do what you need. Appwrite doesn't have that, you have to make do with their queries.

Documentation is fairly fragmented in both, code snippets and examples have not been updated for changes, some new features are only discoverable via search but not via documentation menu e.g. Appwrite's SSR documentation. Most complete documentation in both seems to be for Javascript. I managed to get auth working, but it may require some head scratching, especially if you want to use something different than their default examples.

Appwrite gives you shell scripts for backup/restore right there in the documentation, Supabase does not. It's not anything fancy, but it's nice to have. There are no ways to generate backup from Supabase web interface either so you have to write your own scripts.

Appwrite gives you basic dashboard of stats for your databases and simple charts for traffic and requests, Supabase selfhosted lacks that. Managed version has reports so they're clearly withholding this in purpose.

The thing that made me not want to go with selfhosted Supabase in the end though was constant CPU usage when idling. Some usage is expected, but even on my workstation the load stays around 5-8% and is frequently peaking up to 12% or more. In contrast Appwrite stays between 0.6-3%. On my VPS idle peaks are up to 25% which is wild. The culprit seems to be Supabase analytics and health check which logs agressively and spams console several times per second. IIRC there was open issue about it but the response was "maybe disable health-checks then". This coupled with just having one single project makes it not suitable for self hosting for me. Haven't used functions or realtime in neither so can't comment on that. Overall Appwrite's self hosted solution is more polished, but YMMV.