I'm going to have to very kindly ask the Supabase devs to stop making such an appealing development platform as I don't have the time/energy to rewrite my existing web/apps.
But for real, congrats on this and it looks very nice. At this point I'm just waiting on a new project that would be a good fit so I can play with all of this. Keep up the great work!
I think the best part is that if you're willing to go all in on RLS for your authorization, you can do away with needing a backend for your typical crud operations and use their functions for things like webhooks, or the occasional endpoint for more complicated operations.
I am a happy paying user of supabase and I did just that for my project which is meant to facilitate trading of left over wood between woodworker shops. I simply set RLS rules and now I only have a react frontend which calls supabase directly and it works great.
I haven't checked in a while but one thing that was a little cumbersome for me was that I wasn't familiar with writing proper RLS rules and felt like documentation was a bit sparse and iirc there was not autocomplete to guide me a little more - but that might just be me being an idiot and it worked out with a little trial and error. :)
I would say it's definitely one of the missing pieces in their documentation. They have an example policy for the typical scenario of only allowing a user to read/update/delete their own resources, but there's definitely more patterns that are needed. One that took me a bit to figure out on my own was how to only allow a user access to a resource gated behind a subscription (ie a column value in a table).
I can't quite get onboard with RLS directly from the client. It seems like a risky and finicky thing to design database access patterns around, but they might be a stroke of genius that I'm too blind to see right now.
If you're not comfortable then that's totally ok, especially because it's not as easy to test it automatically, but it's definitely allowed me to do away with a backend completely except for a webhook, so that's been nice.
v2 isn't a huge change from v1, if you have anything existing that you need to migrate. The Typescript support should be quick/easy (if you used it in v1, it's mostly removing <Type> from a bunch of your methods). A lot of this is preparing for mutliplayer functionality (coming on thursday) - we needed a breaking change to support Phoenix's presence/broadcast interface.
I love the concept of Supabase. The Firebase model is powerful but gated. For example, I recently had a project exceed FB's quota of functions- you can't deploy more than 60 endpoints in a minute which is a nightmare for CI pipelines which redeploy the entire app [0].
We recently tried Supabase on a "frontier" project, and found that it wasn't quite mature enough for production use in our case. Intermittent network errors and lack of an up-to-date status page hampered productivity a bit. These API changes seem like steps in the right direction.
I use supabase as our backend for https://sudopad.com and recently crossed 1000 shared links. Has been pretty stable for me. The only thing I am waiting for is the ability to call a subabase function on db change.
I fundamentally disagree with this limit due to the fact they provide no alternative when you start getting into that area (I imagine scaling to 120 or 180 is going to be painful for instance). I'm really shocked they don't have a way for a customer to get this quota changed if on an enterprise account for instance (usually there is some byline to the effect of "if you need a higher quota please contact your account rep" sort of thing, but there is none of that here, which tells me no matter the size this is ironclad)
Off topic but I am curious:
Why re-deployed unchanged code?
The user-land solution I can think of is cached builds that only re-deploy changed code?
Good question- Firebase doesn't have an API to only modify changed functions. We've structured our projects such that a changed file basically has a one-to-one correspondence with a changed function, and this you can derive from git-triggered CI/CD, but we've found that selectively launching changed functions is tantamount to stipulating every function from CI code which we've found to be brittle
This is obviously a (hacky) work-around. Firebase Functions are designed to be deployed individually- abandoning that costs you GCP log traces and boilerplate right off the bat. Read the Firebase Functions documentation, and you'll see no mention of designing your application this way.
Sure, maybe I'm reacting more to calling it a nightmare. This is a well documented limit.
First thing I always do is read the quotas/limits on any google cloud product before I use it.
Then, I'd notice the increase in deployment times on my CI server as more functions were being added and inspect what was taking so long and try to optimize it. Those individual endpoints take a while to deploy...
This article and others like it would greatly benefit from a brief description of the thing it is about.
It's a second release candidate, there are instructions for how to install it, apparently it's really popular (congratulations btw :)), but there's no mention of its actual purpose. Could be another JS engine, a new Postgres JS extension, or who knows what else.
Wouldn't have hurt to get the GitHub repo description "An isomorphic Javascript client for Supabase." in there somewhere!
I love supabase and im using it on one of my projects. The only downside is the storage abstraction on top of S3, those Egress fees are huge. I would love to see a Backblaze b2 integration.
I assume for the File Storage? We've designed this server for additional storage providers, and since Backblaze is s3-compatible it shouldn't be too hard to add. Would love a PR if you're up for a challenge!
I haven’t used Supabase, but would it not be easy/standard to stick a CDN between the end user and S3, so that S3 is only hit on CDN cache misses, and thus S3 egress is minimal?
Chiming in with the huge props to Supabase. I'm falling in love with the product, and I was also incredibly surprised at the ease of porting my applications on Firebase over to Supabase using their migration scripts.
I cannot recommend their platform enough to anyone who hasn't tried it yet! It's going to be my platform of choice for all my upcoming projects. Keep it up!
I love supabase. The main competitor is the lesser well known project directus [1]. Posting my experience with Directus here to see how it compares to supabase for folks that have gone that direction.
I had a tough time picking between these, but ended up landing on directus for a few reasons:
1) I don't like using db level users for RLS. Directus has a traditional users table that can be expanded with anything you want, and their roles ability is pretty comprehensive. Column level security is also straight forward based on declarative rules.
2) The Directus admin app is second to none, other than perhaps Django. Its extensibility is the real killer feature. I'm in production right now with nothing but the admin app and a set of extensions.
3) The files and storage capabilities support pretty much any mechanism you could dream up, plus build-in image editors etc...
4) The flows capability gives semi-technical users the ability to do IFTTT like logic inside the admin app. Pretty cool.
5) Directus has a (very) basic BI capability, that's extensible, and tied into the permissions model.
6) This is just a personal preference, but Directus is a smaller company and operating on less funding. This means that we're able to sponsor issues that are important to us and we can communicate directly with core team members. The team there has been extraordinarily responsive, and their github repo is the gold standard in community engagement, imho.
7) The deployment model is a breeze. Just a package.json dependency. npm install does everything.
Downsides:
- They fairly recently rewrote the whole platform from PHP to NodeJS. I applaud the decision, but this means that the product hasn't reached the same level of maturity.
- QA: the Directus team moves fast and breaks things. We've encountered several situations where releases have come out with core functionality broken. We've learned to thoroughly QA a release before we update.
- DX: the developer experience for writing and debugging extensions isn't the best. Its also very opinionated about Vue. I'm currently operating off a fork so that I can have a better DX and use Web Components (fortunately vue plays well with them). If you're just using out of the box functionality and the API, this isn't an issue.
The JS library is an interface to the HTTP API which handles functionality such as authentication, querying (and the likes) and more complex functionality such as real-time updates. I notice V2 also included auto-generated type defs for various table columns
Supabase now offers a few more features which integrate with the Postgres database - File Storage (s3), Authentication, Deno Functions, and Realtime (database change listeners). Each of these services is a standalone server and each has a corresponding JS library.
"supabase-js" wraps up the modular JS libraries into a single library for convenience
I really love Supabase and I would consider it for my new project but I have a requirement to be schemaless, I know the reasons why they chose Postgres, those are explained clearly on their website, but I wish they added a NoSQL DB as an alternative at least.
In their FAQs they argue that you can just use JSON columns in Postgres but that doesn't really solve my issue because those columns would still need to be pre-defined.
Much prefer the DX of the types inferring from the `from` and `select`. Also really love that `insert` now understands if a field is required (or has a server-side default etc.)
Unless I am missing something we seem to have lost all typing for Views? And it is less clear how to use PostREST style embedding?
In future releases I think we'll have an approach which doesn't require any manual intervention, but for this release we wanted to keep the upgrade path relatively simple (it will probably require us to change from strings - `select('id, name')` - to objects)
How do you limit the queries allowed in the UI aka prevent someone from making a really slow / large query? Do you general not use supabase directly in the UI and write an API that your front end can call instead?
Note that the JS client is deliberately limited in the queries it can perform[1].
You can also be fully restrictive by only allowing the client to call the custom SQL functions[2] you define. In Supabase this is done by having all your tables in a "private" schema and only SQL functions in the "public" schema(whose db objects get exposed to the client).
you can call directly from the UI. just make sure that you have Row Level Security enabled and configure the default API parameters accordingly (eg, by default you can select a max of 1000 rows, you can adjust this if you want).
I tried to make this work for me, but I finally gave up this week and wrote a traditional backend component for part of my backend because supabase doesn't support transactions and I am NOT going to write my whole backend in postgres functions.
supabase does support transactions through RPC calls - I think you already understood that based on your comment but want to make the distinction clear for other readers
I can completely understand if you don't to write everything in pgpsql though. Did you also try the Deno Functions?
We've been brainstorming ways to support transactions directly from the client libs in a way that won't lock up the database if there is a network failure between database operations. It seems doable, but not something we want to rush.
Well, the simple case is to start with transactions with only queries that aren't dependent on each other, which would cover a vast majority of cases by itself - client sends an array of queries as a single network call, gets either an array back of results or a failure state.
I will give deno functions a look -- I haven't really looked into them.
And for the record I am still loving supabase overall. PostgREST works for 90% of what I want to do and I can spin up a simple stateless backend to support the other 10%.
You could hook up Prisma (or any other Orm) to Supabase and use their transaction API. Though this will still need to be in server part of NextJS (api routes or getServerSideProps), but would be faster than rolling an entire backend.
congrats team! i like how you used detail/summary tags to truncate the v1 vs v2 diffs.
> It is a bit surprising that you need to add a select policy to do an insert, so we opted for the “principle of least surprise”. If you don't append select(), the data value will be an empty object: {}.
i wonder if there will be dev-mode assistance/hints for people who may be surprised by this.
I'm very excited for the multiplayer features you teased. it looks to be increasingly table stakes for any app, and people shouldn't be handrolling this stuff.
> dev-mode assistance/hints for people who may be surprised by this.
We mostly rely on Postgres' errors to bubble up through the client libs which, coincidentally, is one of the things we've improved in this release. Most of the servers now are passing the Postgres errors through, and we're standardizing on the Postgres error format.
There's a lot more we can be doing here, but it's a step in the right direction
Maybe it's been discussed before but since it's a VC backed company, what's their business model? They raised a ton of money. How do they plan on getting that back?
we have a hosted platform - you can sign up and spin up a postgres database, and we charge you $25/month (+ additional usage over a certain quota).
This model is proving to be fine for us. It's very common for developers to pay for a database, especially a full Postgres database (more-so than say, a frontend hosting solution). We have a free tier too, where we pause the database if it is unused for a week. This good for the planet, and our bottom-line
their whole thing seems to be to capitalize on rightful faang skepticism to become the default paas over firebase. the model is same as any other paas. going off my network it appears to be working, but making the whole sell "we're open source" makes me wonder if it'll still be a leader in 5-10 years
Your answer didn't answer anything and was a bit terse. Their question was valid.
It looks like the answer is that they're charging some sort of licensing fee per project using Supabase or that they have a hosted option for people who don't want to run their own Supabase instance(s): https://supabase.com/pricing.
supabase ceo here - you're right about the hosted option, but we don't charge any license fees.
Supabase is very liberally licensed (MIT, Apache2, PostgreSQL, depending on the tool), and we don't plan to pursue any revenue from licensing. We make enough money from database hosting.
If all you care about is the database, then yes there's a good chance that Neon will greatly outperform. But Supabase is much more than that since it includes authentication, functions, file storage, and their realtime feature. For me, the appeal is that you can get all those features with a postgres database. The nice thing is that you can mix supabase features, so if all you care about is authn, you can still use it with neon.
if you like Neon, then I imagine you like their database branching model? On Friday we announced[0] our 500K investment into OrioleDB, who are working on branching[1], with the plan to upstream these changes into Postgres core.
It would be possible for us to run a fork of Postgres today which supports branching, but our long-term view is that developers would prefer a non-forked version of Postgres (to mitigate any risk of lock-in). So we will work on adding branching to Postgres core in the background, which will be a benefit to the entire Postgres ecosystem.
Supabase is an open source Firebase alternative. We're building the _features_ of Firebase using open source tools: Postgres Database, Authentication, auto-generated APIs (PostgREST), Realtime subscriptions, and File Storage.
cool v2, I was looking at supabase for my startup on the weekend and dropped it because I had a hard time working out types. Happy to see type release and will check out V2.
I agree with Krono & jibprof about a brief description, please create an about or a better mission statement (other then "open source firebase") on the main page.
But for real, congrats on this and it looks very nice. At this point I'm just waiting on a new project that would be a good fit so I can play with all of this. Keep up the great work!