Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Supabase (YC S20) raises $80M Series B

techcrunch.com

Post reply on HN
Print view View original

111–120 of 130 posts

Re: Supabase (YC S20) raises $80M Series B

#111

Post by wenbo »

KaoruAoiShiho wrote: post #106
giraffe_lady wrote: post #93

Earlier quoted context omitted.

It's postgres behind a naive rest api. You can implement caching by hand at the db with materialized views or plv8 functions or whatever makes sense there. Or at the api gateway with cloudflare or something I guess but that's not my area so only guesses really. The realtime stuff can generate a fuckton of writes depending on how you have it set up and what your use is, that's probably the most likely scaling footgun.

Yes I'm talking about the realtime stuff. I thought that's the reason why people use stuff like supabase. I run chatrooms with hundreds of people in it, for example like this: https://fiction.live/stories/The-Only-Thing-I-Know-for-Real/... Meteor scaled horribly for that usecase.

Supabase dev and the maintainer of Supabase Realtime here!

Meteor was before my time (I was doing product when Meteor was all the rage back in the day and never had a chance to explore it as a dev) so can't speak to that but Realtime scales pretty well since it's an Elixir/Phoenix server listening to a Postgres database.

We've recently added Realtime RLS, a more secure version of Realtime, so we need to continue to tune it to make it more performant. I think a couple hundred is doable for now. You should give it a try and give us feedback.

We have a Supabase user who is running the version prior to Realtime RLS, which is more performant at the expense of security, and they have thousands of users chatting concurrently. Just to clarify these chat messages are being saved to a database and then being broadcast to thousands of users.

We're also actively working on Realtime Broadcast which doesn't need to go through the database. Great for ephemeral chat messages and definitely more performant.

Re: Supabase (YC S20) raises $80M Series B

#112

Post by mstade »

michelpp wrote: post #94
ehathaway wrote: post #82

Earlier quoted context omitted.

Thanks for the reply! I've never worked at Zope. Must be my doppelganger. > We don't "have" row level security per se, that is a native feature of Postgres we expose, and the customer is free to use or not. RBAC is a very broad term, and broadly speaking Postgres has roles and privileges that do access control. Did you have something more specific in mind? I was referring to the ability to assign a user to one or mor…

> I've never worked at Zope. Must be my doppelganger. Same last name and first initial as your handle so I took a guess. :) > I was referring to the ability to assign a user to one or more groups and then set, at the group level, access to a row or column. When I implemented this, I avoided using PG roles b/c I was unsure how this play safely with future changes to the hosted DB. This can be done with Postgres' built…

As a Supabase user this statement from OP resonates with me:

> When I implemented this, I avoided using PG roles b/c I was unsure how this play safely with future changes to the hosted DB.

I don't know if they meant this exactly, but the way I interpret that is that there's a "fear" of sorts that by using PG features like roles there's a chance we might be doing things that are in conflict with things Supabase needs to do to effectively manage the database. The auth schema for example is effectively managed by Supabase and we shouldn't mess with it – but it's not necessarily clear where other boundaries are.

I've not come across a situation yet where we've done something in the database that conflicts with Supabase management, but it'd be nice to have some more clarity on what to avoid.

Maybe prefixing the Supabase managed schemas is a good place to start, but I'd also like to see some rules about settings we shouldn't mess with, features that should be avoided/used with care etc.

Re: Supabase (YC S20) raises $80M Series B

#113

Post by mstade »

kiwicopple wrote: post #49
ehathaway wrote: post #38

I like the approach Supabase takes in being a light abstraction over Postgres and using OSS. Even in light of the following critiques, I feel like its one of the simplest ways for an experienced developer to start a new project, and it's now my go to over spinning up a database, Firebase, ORMs, and other database abstractions. My main critiques are: - As others have said, default security is way too permissive. They…

Thank you for this write up - it's extremely actionable. Our team is already chatting about it internally to find some quick wins, and we'll do a deep-dive tomorrow on each of the items you've raised. Some easy ones from me: > RBAC is completely missing We are implementing something here, but we need to find the right level of abstraction for all/most use-cases. It's still unclear to us whether we should make this si…

With regards to authorization – have y'all looked any at Open Policy Agent[1]? I think it could potentially be a good fit for the Supabase stack to implement policies not just in the database but also the gateway and potentially other components as well.

It'd be super cool to be able to implement custom policies in rego code that could be re-used in several parts of the stack, and tested/verified/evolved independently from the stack.

[1]: https://www.openpolicyagent.org/

Re: Supabase (YC S20) raises $80M Series B

#114

Post by kiwicopple »

ehathaway wrote: post #85
kiwicopple wrote: post #49

Earlier quoted context omitted.

Thank you for this write up - it's extremely actionable. Our team is already chatting about it internally to find some quick wins, and we'll do a deep-dive tomorrow on each of the items you've raised. Some easy ones from me: > RBAC is completely missing We are implementing something here, but we need to find the right level of abstraction for all/most use-cases. It's still unclear to us whether we should make this si…

Thanks for the reply! Also, is there any plan on the horizon to have the cloud offering support Google or Azure? Id love the option to use a different provider than AWS.

Yes, that's the plan. Probably not this year, more likely next year at the current rate

Re: Supabase (YC S20) raises $80M Series B

#115

Post by ratg13 »

halotrope wrote: post #77

Congratulations, it is well deserved! I have been using SB for the past couple months and its great! In my experience what they excel at is picking really good components (Postgres, PostgREST, Elixir, Kong, Gotrue, Logflare etc) and packaging them with little overhead into something that is much greater than the sum of its parts. There are issues of course (slow dashboard, some inconsistencies in auth, shaky self-hos…

>I can't stress enough how there is really nothing quite like it out there at the moment

For self-hosting, AppWrite serves essentially the same purpose except for that it doesn't force you to use postgres.

The only major advantage of supbase at the moment is that they have a functional graphql offering and paid cloud hosting.

Whoever finishes OIDC integration first will have my interest.

Re: Supabase (YC S20) raises $80M Series B

#116

Post by dinvlad »

wenbo wrote: post #110
dinvlad wrote: post #99

Amazing product! Started to explore it just a few days ago, as it seems very popular among the Indiehackers community. Got a few nice-to-haves that I'm sure you're already working on :-) 1) Auth tokens currently use symmetric signatures, which makes them less useful for zero-latency verification in runtimes like Cloudflare Workers, and also less interchangeable with other auth systems (although it is possible to inte…

Supabase dev here! I believe this is you: https://github.com/supabase/supabase/discussions/5911#discus... . I just want to let you know that I saw your comment! Thank you so much for the kind words! > 2) Recently added built-in database-driven GraphQL module is ingenious, but would benefit greatly from Realtime capability A member of the team is currently investigating this so please stay tuned. I'll pass on the rest…

Thanks for your reply! I have since found partial solution to (1) in the docs (https://supabase.com/docs/learn/auth-deep-dive/auth-deep-div...) - i.e. it's possible do to a local verification of the token, because Supabase makes `jwt_secret` available via Dashboard :-)

Also, for systems like Firebase, it's possible to mint a custom token based on the (locally verified) uid and additional JWT claims. This still requires implementing a (small) endpoint to do that, though. But that's a bit orthogonal to the signature algorithm choice.

The third part that remains unsolved is OIDC federation - so for example, I could exchange a JWK-signed Supabase token for a Google IAM token, based on its public JWKS endpoint.

Another unsolved concern I haven't mentioned is obviously from standpoint of security, sharing a symmetric key is "dangerous" because it could leak (and requires a sensitive context for verification).

Re: Supabase (YC S20) raises $80M Series B

#117

Post by mstade »

ehathaway wrote: post #38

I like the approach Supabase takes in being a light abstraction over Postgres and using OSS. Even in light of the following critiques, I feel like its one of the simplest ways for an experienced developer to start a new project, and it's now my go to over spinning up a database, Firebase, ORMs, and other database abstractions. My main critiques are: - As others have said, default security is way too permissive. They…

These are all valid critiques I feel. I would also add something that's currently a pretty glaring hole in the Supabase offering: migrations. Is far as I know there's no good current advice for how to do staged environments and migrating between them with Supabase.

Most advice I've seen is to use Prisma (or similar) which means you have to accept having an ORM layer in the stack, or to use a script that really just applies SQL scripts in a certain order, and puts a lot of the onus on the developer to make sure they get those migration scripts right.

We've been getting by with diffing our environments and doing mostly manual migrations, but it's not going to scale and we're mostly just trying to avoid doing DB chances at all instead.

It's not easy coming up with a one-size-fits-all migration story for sure, but I feel this one is pretty important and not having any good guidance to offer on migrations is a big piece missing I feel.

All in all though, Supabase has a great product and the company is very responsive both in terms of support and acting on community contributions. This investment is very well deserved and as a customer I'm very happy indeed to see this news!

Re: Supabase (YC S20) raises $80M Series B

#118

Post by kiwicopple »

ratg13 wrote: post #115
halotrope wrote: post #77

Congratulations, it is well deserved! I have been using SB for the past couple months and its great! In my experience what they excel at is picking really good components (Postgres, PostgREST, Elixir, Kong, Gotrue, Logflare etc) and packaging them with little overhead into something that is much greater than the sum of its parts. There are issues of course (slow dashboard, some inconsistencies in auth, shaky self-hos…

> I can't stress enough how there is really nothing quite like it out there at the moment For self-hosting, AppWrite serves essentially the same purpose except for that it doesn't force you to use postgres. The only major advantage of supbase at the moment is that they have a functional graphql offering and paid cloud hosting. Whoever finishes OIDC integration first will have my interest.

> doesn't force you to use postgres

at supabase we consider this a feature, not a bug. We don't want to provide huge abstractions over a database, because any product that does will inevitably be slower than the database in it's raw state. This is the major difference between supabase and appwrite - and an important one at enterprise-scale.

Other than that, I see a lot of developer love for Appwrite and it seems like an amazing product. If it comes down to features, I'm sure we will be in roughly the same place in a couple of years - they will add cloud hosting, and we will improve our rough edges.

Re: Supabase (YC S20) raises $80M Series B

#119

Post by _query »

searchableguy wrote: post #89
_query wrote: post #39

Earlier quoted context omitted.

Thanks for your feedback :) You have to send quite a few json messages to fill up 1GB. We think overall thin provides a lot of value and saves a lot of developer time (atleast for businesses), so we price it as that.

I think you should use different unit for pricing. Bandwidth is frequently used in the context of file storage which can get expensive really fast even with a few users. This doesn't translate well on the data side where most json responses will likely be lower than a few kb. It's extremely unintuitive which is why I think most Paas providers use request and inflate the number (10 million requests sounds a lot in com…

Thanks, this is really good feedback! We will update the pricing today to use a different unit that is more intuitive.

Re: Supabase (YC S20) raises $80M Series B

#120

Post by _query »

dexterdog wrote: post #90
_query wrote: post #31

Earlier quoted context omitted.

Thin Backend ( https://thin.dev/ ) is the newest of all of those. Compared to Hasura it offers a nicer schema designer. Compared to Supabase it offers better end-to-end typesafety and a more higher level API that offers optimistic updates. Prisma is more like an ORM, so it's designed to be used by a handwritten backend.

$2/GB for bandwidth for a pro acct? Is anybody actually paying that?

Thanks for your feedback. It's very hard to even get to 1GB of data traffic via JSON. And the Pro plan includes 5 GB already.

We will update the pricing later today to make it more intuitive.

Post reply on HN