4 ms·

author here! happy to answer questions

config_yml 5y ago
So you're calling Graphql via PostgREST, but I didn't ready about why you're including Graphql in the first place. Isn't it orthogonal to PostgREST which is already used in your stack?
- oliverrice 5y ago
  PostgREST does solves a few of the core challenges that GraphQL is intended to address like over/under-selection and resource embedding (relationships). Even so, there has still been a lot of interest in GraphQL so users can leverage the growing ecosystem for things reflecting the data model/types for client usage, offline caching, etc
  - config_yml 5y ago
    Thanks, this was missing for me in the Motivation section on the blog post. It was a genuine question, not sure why it‘s downvoted.
thelastbender12 5y ago
> After tallying the resources reserved for PostgreSQL, PostgREST, Kong, GoTrue, and a handful of smaller services, we were left with a total memory budget of ... 0 MB This was a really interesting bit to me, could you give detail on how the memory usage gets split up across these? Thank you.
- oliverrice 5y ago
  sure, if we're talking free-tier: Postgres runs in a 1 GB VM all by itself with some optimizations to get the most that limited hardware All other services are in a second 1 GB VM. You can see a list of those services here https://github.com/supabase/supabase/blob/master/docker/docker-compose.yml https://github.com/supabase/supabase/blob/master/docker/dock... The memory use per process can differs by use-case, so its important to leave a bit of headroom. For example, PostgREST's memory consumption can grow if the amount of data being returned from its queries is large. By the time you include: - supabase studio - kong - auth - storage - meta if they each take only 100MB, its pretty snug on a 1 GB VM!
httgp 5y ago
Very excited about! Do you have performance comparisons for the same datasets with Hasura / Graphile?
- oliverrice 5y ago
  We don't have an apples-to-apples comparison for similar hardware and queries at this point but here are the links to performance figures for pg_graphql and grahile. Hasura does not publish throughput number afaik pg_graphql: https://supabase.github.io/pg_graphql/performance/ https://supabase.github.io/pg_graphql/performance/ graphile: https://www.graphile.org/postgraphile/performance/ https://www.graphile.org/postgraphile/performance/ We'll certainly be keeping an eye on performance as it gets closer to GA
kiwicopple 5y ago
just want to give a big shout out to Oli - his implementation really ingeneous, leveraging multiple parts of the Supabase stack while also being agnostic enough to work natively inside Postgres (or with other tools) {supabase team}
nwienert 5y ago
Congrats on release. We use Hasura but haven’t been happy with their speed of iteration, lack of communication of various large bugs, and lack of M1 support / communication. But we do use a lot of their more advanced features like being able to use aggregates in sorts, aggregates in results, custom functions, etc. What are your plans there and will you have a public roadmap?
- oliverrice 5y ago
  There is high level public roadmap that covers the minimum features required before we'd consider going GA here: https://supabase.github.io/pg_graphql/roadmap/ https://supabase.github.io/pg_graphql/roadmap/ Its early days, so the conversations around aggregates haven't happened yet, but I'm optimistic that they'll make an appearance in a future release
- gunrein 5y ago
  I joined Hasura recently to lead the Product team because I love the tool and the people are nice. Thanks for the feedback on what you're finding valuable and sharing your dissatisfaction with the lack of communication around bugs and M1 support. M1 support is very close to ready, we've been waiting on a couple of dependencies to support M1. For what it's worth, I agree with you that our communication needs to improve and it is something we're working on. Also, congratulations to Oliver and the Supabase team on pg_graphql! PostgreSQL extensions are slick and it'll help even more people embrace APIs from databases.
kaspermarstal 5y ago
I've been looking for something like this for a long time, so cool! Great work! Does it work with TimescaleDB?
- oliverrice 5y ago
  It has not been tested, but I'm not aware of any differences Timescale introduces that would be a compatibility issue.
rubyist5eva 5y ago
how do you implement search/sort against something like this?
rlili 5y ago
Does this work in YugabyteDB/CockroachDB?
- oliverrice 5y ago
  Like Timescale (below), I'm not aware of anything in these implementations that would be incompatible with pg_graphql, but it has not been tested As long as pg_catalog schema is visible & the base postgres version is >= 13 it should be good-to-go
andrew_ 5y ago
We use Postgraphile heavily, it drives the entirety of our API. A few feature questions; Is there any plan to support, or has there been any conversation around: - custom directives that run custom code - custom routes on the server that do custom things? Or perhaps proxying to another app to handle alternate/custom routes - schema injection, custom resolver logic
samwillis 5y ago
Hi Oliver, Supabase team, Love what you are doing with Supabase! Quick question, have you considered building any kind of local mirroring system for offline mobile app/PWA, say on top of SQLite? Something like Realm for mongodb or PouchDB/Couchbase Lite for CouchDB/Couchbase. It would obviously need devs to add some extra columns to tables for tracking, and a way to define the merge/overture characteristics for each column, but it would be awesome to have something like that! It’s something I have thought about building for a while but never found the time. (I want to combine it with Yjs for collaborative offline rich text editing)
- oliverrice 5y ago
  There have been a few discussions about offline-sync support for the postgREST clients but nothing concrete to announce yet On the graphql side, we'll be targeting making mutations offline capable but are still in the brainstorming phase. If you have any suggestions for how you think it could work please open an issue on supabase/pg_graphql and we can discuss over there
ptrwis 5y ago
Am I correct in saying that for read queries, you essentially translate the GraphQL query into nested jsonb_agg calls?
- oliverrice 5y ago
  yep!

So you're calling Graphql via PostgREST, but I didn't ready about why you're including Graphql in the first place. Isn't it orthogonal to PostgREST which is already used in your stack?

oliverrice 5y ago
PostgREST does solves a few of the core challenges that GraphQL is intended to address like over/under-selection and resource embedding (relationships). Even so, there has still been a lot of interest in GraphQL so users can leverage the growing ecosystem for things reflecting the data model/types for client usage, offline caching, etc
- config_yml 5y ago
  Thanks, this was missing for me in the Motivation section on the blog post. It was a genuine question, not sure why it‘s downvoted.

thelastbender12 5y ago

> After tallying the resources reserved for PostgreSQL, PostgREST, Kong, GoTrue, and a handful of smaller services, we were left with a total memory budget of ... 0 MB This was a really interesting bit to me, could you give detail on how the memory usage gets split up across these? Thank you.

oliverrice 5y ago
sure, if we're talking free-tier: Postgres runs in a 1 GB VM all by itself with some optimizations to get the most that limited hardware All other services are in a second 1 GB VM. You can see a list of those services here https://github.com/supabase/supabase/blob/master/docker/docker-compose.yml https://github.com/supabase/supabase/blob/master/docker/dock... The memory use per process can differs by use-case, so its important to leave a bit of headroom. For example, PostgREST's memory consumption can grow if the amount of data being returned from its queries is large. By the time you include: - supabase studio - kong - auth - storage - meta if they each take only 100MB, its pretty snug on a 1 GB VM!

httgp 5y ago

Very excited about! Do you have performance comparisons for the same datasets with Hasura / Graphile?

oliverrice 5y ago
We don't have an apples-to-apples comparison for similar hardware and queries at this point but here are the links to performance figures for pg_graphql and grahile. Hasura does not publish throughput number afaik pg_graphql: https://supabase.github.io/pg_graphql/performance/ https://supabase.github.io/pg_graphql/performance/ graphile: https://www.graphile.org/postgraphile/performance/ https://www.graphile.org/postgraphile/performance/ We'll certainly be keeping an eye on performance as it gets closer to GA

kiwicopple 5y ago

just want to give a big shout out to Oli - his implementation really ingeneous, leveraging multiple parts of the Supabase stack while also being agnostic enough to work natively inside Postgres (or with other tools) {supabase team}

nwienert 5y ago

Congrats on release. We use Hasura but haven’t been happy with their speed of iteration, lack of communication of various large bugs, and lack of M1 support / communication. But we do use a lot of their more advanced features like being able to use aggregates in sorts, aggregates in results, custom functions, etc. What are your plans there and will you have a public roadmap?

oliverrice 5y ago
There is high level public roadmap that covers the minimum features required before we'd consider going GA here: https://supabase.github.io/pg_graphql/roadmap/ https://supabase.github.io/pg_graphql/roadmap/ Its early days, so the conversations around aggregates haven't happened yet, but I'm optimistic that they'll make an appearance in a future release
gunrein 5y ago
I joined Hasura recently to lead the Product team because I love the tool and the people are nice. Thanks for the feedback on what you're finding valuable and sharing your dissatisfaction with the lack of communication around bugs and M1 support. M1 support is very close to ready, we've been waiting on a couple of dependencies to support M1. For what it's worth, I agree with you that our communication needs to improve and it is something we're working on. Also, congratulations to Oliver and the Supabase team on pg_graphql! PostgreSQL extensions are slick and it'll help even more people embrace APIs from databases.

kaspermarstal 5y ago

I've been looking for something like this for a long time, so cool! Great work! Does it work with TimescaleDB?

oliverrice 5y ago
It has not been tested, but I'm not aware of any differences Timescale introduces that would be a compatibility issue.

rubyist5eva 5y ago

how do you implement search/sort against something like this?

rlili 5y ago

Does this work in YugabyteDB/CockroachDB?

oliverrice 5y ago
Like Timescale (below), I'm not aware of anything in these implementations that would be incompatible with pg_graphql, but it has not been tested As long as pg_catalog schema is visible & the base postgres version is >= 13 it should be good-to-go

andrew_ 5y ago

We use Postgraphile heavily, it drives the entirety of our API. A few feature questions; Is there any plan to support, or has there been any conversation around: - custom directives that run custom code - custom routes on the server that do custom things? Or perhaps proxying to another app to handle alternate/custom routes - schema injection, custom resolver logic

samwillis 5y ago

Hi Oliver, Supabase team, Love what you are doing with Supabase! Quick question, have you considered building any kind of local mirroring system for offline mobile app/PWA, say on top of SQLite? Something like Realm for mongodb or PouchDB/Couchbase Lite for CouchDB/Couchbase. It would obviously need devs to add some extra columns to tables for tracking, and a way to define the merge/overture characteristics for each column, but it would be awesome to have something like that! It’s something I have thought about building for a while but never found the time. (I want to combine it with Yjs for collaborative offline rich text editing)

oliverrice 5y ago
There have been a few discussions about offline-sync support for the postgREST clients but nothing concrete to announce yet On the graphql side, we'll be targeting making mutations offline capable but are still in the brainstorming phase. If you have any suggestions for how you think it could work please open an issue on supabase/pg_graphql and we can discuss over there

ptrwis 5y ago

Am I correct in saying that for read queries, you essentially translate the GraphQL query into nested jsonb_agg calls?

oliverrice 5y ago
yep!