I want to give a big shout-out to the HN crowd. You have been instrumental in our growth - both from a traction perspective, but even more so for product development.
From our initial launch 2 years ago[0], where everyone told us we need auth, to our Auth[1], Storage[2], Functions[3], and GraphQL[4] launches. You are always giving great (and usually tough!) feedback which helps guide the team and product direction.
I will be around briefly to answer questions, then back tomorrow to cover anything unanswered (it's very late where I am!)
I appreciate how you all have open-sourced key elements of the platform. I've enjoyed learning from your code. It's also cool how you guys don't "code scared" and push the envelope for Postgres.
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-hosting story, a little bloated JS client libs) but in general they have a solid offering that is only getting better.
I can't stress enough how there is really nothing quite like it out there at the moment. I get that HN crowd is always very skeptical esp with the somewhat airy opensource/self-hosting story that seems a little deprioritized to handle the (probably insane) growth. The escape hatches might be a bit rusty a bit at the moment but compare that with Firebase and its a little inconvenient in SB vs a prison in FB.
I am quite optimistic about Supabase and I wish the team the best of success.
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.
This mirrors my experience. By making the opinionated choice for Postgres it is possible to use e.g functions and triggers to replace a lot of code that would normally live in the backend. It is quite common to come from ORM-land and treat the database as just a dumb tablestore with some keys. Which does not do justice to the incredible featureset of Postgres. All of that makes it possible to avoid writing a lot of boilerplate and was a huge productivity boost for me. YMMV ofc.
Last time I checked it there was a docker-compose file for local deployment but you had to translate that to a working production env on your own. Which would include setting up the database, setting up Kong on edge-gateway, figuring out secrets management, filehosting and updates. One could argue that this is normal hoops to jump through when deploying open source ofc. It just felt way more laborious than the communication suggested.
One of the main features the "dashboard" was completely unavailable for self-hosted at the time. So you would not get quite the same experience compared to commercial (again this might be expected for OSS but is a little different from what might have been expected initially ).
I just checked and it seems now there is e.g. a (unofficial) k8s deployment plan so it so things might have improved.
In general it just felt like it was not the highest priority to get the self-hosted plan up to parity compared to the managed version.
I have no reason to believe that was anything other than the product not being quite ready for the aspirations of the team. There where some comments on on HN that called the Open-Source claims a marketing ploy. I strongly disagree with that notion and believe that the SB team is acting in good faith and that they will deploy some of that fresh capital to further strengthen the OSS story.
I've recently done the conversion, used Teleport to get access to the dashboard. It works pretty well and I like the fact that I can fork GoTrue / point routes at my own server-side components, rather than just Supabase.
I agree that a proper Helm chart (or a Kubernetes operator) would be ideal. Too bad it would probably also hurt their Cloud offerings.
I’ve used the community Helm chart and it’s nowhere near production ready. I had to spend several days configuring it to be usable in production. Which isn’t that big of a deal, but it doesn’t look actively maintained at the moment and could probably use a fork.
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 should lock everything down by default. At some point, this is going to cause major problems for some company that decides to build off Supabase.
- Although they have row-level security, RBAC is completely missing. It's not hard to implement yourself through stored procedures and triggers (they have an example repo to copy from), but I don't see a lot of junior devs doing this.
- Stored procedures are more likely to be utilized in the Supabase paradigm, but I haven't felt like they have done much to address the inherent weakness and common critiques of using sprocs instead of application level functions.
- Escape hatches are missing in their fork of GoTrue (why did they fork it in the first place - now there are two competing versions?). It's still not clear to me how to add data to the JWT or get access to the JWT through their SDK.
- Slow dashboard with rendering problems. It doesn't render correctly on my Fedora laptop. And the slow speed becomes pretty annoying almost right away.
- I have experienced data loss when using their SQL editor. So now I copy all the SQL I write to a local file or just do everything through DBeaver.
- Lack of backups on the free tier. They should give this away for free up to a storage limit. Backups are a critical part of development and I don't have full trust in Supabase given that I've already experienced data loss through their UI.
- Misleading marketing. They make implicit claims all over the place on what they offer but then have disclaimers on their code bases about certain features not being production ready.
They clearly have work ahead of them, but I'm optimistic about the potential for Supabase and I look forward to the improvements!
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 simply documentation ("RBAC with RLS") or actually build the abstraction. We have built something internally which we are dogfooding, so watch this space.
> Stored procedures are more likely to be utilized in the Supabase paradigm
Now that we have released Edge Functions, we have more time to work on the blend between both Procedures and Functions. Our CLI needs a lot of work, but this will be a major focus for the rest of the year.
> They clearly have work ahead of them, but I'm optimistic about the potential for Supabase and I look forward to the improvements!
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.
We did evaluate OPA recently. For now, we're working with an approach that builds on top of PostgreSQL Row Level Security and functions. That may have a sufficient balance of power, performance and complexity for many of our users. For more complex use cases, OPA may indeed be a good fit and is something we can explore more in the future.
I work at Supabase on database security so I can speak to some of these.
> - As others have said, default security is way too permissive. They should lock everything down by default. At some point, this is going to cause major problems for some company that decides to build off Supabase.
We agree and are internally actively discussing this very subject.
> - Although they have row-level security, RBAC is completely missing. It's not hard to implement yourself through stored procedures and triggers (they have an example repo to copy from), but I don't see a lot of junior devs doing this.
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?
> - Stored procedures are more likely to be utilized in the Supabase paradigm, but I haven't felt like they have done much to address the inherent weakness and common critiques of using sprocs instead of application level functions.
Weaknesses, critiques and strengths. There are tradeoffs and some of this gets down to a matter of opinion. Mine is admittedly radical in this case. We recently released Edge functions which are great, more tools in the toolbox, including stored procedures.
Did you used to work on Zope? You have a familiar handle...
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 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.
> 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-in role system. You can assign a "group role" to as many roles as you want (which in turn, can also be groups, or not) into a hierarchy of roles which can be used in any GRANT statement or RLS policy. Postgres used to have `CREATE USER ...` and `CREATE GROUP ...` but they are now completely subsumed by the "new" role system. Both statements still work and map to equivalent `CREATE ROLE ...` statements.
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.
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!
For me, this is the part where Supabase being purely a Postgres implementation is a real strength. Supabase gives you access to the underlying database directly via a standard Postgres connection, so you can use literally any tool you want for database migrations.
Downside to the direct access being that there's no pretty Web UI for it - but I think that's both a pro and con (it sometimes bothers me how much effort they put into their UI, from an purely opportunity-cost perspective).
Have used Supabase in several applications; it's an amazing product. And what I'm the most grateful about it is that I came to it as a self-taught front end dev, and it taught me the beauty and power of the relational database itself. Trends and technologies will come and go, but the heart of a software project, as I understood it, will usually lie in its data model. I was intimidated by it, and then, after Supabase, I was not.
Now, I'm especially hyped on on the realtime capabilities showcased in multiplayer.dev: in a recent project we had to implement a chat service quite quickly, an although through supabase we already had an elixir server set up and working, it still revolves around postgres replication, which didn't really felt right and did imposed some limitations. This led us to use Centrifugal, a oss go microservice, which has worked great... but it felt a bit like a missed opportunity. I didn't found any Elixir based rt-as-a-service product, and it looks like you guys are in a great position to tackle that space. So there's that.
Anyways, good luck and thanks again for your hard work!!
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 interchange still by implementing a token minting endpoint ourselves, but that's extra effort and latency). This would also be really useful for integrations with Firebase Auth, which is ironically needed for interoperability with other Firebase products not yet in Supabase :-) It would be great if you switched to standard RS256 + .well-known OIDC endpoints..
2) Recently added built-in database-driven GraphQL module is ingenious, but would benefit greatly from Realtime capability (and I know that's hard!)
3) It's a bit unclear what the multi-zonal or multi-regional (!) story is for Postgres. This would be very useful not just for HA, but for globally-distributed (reduced latency!) scenarios, like the ones addressed by Fly.io Postgres, for example. I know, global ACID is hard and expensive, but if we could get closer to that (for example, similarly to Fly.io), that would be amazing! Right now, it's not clear what the latency story is for users accessing Supabase from half-across the world. If you could document that at least a bit (incl. which region(s) Supabase is deployed in so we could place our backends closer to those), that would be awesome!
Thanks so much, this is such an amazing and unique (!) product that really fills the void left over by Firebase, particularly due to the lack of major progress on Firestore in recent years.
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).
Hasura connects to databases and all your other APIs to give a unified GraphQL API (and REST API, if you configure it).
This takes care of your CRUD APIs portion of building your app. With declarative Access Control Rules, you get powerful Authorization. IMO, these two should take care of 70% of your application code that you typically end up writing. The remaining will be custom business logic that you can write in any language or framework of choice and connect it to Hasura.
There’s of course more with the cloud offering to give you caching, rate limiting and monitoring in production. Hasura doesn’t host your database, it just needs the db connection string to get started.
I think Firebase has the lowest barrier to entry and if you don't exceed the pricing tiers, its a very pleasant experience.
Hasura and Prisma are both awesome, but after having worked in GraphQL a lot, I now try to stay at least 10 feet away at all times from GraphQL paradigms unless their hidden costs can be justified for the project.
I haven't used Thin, but it looks like its React only. If there was a Svelte or JS agnostic option Id give it a try.
Thin also supports other JS frameworks. Svelte docs can be found here https://thin.dev/docs/svelte We're focussing the communication on react mostly to keep things simple. The core of thin is independent of react.
I havent been following closely, but Prisma just landed $40m series B, & their announcement describes it as an intent to grow into an "Application Data" platform. https://news.ycombinator.com/item?id=31251167
So I think what they are talking about with platform here is just more and better tooling above the data store - like the prisma studio product for a uniform interface to data for different teams, abstracted above the detail of the specific store etc. So not just an ORM on the techincal level but that same sort of idea on a business level perhaps.
I don't see anything in there about this including plans to build their own native data store. Nor do I suspect that would be a great idea (really really hard, not their competency, nor their point of leverage!)
Using thin-backend has been one of the most delightful experiences I've had making an SPA with a simple backend. The developer experience with the generated TypeScript types is particularly great, the DB migrations remind me of Prisma, and knowing I have a standard Postgres db under the hood is comforting. It isn't a large or complex app, but Marc has been super responsive to bugs and feature suggestions so it has been fun to iterate on. You can find the code at https://github.com/ianobermiller/colorcal.
Coming from a rails background, I have really enjoyed developing against Firebase.
Cloud Firestore so much easier than deploying a rails app somewhere. It comes with a lot of great analytics tools. The auth stuff works great. The documentation is very good. It has been extremely reliable. Syncing across devices is amazing and seamless in my experience.
If it fits your use case (I think mostly CRUD apps with data sharing that is somewhat limited in its breadth, e.g. not something like twitter with N-N data relationships), it is really amazing.
It has most of the features that all this shiny new tools have (and more) but is way older. It used to be a Facebook hosted solution but it was opensourced and is still actively maintained, has SDKs for most languages and frameworks, REST & Graph QL API, live queries...
And there are still some sites that host it for you for free (limited), but you can always self host it yourself...
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.
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 comparison).
I echo the sibling: I really recommend you change this. Pricing by bandwidth only makes sense if bandwidth is one of the main cost factors, because people will, consciously or not, compare it to other services that are priced by bandwidth.
I recently started a project with Appwrite. So far it looks to be quite straightforward, the only thing that's annoying is their database capabilities. You can only load data via their SDK API, so migrating my existing multi million record db is a pain.
We only have mobile apps, so I can’t speak for web apps, but for us Realm (https://realm.io/) has been amazing.
The Local API’s are a joy to work with. The capabilities of the local database makes Firebase look like a toy, and the sync service does solid two-way replication between devices.
Definitely one of the best backend-as-a-service we have tried (but our experience is mobile only, so yemv).
There’s no best really, but in my experience I prefer Hasura. I think their security model makes more sense than row level security and I prefer GraphQl.
Supabase recently shipped with graphql support that is very nice, it maps the query language to the relational schema in a sensible way. Without direct experience I understand this is similar to how Hasura maps it.
As for your preference for Hasura security vs Postgres' native row level security, of course your preference is entirely valid and may also be the best fit for your needs, but consider that RLS works for all database clients, not just Hasura, so if you have a heterogeneous db client environment and you want to enforce one central policy, RLS can do that but a Hasura specific policy checker can't.
Disclaimer: I work at Supabase but not directly on the GraphQL support.
Thin self-hosting is coming soon :) We already have this working on the technical side, we just need to add more documentation before we can push it out.
However, while I've played around with most of the others you mention, I haven't build anything serious with them. But hasura has a decent authentication story and reactive graphql queries are just a really nice dev experience
I just started using Supabase on a small side project and am very impressed; the ease of setting up realtime was amazing. However, the dashboard is so slow. Every action that has a server request results in a spinner, even if it could be instant, like creating an empty unnamed sql query.
Unrelated but Cloudflare dashboard used to be like that but they did something recently (few weeks ago) and it is blazing fast. Everything is instant joy. Well, except the Access/ZeroTrust app. Not sure why that's a different app that takes 10 seconds to redirect a bazillion times. It has horrible UI compared to the main dash.cloudflare.com and generally has bad documentation. I guess it exposes internal teams at Cloudflare and some broken product management. Hope that gets better.
My main critique after trying Google Firestore was:
(1) Lack of typed schemas with declarative definitions
(2) Read/write permissions and write validation was extremely complex
Disclaimer: I work at Supabase on database security.
The link you posted is a great guide to sensible security practices with Supabase. It's worth noting that the feature highlighted, Row Level Security (RLS) is a native Postgres feature and not Supabase specific in any way.
One immediate benefit of using native security is that it applies to all types of database clients and tools uniformly. we're not blocked in the future adding more integrations. And it works both ways, if you are using RLS in an existing postgres deployment you can migrate to Supabase and your existing trusted policies will come with you.
It also means that we can avoid creating a whole class of security bugs by starting from scratch, and take advantage of the millions of collected human-hours of work that already exists. Security is hard because it is adversarial and it is hard to reproduce or even conceptualize a truly threatening environment without experience.
One of our guiding principals is to stand on the shoulders of the core developers and not implement our own core security model, but to use the native one as a foundation for even more powerful security concepts to come. We're actively discussing a lot of ways to make this even easier and safer for customers.
A long time ago, I was the PM on Firestore security rules, which was intended to solve both of those issues.
https://github.com/FirebaseExtended/protobuf-rules-gen was the closest we got: declaring types as protobufs (because Google, of course) and then generating both security rules to guarantee validity as well as client types that would match. I wanted to add proto annotations to do additional validity (e.g. add a regex to validate the phone number string was correct, do length checks on strings, etc.), but we never quite got there (not sure proto annotations are a thing externally either).
The short answer is that backend rules engines, either in their own DSL or bolted on to e.g. SQL, are pretty tough to get right, and have a super steep learning curve. IMO, AWS API Gateway with Lambda Authorizers get this most correct: it offers a programming model that people are familiar with (writing code to access external resources to make the authZ decision) with a clear performance tradeoff (ability to cache the result for a period of time).
> The service can’t, of course, match Firebase on a feature-by-feature basis, but it offers many of the core features that developers would need to get started, including a database, storage and authentication service, as well as the recently launched Supabase Edge Functions, a serverless functions-as-a-service offering.
I’ve been self hosting it for the past couple of months. It is a really nice product. Allows one to get fully fledged app with backend running extremely quickly, just drop a front end in. There’s still some annoyances with it though - Work still needs to be done to enable backend communication over services using SSL - it’s currently unencrypted by default. I was able to get SSL working with some minor changes to sources and configuration but it really should be encrypted by default.
The defaults don’t seem super sane either, by default an anonymous user can read your entire public database schema via OpenAPI (which is turned on by default as well), including any RPC’s. That alongside the fact that Postgres grants RPC execute to public by default means that if someone isn’t paying attention they can easily expose execute permissions to the outside world on functions in their public schema to unauthenticated users, and tell them exactly what functions are exposed!
The current response from Supabase is to ensure the API gateway you use authenticates users first - which isn’t really a solution IMO, for multiple reasons. I ended up spending some time figuring out how to revoke the appropriate database permissions from the anonymous role in Postgres, but it shouldn’t be like that. Anon role should start with nothing and the end user should very explicitly be turning on what unauthenticated users can access.
> Anon role should start with nothing and the end user should very explicitly be turning on what unauthenticated users can access.
We agree. We're working on a pathway towards this. Under our original designs we matched all defaults to Postgres' defaults, and with any additions the idea was to "stay out of the way" during development. It's become increasingly important for us to design around security. This will definitely mean more difficult development for newbie developers, but it's an important step forward.
> I’ve been self hosting it for the past couple of months. It is a really nice product
Thanks for the kind words! The credit also belongs to the open source tools we leverage - Postgres, PostgREST, GoTrue, Kong
Useless or not, spending less human and environmental resources to make something is generally positive, no? Supabase enables developers with ideas to easily create software with more features thanks to a 1click Postgres database + auth + a secure API. I imagine that would generally lead to more “usefulness” in an app.
All I need is to do is install the npm package, write some psql, and the whole system can be driven securely in the frontend. As a dev with more experience in frontend than backend, it’s quite empowering for me! And I know companies who do much more than what I can accomplish with Supabase.
Yes, it is 100% a good thing. Computers should make our lives easier, and the best way to do that is to enable people to solve their own problems. Not everyone needs to rewrite Microsoft Word, but who knows what great idea someone is sitting on, just waiting for the tools to make it. Perhaps someone has a novel approach to task management, or needs a way to track medication but doesn't want to share their data. Giving people means to do more with their devices than swipe and click is a good thing.
Cheaper bets -> More bets -> more wins -> more winners -> more bets
E.g. Shopify absolutely made Ecom 10x easier, which has enabled more people to start brands catering to more niches while making more entrepreneurs wealthy who then invest in other entrepreneurs.
This is only a good thing; the marketplace cannot be too crowded.
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.
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.
The innovation in managed devops is pretty incredible! Had a question for the Supabase team regarding authorization and PostgREST.
Let's say I have Customer 1 who owns Document 2, 3. Document will have a foreign key pointing to Customer. How do I ensure that Customer 1 can't access Document 1?
That can be solved with RLS. The JWT usually contains the application user id(Customer) and assuming Document has an ownerId column, the SELECT policy for Document would contain the `ownerId = auth.uid()`[1] condition — this would ensure customers can't access documents that they don't own.
Huge congrats to you guys! Have really enjoyed using Supabase with both React and Vue, especially how well things are documented (especially so early on in your product’s maturity.
I think the sentiment has been shared here by others, but I think authentication and authorization are going to be your biggest hurdles, yet biggest revenue drivers in the future (e,g., enterprises, startups, etc).
I’d honestly love to see you guys come up with a novel OIDC solution, maybe even using Keycloak as the model/goal (which also follows the trend of Supabase innovating on existing tech).
Excited to see where you all go from here and the sky is the limit!
When you first launched I recall seeing an advertisement for CEO position at Supabase which I thought was surprising for such an early stage startup. It looks like that never eventuated which I am pleased to see. I am curious about the backstory behind seeking an external CEO and then concluding not to?
Supabase edge functions use Deno, which supports WebAssembly, which is a decently-stable compile target of Rust. It gets tricky when you need to do IO, though.
The wasm spec itself should be pretty future-proof now, but I'm less sure about deno. I'm curious what your use case is, happy to take it to email if you like.
If you're looking for something like superbase but with a more end-to-end typesafety approach + optimistic updates, check out Thin Backend https://thin.dev/ It takes a bit more of a higher level approach to database operations than superbase, which allows us to do things like optimistic updates that are hard to do in other tools.
It's using Postgres pg_notify to subscribe to tables and using a WebSocket server to distribute the changes. The table watcher is written in Haskell and based on the IHP haskell framework. Using Haskell makes it very easy and efficient to deal with lot's of active sessions in parallel.
I'm a Supabase dev and the maintainer of Supabase Realtime and just wanted to clarify that Realtime works by listening to Postgres' logical replication because we realized early on that it scales better and circumvents the limitations of pg_notify; for example notify has a payload limit of 8000 bytes.
We also use the WebSockets to do write operations. This allows for lower latency than doing a HTTP call for any API call. Additionally we run all operations in parallel. With HTTP push we wouldn't be able to easily run all these operations in parallel.
Point being you can usefully have two or more of the same type of thing, even if their only difference is the quality of the team building them. That's why the market sustains more than one car of each type.
Off-topic (and hope the conversation doesn't digress too much): when is it ok for someone to monetize an open source project and when is it not?
I've read over the years how people get super upset at Amazon for taking an open source project, (sometimes) adding some code to it and then host and monetize it. The argument being that Amazon is monetizing on the backs of countless open source developers. Hence why the Common Clause has been added to a number of open source projects to prevent this from happening.
Supabase seems to be loved by HN (haven't tried it yet but looks interesting).
Isn't Supabase just a wrapper around the open source Postgres database (which is BSD licensed)?
Supabase developer here. "Wrapper" is an oversimplification, but essentially, we provide additional value to the existing OSS offerings (i.e. PostgreSQL, GoTrue, Kong, Postgrest) by adding libraries and server configurations that tie everything together and make it much easier to develop an application. That being said, you're free to self-host Supabase and get all this value (and continued value and support) for free. We only "monetize" it by offering a hosted version as an option for people who would rather not spend time managing servers and other infrastructure.
In addition, the value we add to these existing tools is turned back to the community and can be used however people see fit.
Hope my question didn't come off the wrong way, and really appreciate your reply.
Another question, so does Supabase open source 100% of the added features/functionality? Or are some features/functionality gated behind a paid license?
No problem -- it's a very valid question and deserves to be clear to everyone.
Supabase open-sources everything and nothing is behind a paid license, except for any stuff related to us providing the hosted stuff. For instance, our internal software we created for billing customers who host with is not necessarily open-source.
One can do whatever the license allows. It is not my fault if I monetize someone else's code that is MIT licensed. People should read and understand licenses before slapping one on their open source project.
I've been using the MIT license for a decade. It's actually free software, not "free but if you fail to follow my manifesto I'll sue you". It's more practical since it can be used for anything, and it's better for the community since people can use it and contribute without risking legal liability.
Unfortunately this is the wrong team. I have worked on several Postgres full stack applications over the past few years, and I really wanted Supabase to work, the idea sounded great. The JavaScript SDK, the documentation for getting started, and the user interface are all horrible/half-baked. Instead of speeding up my development, Supabase lead me to waste hours in confusion. It is easier to roll your own auth and setup your own database than use Supabase unfortunately.
For a product whose whole purpose is to enable developers to move faster, the product misses the mark completely. If I were CEO I would shift all resources to fixing the UI and SDK.
I would guess out of all the people who have signed up, less than 1% have actually made a “working” frontend.
"Horrible" and "half-baked" don't describe my experience using Supabase at all. Yes, they have work to do. Yes, the documentation is lacking in certain areas. No, this round doesn't indicate they've magically got it all figured out.
> If I were CEO I would shift all resources to fixing the UI and SDK
I'm the CEO :)
Thanks for the feedback. I would love to hear any specifics - where you got stuck and which parts of the UI/SDK we can improve. My email is in my profile.
We know we have a lot more to do, and we love building based on user feedback.
While I don't agree with supabase not being useful, I agree that their getStarted documentation could use some work.
I've faced many issues with the twitter auth. For example, you need to enable accessing email via an additional option on twitter developer dashboard for it to work with supabase. It wasn't documented. I've faced bugs which appeared and disappeared between upgrading supabase instance (You can have different instance version if you created a new application in the middle of beta).
The real time doesn't work until you enable the sync on the supabase dashboard which was not apparent to me. There are bunch of oddities with how policies and realtime work.
The CLI has gone through multiple confusing iteration.
I would still recommend supabase to anyone though. Solid despite rough edges.
Supabase dev and the maintainer of Supabase Realtime here!
> The real time doesn't work until you enable the sync on the supabase dashboard which was not apparent to me.
Thanks for the feedback! I think you're right and we can do a better job of exposing this so it's more apparent for everyone.
> There are bunch of oddities with how policies and realtime work.
Would love to hear more about the oddities! Realtime works with Postgres RLS policies so there should be nothing odd about it. Set up your policies and Realtime works accordingly.
I want to give a big shout-out to the HN crowd. You have been instrumental in our growth - both from a traction perspective, but even more so for product development.
From our initial launch 2 years ago[0], where everyone told us we need auth, to our Auth[1], Storage[2], Functions[3], and GraphQL[4] launches. You are always giving great (and usually tough!) feedback which helps guide the team and product direction.
I will be around briefly to answer questions, then back tomorrow to cover anything unanswered (it's very late where I am!)
[0] https://news.ycombinator.com/item?id=23319901
[1] Auth: https://news.ycombinator.com/item?id=24072051
[2] Storage: https://news.ycombinator.com/item?id=26635184
[3] Functions: https://news.ycombinator.com/item?id=30868849
[4] GraphQL: https://news.ycombinator.com/item?id=30846006