hey HN, supabase ceo here. I'm really excited about this release.
Our GraphQL implementation is built on top of pg_graphql[0], a PostgreSQL extension we open-sourced a few months ago. The implementation works with a lot of native PG functionality (like Row Level Security). You can also do a some neat things with PG GRANTS, enabling/disabling access to different tables/columns to effectively serve a different GraphQL API depending who is "logged in".
On Supabase, the extension is served via PostgREST[1] using the public PostgreSQL function exposed by pg_graphql. PostgREST exposes PG functions as RPC routes (in our case we also map /rest/v1/rpc/graphql => /graphql/v1)
I'll ping the main dev (@oliverrice) and make sure he is here to answer any technical questions. This is just one of the exciting features we're launching this week. Stay tuned for one of our most-requested features later this week.
big fan of what you all are doing with this. the one massive need we still have are great user stories and recipes around auth, and some common kinds of things people do with auth, and how it affects mutations, queries, etc. It's all very vague at the moment and the docs don't go into much depth. cheers
If you're an existing supabase customer you don't need to change any of your existing permissions.
pg_graphql filters out any tables/columns that aren't accessible to the user making the request. It also respects your row level security policies.
If you can't see something in the introspection schema, you'll get a friendly error if you try to access it. pg_graphql does not used any privileged access so the queries are being executed in a context that is identical to supabase REST
that's great, but what if I want to add a role to my user to do something like send an email with an extended schema (when that lands). What if I'm not familiar with "row level permissions" and I have a SaSS app where different users can access different rows based on column content? Scenarios like those are where the docs fall short. PLEASE think like new users and not like seasoned engineers with prior experience with the feature set.
Supabase's row level security is just postgres row level security, it's not proprietary to Supabase. Postgres documentation, blog posts etc on RLS will apply to Supabase too.
I get this, and I've been using postgres for a long time, so I should get this. My point is that the barrier for entry is very high. Most folks that have experience with GraphQL and not intimate knowledge of Postgres security/access are going to struggle with this. It's much different than say, Postgraphile or Asura - both of which have a much lower barrier for entry. Folks are naturally going to compare. I've been following their GraphQL extension since its development announcement and I think this will end up being the better GraphQL product in the long term. I want Supabase to be a world-class product because I'm a fan, and that means world-class documentation.
You're definitely not wrong. I think Supabase will get there ultimately. But being a startup and presumably a small team, I think it's ok for them to lean on "Supabase is basically postgres as a service so postgres docs can fill the void for now".
And just for the record I'm not affiliated with Supabase, I just use it on a side project and quite like it.
Hey, thanks for creating this! It's nice to see more products in that space.
Off-Topic: How did you create your blog? It's seems like you developed it yourself? I'm currently contemplating on how to create the blog for my product, since I want to have it integrated into the main website as well (as subdirectory). It's not really possible when using third party providers. You always have to use subdomains there.
Yes we developed it ourselves. It's all open source [0] so feel free to fork and modify for yourself.
Inside that repo you'll see two key folders:
- web: our Docs (built with Docusaurus)
- www: our website + blog (built with Next.js)
The naming convention could be better.
Both of these are deployed to Vercel as separate "sites" using their mult-zone setup [1]. This setup is so that the docs are deployed on a sub-path (supabase.com/docs), rather than a subdomain (docs.supabase.com)
Hey, I’m about to launch a product that will make it much easier to host third party website as a subdomain, ping me at lucjansuski (at) gmail if you are interested
EdgeDB [1] has indeed a rich GraphQL layer, but it's a very different project.
While it also builds on top of Postgres, EdgeDB replaces the entire relational database front-end. EdgeDB features a SQL replacement language called EdgeQL (analytical capabilities of SQL married with deep-fetching in GraphQL), a higher-level data model (tables -> object types), integrated migrations engine, a custom protocol with great performance & great client APIs, and many other things. Read more here [2].
pg_graphql and EdgeDB both provide a graph-like query language on top of Postgres. EdgeDB
philosophically (I think) EdgeDB tries to do a more complete job of abstracting over Postgres. It has a custom query language (and GraphQL support via a plugin), and a migration system. Its runs separately from the DB.
In contrast, pg_graphql is more narrowly scoped. It enables you to query your existing Postgres database without caring how your data is structured or having any interactions with migrations. It also runs directly inside the database, so theres no separate process/server to manage.
I've been using hasura for a long time and this offering from supabase is the first time I've ever thought I could move away from hasura. Looks simply amazing.
The Gui for adding roles and tying them to postgres access is very slick with hasura. Is this done manually via SQL commands with supabase?
My litmus test will be if I can run the entire solution from docker or if I'll need to assemble the pieces. Hasura is so easy to boot up with a few environment variables, run locally or inside dokku, and that makes it so simple to set up and start building.
We PR'd this into our docker-compose today [0]. We're always a bit slammed during Launch Week, so if you spot any problems let use know and we'll patch it up asap.
The extension is also deployed directly into our PG bundle [1] which is available in docker [2]
> The Gui for adding roles and tying them to postgres access is very slick with hasura. Is this done manually via SQL commands with supabase?
pg_graphql works with Postgres Row Level Security - we provide a GUI for this in our Dashboard, but they are also just native PG Policies, so you can write them in raw SQL. (I haven't tried Hasura so I don't know if this is a direct comparison.)
The GUI leaves a lot to be desired though. I'm wondering why there is no work being done on just copying what Hasura did with its RLS interface?
I've used it for small projects where permissions are done in an hour of work and big projects with complex permissions were also totally doable, albeit a bit convoluted but that's just complex permissions being convoluted themselves
So why not just copy it and write the "policy" behind the scenes (optionally)?
Thanks for the feedback - sounds like we need to check out the Hasura implementation.
I'll pass that onto the team. We've been planning to re-write the Policy editor for a while now - this feedback is a good justification to prioritize the work.
Also checkout GraphJin an automatic GraphQL to SQL service in Go. It's packed with features including support for GraphQL subscriptions, etc and can be used as a standalone service or a library. Also it's a pure OSS project not a startup. https://github.com/dosco/graphjin
Hi all, this sounds very cool. How does pg_graphql compare to Postgraphile? https://github.com/graphile/postgraphile (besides I guess running in the DB with PLpgSQL instead of as a NodeJS server)
Did you think about integrating Postgraphile with the Supabase ecosystem or have specific limitations with it?
PostGraphile is very close to pg_graphql in goals. It was a big help during development to be able to reference their implementation.
> Did you think about integrating Postgraphile with the Supabase ecosystem..?
For sure! We wrote a blog post about why we chose to implement the reflection engine as a Postgres extension here https://supabase.com/blog/2021/12/03/pg-graphql w/ a direct comparison against Postgraphile and Hasura.
The summary is that we tried out Graphile and Hasura and found that they were both very workable options. We had a few other requirements that led us to the extension instead:
- An extremely minimal memory footprint
- Performance scales with the DB
- 100% security and visibility interop with PostgREST (powers Supabase REST API)
The blog post's "motivation" has some more specifics if you're interested!
It's impressive that the entire thing is in pl/pgsql (apart from parsing).
Have you considered any other implementation strategies (C native extension, any other pl/* or maybe running an out of PostgreSQL process which does GraphQL to SQL compilation)?
Congratulations on the GraphQL launch. I think it is a step in the right direction :)
I see a lot of mentions of Hasura in the comments.
If you'd like what Supabase is building but prefer using Hasura you might want to check out what we're building at Nhost (http://nhost.io/). We use Hasura's GraphQL Engine for the API layer while also providing Postgres, Auth, Storage and Serverless Functions.
been curious as to what sort of savings you've been able to get with supabase because we are approaching a few thousand dollars to store a couple terabytes on DynamoDB
Thinking of buying a dedicated server from Hetzner to run Supabase on it instead but worried about latency. awful that we have to move away from AWS for this but with four/five dedicated servers in EU, US-West, US-East, Singapore and Tokyo, we could have a fixed monthly storage/database cost with some globalized latency (client would connect to whichever dedicated server is available).
we realize that we are at complete mercy of AWS as was expected but the database storage cost was a curveball, so much so that we are thinking of self-hosting database ourselves but seems like a daunting task of its own.
tldr: unpredictability and variability of storage size on Dynamodb is forcing us to explore a more reliable fixed cost solution via self-hosting and hardening our dedicated servers running Supabase.
One thing to mention is that DynamoDb and Postgres are vastly different databases, so the migration won't be a simple "dump and restore".
You're right - it will be a daunting task, but one that only becomes more daunting the longer you wait.
If you make the migration to Hertzner + self-hosting (even just to pure Postgres), I'm certain you will see huge savings. It's hard to give exact numbers without knowing your workload, but feel free to reach out if you want to step through the numbers. We're not one-eyed about Supabase, but we feel that Postgres is a solid choice for your core-OLTP workloads. We love seeing more businesses adopt it. It's good for the ecosystem, and good for open source in general
Appreciate it, really think AWS dynamodb is not an option for those running a bootstrapped business and dealing with large amount of data anymore, guess I'm going to have to bite the bullet and just do more research on hardening dedicated servers ourselves. Really the security and peace of mind from relying on AWS was what we were paying for but the cost is too much as our data storage needs are exploding.
At this point I might even move off AWS Lambda somehow, its quite ironic, we do consulting to help businesses get on AWS but we are moving off it due to rising costs!
Take a look at ScyllaDB Alternator [1], which is API compatible with DynamoDB. Scylla also supports multiregion clusters, which should help with latency. I've not used alternator, but I've had a good experience with Scylla, and it might be worth looking into as a lower effort way to move off DynamoDB.
Our GraphQL implementation is built on top of pg_graphql[0], a PostgreSQL extension we open-sourced a few months ago. The implementation works with a lot of native PG functionality (like Row Level Security). You can also do a some neat things with PG GRANTS, enabling/disabling access to different tables/columns to effectively serve a different GraphQL API depending who is "logged in".
On Supabase, the extension is served via PostgREST[1] using the public PostgreSQL function exposed by pg_graphql. PostgREST exposes PG functions as RPC routes (in our case we also map /rest/v1/rpc/graphql => /graphql/v1)
I'll ping the main dev (@oliverrice) and make sure he is here to answer any technical questions. This is just one of the exciting features we're launching this week. Stay tuned for one of our most-requested features later this week.
[0] pg_graphql: https://github.com/supabase/pg_graphql
[1] PostgREST: https://postgrest.org/