Supabase-JS v2(supabase.com)
supabase.com
Supabase-JS v2
https://supabase.com/blog/supabase-js-v2
81 comments
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.
Absolutely.
I find myself saying this a lot when I try and explain the concept of Supabase. We don't really emphasize this very much on our website either.
Disclaimer: I work at Supabase.
I find myself saying this a lot when I try and explain the concept of Supabase. We don't really emphasize this very much on our website either.
Disclaimer: I work at Supabase.
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 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.
Whoa. Didn’t think about that.
thanks for the kind words
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.
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.
[0] https://firebase.google.com/docs/functions/quotas
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.
[0] https://firebase.google.com/docs/functions/quotas
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.
supabase ceo here
> Intermittent network errors
I'm curious about where you're seeing these errors - is this your database functions or "Edge Functions" (Deno)?
> Intermittent network errors
I'm curious about where you're seeing these errors - is this your database functions or "Edge Functions" (Deno)?
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?
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
Why not have a single function that uses a router? Just map /* to the function and within the function, make your calls to other discrete handlers.
That is the exact solution we went with :)
So then why mention that FB is gated? It isn't gated, the design of your application was off.
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.
I always assumed it wasn't documented as such because it is a bit more complicated to set up / describe and they were trying to keep the docs simple.
Once you get past a certain amount of endpoints, I'd always want to declare my endpoints in code rather than be tied to their config.
Never had an issue with the logs. Requests still show up.
Once you get past a certain amount of endpoints, I'd always want to declare my endpoints in code rather than be tied to their config.
Never had an issue with the logs. Requests still show up.
it is gated. 60 endpoints in a minute. thanks to OP i now know this.
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...
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!
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.
> 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 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 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.
[1] https://directus.io/
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.
[1] https://directus.io/
I've heard great things about Directus. We have a guide (which the Directus team kindly contributed) that shows how to use Directus & Supabase together:
https://supabase.com/docs/guides/integrations/directus
best of both worlds
best of both worlds
Thanks for this, very informative.
I'm going to look deeper at supabase and how it can add to our stack.
Pretty excited about the sql query editor.
I'm going to look deeper at supabase and how it can add to our stack.
Pretty excited about the sql query editor.
I'm having a bit of difficulty understanding what supabase is.
I thought it was a Postgres database that gave you a PostgREST HTTP API interface.
If that's the case... what does the javascript library do?
I thought it was a Postgres database that gave you a PostgREST HTTP API interface.
If that's the case... what does the javascript library do?
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
yes you're right. The JS library is a thin wrapper around PostgREST's API (https://github.com/supabase/postgrest-js)
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
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
Ok that puts in perspective. It's a convenience package not a must have.
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.
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.
Why not create a table with a single JSON column and dump everything in there?
Has any used Fly.io app hosting with Supabase-JS for the DB? I'm curious to hear people's experience.
I created a branch to deploy the supabase "postgres" image (with all extensions etc) here: https://github.com/kiwicopple/postgres-ha/pull/1
It worked great. That's just the database part - from there you'll need to deploy the middleware too
It worked great. That's just the database part - from there you'll need to deploy the middleware too
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?
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?
> we seem to have lost all typing for Views
I've sent this to the team. We generate the types directly from database, so it's definitely possible.
> PostREST style embedding
For now, you'll need to do something like this:
https://supabase.com/docs/reference/javascript/next/typescri...
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)
I've sent this to the team. We generate the types directly from database, so it's definitely possible.
> PostREST style embedding
For now, you'll need to do something like this:
https://supabase.com/docs/reference/javascript/next/typescri...
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)
What is the difference between Supabase and PostgREST https://postgrest.org/en/stable/
I know Supbase is a sponsor of the PostgREST.
I know Supbase is a sponsor of the PostgREST.
Supabase uses PostgREST as an API server on top of you Postgres database:
https://supabase.com/docs/architecture
We are a sponsor and we employ the maintainer of PostgREST
We are a sponsor and we employ the maintainer of PostgREST
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).
[1]: https://postgrest.org/en/stable/api.html#custom-queries
[2]: https://supabase.com/docs/reference/javascript/rpc
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).
[1]: https://postgrest.org/en/stable/api.html#custom-queries
[2]: https://supabase.com/docs/reference/javascript/rpc
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).
Anyone running projects with just Next.js + Supabase and no traditional backend?
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.
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%.
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.
> 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
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?
supabase ceo here.
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
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
Firebase clone but open source, with hosted options. It's a very valuable value proposition that many people including myself are looking for.
its brought up every time supa is on hn. reasonable qtn but here you go https://news.ycombinator.com/item?id=32440018
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.
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.
hope that clears things up a bit
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.
hope that clears things up a bit
Supabase user here. Ive been happy with Supabase. It feels like the recent launches have been underwhelming.
I am really pumped for Neon and think they are doing something more differentiated.
I am really pumped for Neon and think they are doing something more differentiated.
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.
sorry to underwhelm!
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.
[0] Announcement:https://supabase.com/blog/supabase-series-b#where-were-going
[1] https://github.com/orioledb/orioledb/wiki/Database-branching
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.
[0] Announcement:https://supabase.com/blog/supabase-series-b#where-were-going
[1] https://github.com/orioledb/orioledb/wiki/Database-branching
I'm curious, care to drop a link about this Neon you're referring to? Thanks!
are you a frontend dev?
I cannot find an "about" page. What is Supabase?
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.
more details here: https://supabase.com/docs/architecture
more details here: https://supabase.com/docs/architecture
[deleted]
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.
and congratz on funding kia ora!
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.
and congratz on funding kia ora!
Any support for https://flutterflow.io/ coming?
What about updated Dart support and functions?
we recently released the Dart 1.0 Developer preview: https://supabase.com/blog/supabase-flutter-sdk-1-developer-p...
if the logged out issue is truly fixed then this is amazing - waiting for it to get added to the auth helper lib!
(i’m the github complainer)
(i’m the github complainer)
how does directus compare to supabase? anyone compare the two..
[deleted]
It's wild that their whole value proposition seems to be "It's a Firebase clone, but open source."
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!