We are moving to General Availability

by jimmcslim • 2 years ago

272 100 2 years ago

kiwicopple21• 2 years ago

hey hn, supabase ceo here

we just announced GA, after ~4 years of beta. for those who don't know: supabase is a postgres hosting company. we also host other open source "backend" tools that make it easy to get started with postgres (tools like PostgREST for auto-generate APIs [0])

we owe a lot to the HN community. you launched us 4 years ago [1], when we were just a few developers. since then HN has been a staple in our journey, one of the best sources of product feedback [2]

the GA badge is mostly to signify organizational readiness. we're at a stage where we can take any profile of customer. we have a support team that works 24/7, and a success team that will help customers improve their postgres usage. we released our Index Advisor [3] yesterday, and we'll be releasing a few more products this week that helps customer with performance and security.

on a personal note: i read HN most days, and love going through the ShowHN's to see what devs are building. thanks for being an awesome community and my favorite place to lurk on the internet. i'll stick around to answer any questions

[0] PostgREST: https://postgrest.org

[1] Launch: https://news.ycombinator.com/item?id=23319901

[2] HN journey: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

[3] Index Advisor: https://news.ycombinator.com/item?id=40028111

psnehanshu• 2 years ago

When did the positioning of Supabase changed from a "Firebase alternative" to a "Postgres hosting"?

kiwicopple21• 2 years ago

we're constantly evolving it.

at the start, the "firebase alternative" positioning made it unclear to developers who thought we offered a NoSQL database. We always wanted to be "Postgres plus useful tools" so we started evolving the positioning over the past year

you'll still see "firebase alternative" on our site: I think the comparison is apt and the aspiration remains the same

clarkbw• 2 years ago

Congrats to the Supabase team! You've all done some impressive work to be proud of.

kiwicopple21• 2 years ago

thanks for the kind words

Jabbles• 2 years ago

Why do you not use capital letters in the typical way?

Takennickname2• 2 years ago

It is a little bit painful to read. Capital letters exist for a reason (to make reading easier)

spencerchubb• 2 years ago

capital letters are atypical in many internet circles, particularly younger. so maybe it's a habit from frequenting those circles or a deliberate branding choice

benreesman• 2 years ago

I’ve just started dabbling so take this with a grain of salt.

Overall, it’s great. I recommend it to people. The high signal part is what I would work on:

- deeper integrations with common OpenID Connect providers, with a pretty foolproof “bail to browser view that looks like Kinde or Clerk”. there’s only so much you can do, but it’s not trivial to get wired up to a bunch of pick-and choose SSOs.

- prisma should be front and center, the auth/public schema split is not a breeze, Prisma slays at being an ORM, Supabase slays at other things. It’s not obvious whether or not to use realtime or Pulse.

- force the env footprint on e.g. next or expo or whatever, it’s a little glue, it’s a lot of people who don’t pop out of the funnel.

- chat / dm is a common enough use case to be in the wizard (like avatars), Postgres handles it fine for small to medium apps, and arguably for big ones

- have a pass through mode for the local deploy that’s easy to toggle, you guys are fast AF, it’s often sane to dev directly against the instance.

- I’m sure you’re already building the kind of anonymized training sets that let you spot bad configs a mile away.

Again, nitpicks on a great product. I love Supabase.

kiwicopple21• 2 years ago

this is all great, actionable feedback. Thanks for this - really nice list

jerrygoyal• 2 years ago

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.

kelsey98765431• 2 years ago

This is not a negative statement against Supabase, but heed my warning:

Do not build out your MVP on supabase. If you need to scale and want a MSP do it after the MVP. Detangling the lock in is not fun.

Everything offered by supabase is easily found elsewhere without the MSP lock in.

xytofs3• 2 years ago

What were the troubles you faced?

trolan2• 2 years ago

I've used it for a couple uni/personal projects to get some experience, and firebase for the same. I'm concerned about getting locked in, what other providers do you recommend who can let me migrate more easily?

oliverrice2• 2 years ago

I'm concerned about getting locked in

Supabase is one of the most portable platforms out there.

The whole stack is self-hostable and open source. All of the data are contained in Postgres. You're one pg_dump away from being able to switch to a different Postgres host. Or if you're switching to something else entirely, you can export the data to CSVs and take it anywhere. But we're confident you won't want to :)

disclaimer - Supabase employee

kiwicopple21• 2 years ago

You can use supabase simply as a Postgres provider. Supabase is just postgres, and you can choose to use any tool we provide (or not)

stemc43• 2 years ago

supabase, directus and similar are just wrappers on top op postgres. I just spin up local postgres instance for personal project and see no reason to get vendor locked-in myself.

tootie• 2 years ago

If it's postgres with easily available plugins, then where is the lock in?

atonse3• 2 years ago

We're using Supabase for a client project and even three sprints in, we're severely hobbled by having to play with a couple of architectural choices forced on us with Supabase and Supabase Auth. Any of the time savings benefits have been wiped out already just fighting the choices and also the subtle differences between the local dev environment, implementing RLS without good tooling.

On an architectural level, it is also terrifying to have your database exposed to the public internet just hidden behind authentication and RLS policies (which are much harder to reason about for most developers, and for which there is very immature tooling, a recipe for disaster).

Plus the local dev experience leaves a lot to be desired. We spent days trying to get file uploads working only to find that the issue was with local Supabase, and we had to create a remote Supabase database just to upload files successfully. But then we can't "reset" the database to run migrations.

The product is definitely much less smooth to develop on and I've had to provide dozens of hours of free client consulting work to untangle my recommendation of Supabase (didn't feel right to charge them to fix a product choice that I recommended to them).

Right now I'm in a strong "never again" view on this set of technologies. At least not for a long time until the tooling improves.

But it seems like there are some happy customers. So would love to hear a counterpoint of how they overcame all the issues we've faced:

- how are your security teams ok with exposing your PG server to the internet, relying mainly on RLS? And RLS isn't turned on by default, so full tables are exposed to the public internet by default, behind a rather nice REST API.

- Reliance on RLS for a public service seems risky because RLS quickly gets harder to maintain as you have to get more complex policies in place without much tooling to help you.

- how about the fact that some of your most important code, the RLS policies code, is hard to unit test with today's tooling? And they recommend pgTAP, which, who knows how big this community is?

That combination seems highly risky to me.

Our best bet right now has been to just install prisma and implement more traditional filtering on top of RLS, and just not rely at all on client side connections to postgres. So in a nutshell, moving away from Supabase specific architecture to more traditional architecture. The real "It's just postgres"

xytofs3• 2 years ago

how are your security teams ok with exposing your PG server to the internet, relying mainly on RLS? And RLS isn't turned on by default, so full tables are exposed to the public internet by default, behind a rather nice REST API.

Tooling is improving constantly and security really is at the top of mind for us. We've got some cool announcements this week that will keep reminding you if you're doing something sketchy!

listenallyall2• 2 years ago

Kinda sounds like "client side connections to postgres" was the poor decision at root of your security concerns, not the choice of provider

Difwif• 2 years ago

This isn't fair feedback. You have to be more specific about the "lock in". Supabase itself is just managed Postgres and can be self-hosted. The entire point is that everything they offer is open source and easily found elsewhere.

I can imagine they fall short in some aspects from that ideal and I would love to know your experience but even with your first sentence this is just a pretty damning write off.

Disclaimer: I'm NOT a Supabase employee, just a happy user.

BoorishBears4• 2 years ago

People keep writing this, doesn't Supabase rely on spinning up additional services to leave, meaning you can't leave to another managed offering?

Off the top of my mind, PostgREST and go-true? https://github.com/supabase/auth

If you use Postgres you're "locked" into Postgres: a technology with a laundry list of providers.

If you leave Supabase, you'll lose the fully managed aspect of 99% of the Postgres providers out there, which confirms the pain the parent comment is describing.

kwerk• 2 years ago

Congrats! Happy supabase user here

samoit• 2 years ago

I also know appwrite. It looks quite similar to me, has it the same target audience?. Is there any comparision chat? Thanks.

ihateolives• 2 years ago

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.

pastor_bob• 2 years ago

Curious to see how many of those million databases are from free users.

Feels like we're living in the golden age of free platform offerings.

Wonder when the shoe will drop.

burggraf• 2 years ago

Curious to see how many of those million databases are from free users.

A LOT! Probably most.

But Supabase is committed to the free tier and it's not going anywhere. It's crucial to helping demonstrate all the features and the DX to developers.

mattjenner• 2 years ago

I am happily using the free tier to help launch my startup. It is invaluable to me. I am a big fan of it, and have no regrets with this decision (only 9 months in). I admire what I am allowed to have for the low price of 'free now, pay when you need to'.

kiwicopple21• 2 years ago

thanks for building with supabase. good luck with your startup!

noob-4-life• 2 years ago

Awesome, the Index Advisor sped my slowest query 4x! Is there a way to run that across all queries in pg_stat_statements at once or do I need to click on each one?

oliverrice2• 2 years ago

In Studio you'd need to click on a query to get the recommendations but the most important queries to optimize are on several metrics like "Most time consuming", "Most frequent", "Slowest execution" are sorted worst-to-best in tab views.

But if you do want to scan all of your queries at once for possible indexes you can do it in SQL with

```sql

create extension index_advisor cascade schema extensions;

select ia., pss.query

from pg_stat_statements pss, lateral( select from extensions.index_advisor(pss.query)) ia

order by (total_cost_after::numeric - total_cost_before::numeric)

limit 100;

```

lbrito• 2 years ago

Any news on the integration with Fly.io going GA?

kiwicopple21• 2 years ago

it's progressing! we'll have some news on friday

benzible• 2 years ago

From a recent post by a fly.io employee in their forums [1], in response to being asked "do you expect it to be ready for production use this year?"...

Coming very soon, we’ll be moving to public alpha (which in our world, comes after private beta :smiley:).

[1] https://community.fly.io/t/supabase-managed-postgres-in-priv...

jmeyer2k2• 2 years ago

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.

kiwicopple21• 2 years ago

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

moomoo112• 2 years ago

Hi.

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

k_vi2• 2 years ago

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.

williamdclt• 2 years ago

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

wirelesspotat• 2 years ago

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

CharlesW• 2 years ago

Congrats Supabase folks! I wish you every success.

I paid $20/mo for a while because of the free tier storage cutoff (500 MB), but have since stopped. I wish you had a $5/mo tier for "small projects" folks who need a database larger than that.

For example, Cloudflare's Workers Paid is $5 for D1 databases up to 10GB, with 5GB included and 75¢GB after. I know this is comparing apples and oranges to some degree and that your business model may be incompatible with this use case, which is absolutely fair.

trevoragilbert2• 2 years ago

Happy Supabase user here, albeit on a tiny app I work on in my spare time. So no comment for larger or more complex orgs.

That being said, the Swift documentation could use some love. It’s not terrible but it’s also not great. There have been a number of times when I wanted to do something, ended up reading about it on the Supabase JS documentation, and then thought “well I assume it’s roughly the same in the Swift library.” It worked, but a pain to have to guess a lot.

kiwicopple21• 2 years ago

we just took over official support for swift: https://supabase.com/blog/supabase-swift

I'll let Guilherme know. feel free to reach out directly with any specific feedback

eddieroger• 2 years ago

I would add that it's gotten better since it was folded in for official support, but it could still use some love. So cheers for improvement, and stay at it. It's encouraging to see a community add like this folded in to the main.

trevoragilbert2• 2 years ago

Ha, the timing makes it look like you did this in response to my comment. :D Very excited about this!

SadWebDeveloper• 2 years ago

I'm a full stack developer and still don't know what supabase does other than being a firebase replacement...

Like seriously are they seriously trying to sell us how difficult is to setup a simple nginx server? Not sarcastic just an old developer that hasn't get this new fad of going "serverless".

giraffe_lady• 2 years ago

It's not serverless it's a postgrest API over a DB. Which is plenty of backend for many of my purposes. Postgres's RBAC is sophisticated enough to use as your entire auth layer if you know what you're doing with it. After that it's a free rest API.

I'm not like a supabase diehard or whatever but I have used it to great success in a handful of projects, especially early or proof-of-concept stage ones. For me it's not a replacement for nginx it's a replacement for rails.

cljacoby• 2 years ago

They seem to heavily invest in their social media presence with things like the YouTube channel, but then also use social media indicators (likes/follows/subs/etc) as a measure of success. Seems a little circular.

The plot of Github Stars over Time: Supabase vs. MongoDB seems particularly silly (imo).

Not a hater by the way, I think their YouTube channel is actually pretty good, and I think it will become increasingly common for startups/businesses to have something like this for product/brand awareness, getting users up and running, etc.

I think if the goal of the post was focusing on platform maturation and growth, it might have been better to focus exclusively on the plots of database/users over time, and simply link out to the various social channels.

Overall though still cool to see, and congratulations to the Supabase team!

hackerman14• 2 years ago

Interesting how they posted a self-host guide just a few hours before announcing this. https://www.youtube.com/watch?v=FqiQKRKsfZE Perhaps expecting criticism and preemptively creating a response that shuts people down?

Ultimately I just see the same pattern in Supabase as in many of these "easy scaling" solutions: lock in. I think the future is something like those platforms are offering but we're definitely not there yet. Also it's not like I'm an old person refusing to accept new tech. I'm young and looking to create things but I recognize that these services are (currently) doing the complete opposite of giving me freedom.

kiwicopple21• 2 years ago

the video has been available on our self-hosting docs (https://supabase.com/docs/guides/self-hosting/docker) for months (see comments age). I just noticed that it was "unlisted" instead of "public" when I was making this GA page so I made it public. There isn't anything sinister here

"easy scaling" solutions: lock in

This has been hashed through in a few comments on this post: Supabase is Postgres. We offer tools on top which you can _optionally_ use. Some people love those tools (especially Postgres maxis). Some people prefer to just use the database with Django/Phoenix/Rails/etc. You choose your own level of comfort.

tasubotadas• 2 years ago

How it compares against neon.tech?

imbradn• 2 years ago

The acquisition of Oriole is very interesting. Getting that to a GA product would be a game changer for a lot of workloads.

tristan957• 2 years ago

I'm excited for more OrioleDB patches to land in upstream. Sounds exciting.

davetron5000• 2 years ago

I built a toy app using this, with a front-end only app and postgrest + RBS. The app was seriously two forms behind a login. It was a huge pain.

RBS is "insecure by default" meaning if you don't set it up right, all users can access all data. And, because it's SQL, it's really easy to write a valid and successful configuration that doesn't work. You have to test it. And for views, you have to do some real heroics to get them to respect RBS.

PostGREST is very very basic and far less powerful than just writing SQL. I found it pretty frustrating to use, knowing that SQL would be far simpler.

Yes, I know that I could make a direct SQL connection to the database, but at that point, it would've been easier to put a Rails app on Heroku and use their offering, which is far more mature.

The Supabase dev environment was pretty slick and worked well, though I had to docker implode a couple times.

I wish them luck, but I could not figure out what the use case was for their product, given that Heroku has an awesome managed Postgres and RDS is there if you have more knowledge and want more controls. I don't see how you could make a complex app that is front-end only with Supabase as your entire back-end.

TOMDM2• 2 years ago

A few things, RLS is secure by default, it's postgrest that's insecure by default.

RLS disables all operations on a table once enabled and is only operable once there's a passing policy unless you can bypass RLS.

When it comes to access control, you should probably always have tests for anything halfway important.

Views are a bit of a footgun when it comes to RLS, they bypass it by default. But getting them to play nice is as simple as defining "security invoker" in their definition; not what I'd call heroics.

steve-chavez3• 2 years ago

A few things, RLS is secure by default, it's postgrest that's insecure by default.

What makes you think that? PostgREST delegates all the authorization to PostgreSQL, which is secure by default. You have to explicitly assign privileges to roles for every operation.

Relevant previous discussion: https://news.ycombinator.com/item?id=38689294

steve-chavez3• 2 years ago

PostGREST is very very basic and far less powerful than just writing SQL. I found it pretty frustrating to use, knowing that SQL would be far simpler.

The PostgREST query grammar is basic on purpose, you're supposed to write SQL on views or functions[1] to extend its capabilities.

[1] https://postgrest.org/en/v12/references/api/stored_procedure...

vbezhenar2• 2 years ago

I'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 significant time investments.

So my wish would be for supabase to provide some kind of minimal bare-bones configuration and careful documentation for their monstrous docker-compose configuration with explanations why all parameters were set to non-default values. I don't think that I need all those services if I don't use any of them except database and sometimes admin UI.

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.

Right now I've set up supabase for our developers but asked them to migrate to plain postgres as soon as possible, so I could move production workloads to our standard setup.

My ideal setup would be one postgres instance which I can install myself from plain docker library image; one golang binary which embeds everything supabase offers turned off but with some envs to enable and that's about it.

kiwicopple21• 2 years ago

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...

vbezhenar2• 2 years ago

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.

owenversteeg• 2 years ago

Supabase is great - I use them now and they and would be my choice for a new project today - but I have to say I am not a huge fan of how they communicated the whole auth-helpers and ssr situation, and I am not the only one with this comment by a long shot. This is, I think, a part of wider issues with their documentation; it seems like whoever's doing documentation at Supabase is intelligent but stretched thin. Particularly for Sveltekit, the documentation and examples are incomplete, there isn't any guide to migration or how to modify your code, and if you Google things or follow any links or examples you quickly end up in a web of deprecated repositories where it's unclear what to do next or replace them with. One example: https://github.com/supabase-community/auth-ui

If you produce a product for developers, you really need to have 1) quality, readable documentation with an introduction that noobs and pros alike can follow, 2) multiple complete, cloneable examples on how to integrate and use your product in several different libraries, 3) obvious migration guides and timelines whenever you deprecate something. Supabase lacks all three, which is extremely frustrating and means there's always a giant caveat when I recommend them. They're still the best, it's a very powerful and impressive product, and the possibility of self-hosting is amazing.

kiwicopple21• 2 years ago

They're still the best, it's a very powerful and impressive product

first, thanks for these kind words - it's encouraging (as a maintainer, not just a team member) when we know we're on the right track

sorry about the frustrations, especially around the ssr/auth-helpers. We definitely could have handled that migration better (and the comms in particular). To address some of your other points:

2) multiple complete, cloneable examples on how to integrate and use your product in several different libraries

Yesterday we made it even easier to do just that with "supabase bootstrap"[0]. We'll be adding all of our quickstarts[1] which cover most of the key (frontend) frameworks

3) obvious migration guides and timelines whenever you deprecate something

Agreed. We actually developed this internally after the auth-helpers/ssr. We'll do better in the future.

[0] bootstrap: https://supabase.com/blog/supabase-bootstrap

[1] quickstarts: https://supabase.com/docs/guides/getting-started

breakingcups• 2 years ago

I've been trying out Supabase for an MVP but while the hosted postgres part is quite nice, the C# SDK recommended (but not maintained) by Supabase falls quite short, leaving me to trace down all sorts of obscure issues that turn out to be a 2-year-old bug in the SDK that's still not fixed. It is kind of nice for a community effort but definitely not good enough at all for professional adaptation by .NET developers.

On paper, Supabase really has all the ingredients I should need to make my application. In practice, I still end up struggling a lot with the development model. I wish there was an easier, safer way to create RLS rules that doesn't need me knowing (to me) obscure Postgres syntax. This is especially grating since the rest of the tooling seems to try to take me away from SQL a lot by using Postgrest.

steve-chavez3• 2 years ago

This is especially grating since the rest of the tooling seems to try to take me away from SQL a lot by using Postgrest.

You're actually encouraged to write SQL with PostgREST, see this other comment https://news.ycombinator.com/item?id=40046710

lakomen• 2 years ago

I have to say, I tried it but at that time the self hosted offering was too limited, and the good stuff, the useful stuff was behind the cloud subscription paywall.

The initial experience was easy to get going, but the devil was in the details. Much of the logic should be server side also for security reasons and that wasn't possible when I tried it.

People like to hype things that are easy to get started with but don't go much further so the initial impression remains.

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

kiwicopple21• 2 years ago

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...

dylanzhangdev• 2 years ago

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

Related Stories