41–50 of 102 posts
As co-founder of another database company in the PostgreSQL ecosystem, I have to say that I'm really impressed with the quality and velocity of launches from the Supabase team. Nothing else to add, except please keep up the great work!
What's your company?
As co-founder of another database company in the PostgreSQL ecosystem, I have to say that I'm really impressed with the quality and velocity of launches from the Supabase team. Nothing else to add, except please keep up the great work!
thanks Ajay, we're also big fans of yours here at Supabase :)
My understanding is that Postgrest is a separate project that began development in an unrelated way to Supabase, and Supabase is just an user. Is that correct?
But, Supabase is also a contributor to Postgrest, right? Does Supabase employs engineers dedicated to it?
Earlier quoted context omitted.
> It would take a lot for me to switch. We were pretty happy with Hasura but had to switch to Postgraphile due to poor multi-database support, bummer. (Postgraphile is not as polished as Hasura in some ways, but since it can used as a library, it's easy to dynamically create N instances of it with different configurations at runtime. Hasura required our ops team to define a new instance of the service in the docker-c…
Pretty recently, as of 2.0, hasura has added support for multiple databases.
https://github.com/hasura/graphql-engine/issues/6648
Basically, if two entities in the databases have the same names, Hasura fails unless you manually define a unique `custom_name` for each such entity.
Given that the most common multiple database scenario involves different databases with either the exact same schema (one-db-per-tenant) or similar schemas (staging vs. production database), it forces you to painstakingly set a custom_name for basically every single entity in your db.
Thankfully there is an API so in theory you could set this programmatically, but it still means that your client code needs to be manually kept in-sync with whatever custom name generator rule you used.
author here! happy to answer questions
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?
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
Earlier quoted context omitted.
thanks Ajay, we're also big fans of yours here at Supabase :)
Hey it's unrelated but, what's the relationship between Supabase and Postgrest? My understanding is that Postgrest is a separate project that began development in an unrelated way to Supabase, and Supabase is just an user. Is that correct? But, Supabase is also a contributor to Postgrest, right? Does Supabase employs engineers dedicated to it?
Supabase uses PostgREST for its automatic/reflected REST API
> Supabase is just an user. Is that correct?
yep!
> Does Supabase employs engineers dedicated to it?
There is no way every cloud provider won't jump on this as soon as it's stable for their Postgres offerings.
How does it compare with https://github.com/solidsnack/GraphpostgresQL ? It's like 7 years older and it takes the same approach, it seems.
I am the person who wrote it. It was a proof-of-concept, written in PL/pgSQL. This made it fairly easy to set up and test but made maintenance and contributions very difficult.
This is awesome! Really creative approach to the problem. Does this also support custom datatypes that can be marshalled to json? For example, PostGIS geometries?
https://supabase.github.io/pg_graphql/reflection/#type-conve...
are cast as strings, but prioritizing a JSON conversion if one is available is a great idea that we'll look into