5 ms·

I'm really curious to see how this ends up doing vs. Hasura. Postgrest (which is basically what Supabase is, obviously with other value-adds) or Hasura which b

I'm really curious to see how this ends up doing vs. Hasura. Postgrest (which is basically what Supabase is, obviously with other value-adds) or Hasura which basically exposes a GraphQL server that interfaces with Postgres. Personally I prefer GraphQL as there's more tooling around that compared to Postgrest but it's interesting to see. In this case if supabase was GraphQL you could just use a subscription. I'd be curious to know why supabase didn't go with GraphQL.

michael_j_ward 6y ago
I believe the graphql equivalent of postgrest is postgraphile [0]. [0] https://www.graphile.org/postgraphile/ https://www.graphile.org/postgraphile/
pier25 6y ago
> I'd be curious to know why supabase didn't go with GraphQL. I'm guessing because GraphQL is very limited compared to SQL. From reading their docs [1] it seems they have a JS API for SQL with support for nested data a la GraphQL. Not sure if its their own or comes from some other library. [1] https://supabase.io/docs/reference/javascript/select https://supabase.io/docs/reference/javascript/select
- rattray 6y ago
  With postgraphile you get the full power of postgresql exposed through graphql. Using a few commonly-used add-ons, you can write a whole lot of sql in gql and it Just Works, translating your deeply-nested and richly-filtered gql query into a single, performant sql query. You can see roughly how this translation ends up here: https://gist.github.com/rattrayalex/ae39c2cf0356f1257ece4f3c4f6488cd https://gist.github.com/rattrayalex/ae39c2cf0356f1257ece4f3c... (in production it's more condensed etc). You can also extend with sql functions or add/wrap resolvers at the js level. (And yes, you can easily hide columns, rename, etc)
  - efxhoy 6y ago
    I recently spent a week doodling around with postgraphile and postgrest. I really liked both, writing everything in SQL is super great. It does feel a bit weird at first but the amount of boilerplate it removes is fantastic and it really forced me to think about the correct schema for my business logic. My only gripe with postgraphile is not supporting column grants in RLS policy.[0] Instead they recommend splitting tables in two and having one-to-one foreign keys and using grants on the full tables instead. It's a shame because PostgREST dealt with column grants just fine and I don't want to use postgraphile's specific "smart comments" in my database, they just seem like a really un-elegant solution to what is otherwise a super nice pattern: SQL everything. I also considered Hasura but they have their own auth system and don't use RLS, which is a shame. Having access control in the database is super great when you have multiple APIs and different people with psql and different roles, all with different levels of access to the same DB. 0 : > Don't use column-based SELECT grants: column-based grants work well for INSERT and UPDATE (especially when combined with --no-ignore-rbac!), but they don't make sense for DELETE and they cause issues when used with SELECT. https://www.graphile.org/postgraphile/requirements/ https://www.graphile.org/postgraphile/requirements/
  - pier25 6y ago
    Thanks, super interesting stuff!
tablatom 6y ago
Nhost is a very similar offering, built on Hasura https://nhost.io/ https://nhost.io/
iooi 6y ago
For Python folks, this library builds a GraphQL schema from your SQLAlchemy models: https://github.com/gzzo/graphql-sqlalchemy https://github.com/gzzo/graphql-sqlalchemy
thom 6y ago
Have you had positive experiences using Hasura in production?
- elitan 6y ago
  Hasura have some big clients: https://twitter.com/commandodev/status/1387348391047335938 https://twitter.com/commandodev/status/1387348391047335938
eloff 6y ago
So one big difference is this tails the bin log (as a replication slave), while Hasura polls. Hasura makes that polling efficient by multiplexing the polling queries transparently so they send one query to poll N queries on the same table with the same shape. But once you're polling a large percentage of your whole data set, the bin log approach has a clear advantage.
kiwicopple 6y ago
(supabase cofounder) We're not opposed to GraphQL at all. We use PostgREST because it's very low-level. It's a thin wrapper around Postgres. It uses Row Level Security, works nicely with Stored Procedures, and postgres extensions (like PostGIS). Philosophically we want to focus more on the database-centric solutions, rather than than middleware-centric solutions. This means a slower time-to-market, but it's beneficial because you have a "source" right at the bottom of your stack, and you can connect whatever tools you want to it (including Hasura!)

michael_j_ward 6y ago

I believe the graphql equivalent of postgrest is postgraphile [0]. [0] https://www.graphile.org/postgraphile/ https://www.graphile.org/postgraphile/

pier25 6y ago

> I'd be curious to know why supabase didn't go with GraphQL. I'm guessing because GraphQL is very limited compared to SQL. From reading their docs [1] it seems they have a JS API for SQL with support for nested data a la GraphQL. Not sure if its their own or comes from some other library. [1] https://supabase.io/docs/reference/javascript/select https://supabase.io/docs/reference/javascript/select

rattray 6y ago
With postgraphile you get the full power of postgresql exposed through graphql. Using a few commonly-used add-ons, you can write a whole lot of sql in gql and it Just Works, translating your deeply-nested and richly-filtered gql query into a single, performant sql query. You can see roughly how this translation ends up here: https://gist.github.com/rattrayalex/ae39c2cf0356f1257ece4f3c4f6488cd https://gist.github.com/rattrayalex/ae39c2cf0356f1257ece4f3c... (in production it's more condensed etc). You can also extend with sql functions or add/wrap resolvers at the js level. (And yes, you can easily hide columns, rename, etc)
- efxhoy 6y ago
  I recently spent a week doodling around with postgraphile and postgrest. I really liked both, writing everything in SQL is super great. It does feel a bit weird at first but the amount of boilerplate it removes is fantastic and it really forced me to think about the correct schema for my business logic. My only gripe with postgraphile is not supporting column grants in RLS policy.[0] Instead they recommend splitting tables in two and having one-to-one foreign keys and using grants on the full tables instead. It's a shame because PostgREST dealt with column grants just fine and I don't want to use postgraphile's specific "smart comments" in my database, they just seem like a really un-elegant solution to what is otherwise a super nice pattern: SQL everything. I also considered Hasura but they have their own auth system and don't use RLS, which is a shame. Having access control in the database is super great when you have multiple APIs and different people with psql and different roles, all with different levels of access to the same DB. 0 : > Don't use column-based SELECT grants: column-based grants work well for INSERT and UPDATE (especially when combined with --no-ignore-rbac!), but they don't make sense for DELETE and they cause issues when used with SELECT. https://www.graphile.org/postgraphile/requirements/ https://www.graphile.org/postgraphile/requirements/
- pier25 6y ago
  Thanks, super interesting stuff!

tablatom 6y ago

Nhost is a very similar offering, built on Hasura https://nhost.io/ https://nhost.io/

iooi 6y ago

For Python folks, this library builds a GraphQL schema from your SQLAlchemy models: https://github.com/gzzo/graphql-sqlalchemy https://github.com/gzzo/graphql-sqlalchemy

thom 6y ago

Have you had positive experiences using Hasura in production?

elitan 6y ago
Hasura have some big clients: https://twitter.com/commandodev/status/1387348391047335938 https://twitter.com/commandodev/status/1387348391047335938

eloff 6y ago

So one big difference is this tails the bin log (as a replication slave), while Hasura polls. Hasura makes that polling efficient by multiplexing the polling queries transparently so they send one query to poll N queries on the same table with the same shape. But once you're polling a large percentage of your whole data set, the bin log approach has a clear advantage.

kiwicopple 6y ago

(supabase cofounder) We're not opposed to GraphQL at all. We use PostgREST because it's very low-level. It's a thin wrapper around Postgres. It uses Row Level Security, works nicely with Stored Procedures, and postgres extensions (like PostGIS). Philosophically we want to focus more on the database-centric solutions, rather than than middleware-centric solutions. This means a slower time-to-market, but it's beneficial because you have a "source" right at the bottom of your stack, and you can connect whatever tools you want to it (including Hasura!)