hey HN, supabase ceo here. I'm really excited about this release.<p>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".<p>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)<p>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.<p>[0] pg_graphql: <a href="https://github.com/supabase/pg_graphql" rel="nofollow">https://github.com/supabase/pg_graphql</a><p>[1] PostgREST: <a href="https://postgrest.org/" rel="nofollow">https://postgrest.org/</a>
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.<p>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?<p>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.
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. <a href="https://github.com/dosco/graphjin" rel="nofollow">https://github.com/dosco/graphjin</a>
Hi all, this sounds very cool. How does pg_graphql compare to Postgraphile? <a href="https://github.com/graphile/postgraphile" rel="nofollow">https://github.com/graphile/postgraphile</a> (besides I guess running in the DB with PLpgSQL instead of as a NodeJS server)<p>Did you think about integrating Postgraphile with the Supabase ecosystem or have specific limitations with it?<p>Thanks!
Nice! I was already pretty excited about you guys, and this only fuels up more excitement since I always been a GraphQL lover.<p>I'm impressed by the pace that you are releasing new products... keep it up team!
Congratulations on the GraphQL launch. I think it is a step in the right direction :)<p>I see a lot of mentions of Hasura in the comments.<p>If you'd like what Supabase is building but prefer using Hasura you might want to check out what we're building at Nhost (<a href="http://nhost.io/" rel="nofollow">http://nhost.io/</a>). We use Hasura's GraphQL Engine for the API layer while also providing Postgres, Auth, Storage and Serverless Functions.<p>(CEO of Nhost)
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<p>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).<p>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.<p>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.