Supabase is an open source Firebase alternative. Start your project with a Postgres database, Authentication, instant APIs, Edge Functions, Realtime subscriptions, and Storage.

Supabase

I'm in love with `pg_graphql` extension and it would be really nice to have also **subscriptions** to make it more complete!

There's a few caveats to keep in mind:

 - Realtime already exists, and there are plans to expand it even more later in the year
 - The concept of subscriptions aren't part of the GQL spec
 - Apollo notes that the older `subscriptions-transport-ws` library is no longer maintained, and `graphql-ws` uses a different subprotocol (https://www.apollographql.com/docs/react/data/subscriptions/#choosing-a-subscription-library), which makes compatibility a concern
 - Implementing RLS support on realtime took a long time and lot of work. Would it be worth it to duplicate such functionality into GraphQL?

I'm curious to hear what benefits you think it'd bring over an improved version of the core realtime functionality of Supabase.

I'd like to use the GraphQL endpoint as a single source of truth for my clients, and having also subscriptions available without using the supabase client would be nice I think. Speaking about Typescript, it would be great also for tools like `graphql-codegen`, because it would make it, again, the single source of truth for typings in the source code

PG GraphQL subscriptions - idea discussion

Again, as i'm in love with GraphQL and the `pg_graphql` extension, it would be nice if **PostgreSQL functions** could be exposed in the GraphQL endpoint, like it's done in Hasura (https://hasura.io/docs/latest/graphql/core/databases/postgres/schema/custom-functions/)

I mean, I know that if I create a function that accepts as an input a row of a table, that function gets exposed as a field in the table's graphql schema. What would be nice would be function accepts any as input and gets exposed in the root of the schema between other tables' schema, as Hasura does

supabase pls https://twitter.com/noahdigesu/status/1512535648762220557

Authentication -> policies tab shows policies for tables in public schema.
I have a view in public schema. The view reads from tables in different schema with existing RLS policies.
I think it would be great to have the same policy explorer for custom schemas as well

Not sure if this is a good idea... but I found it a little bit annoying where on the local supabase studio, the organization and project names are not configurable... Would there be any interest in allowing it to be configured via .env?

https://github.com/supabase/supabase/pull/6417

I think email sending (for custom formats) could be dangerous especially with how the team mentioned being targeted by phishers for hosting

Honestly, setting up sending emails was a pain since you either have to create a public table that is locked and updated whenever email would be updated
Or query auth table with another client

You could try doing that with an SQL function but securing that is not possible afaik, without postgres user or RLS on a public table

It's a nasty workaround

Any chance Supabase will move off of AWS?

Please read the channel description, is this an idea or a suggestion? if a question then it should be asked in <#839993398554656831>

I guess it is a suggestion and an idea; I'd be really interested in using a different cloud service provider

Well they for sure would not go to Google...😎

They used to be on DigitalOcean in the early days but moved over to AWS.

There's always the option to self-host, which works on any provider which supports Docker. You could probably set it up on a non-Docker host too, but it'd be a lot more work.

There are valid reasons for the PR to take its time.

I share your annoyance and would love for it to be merged quickly but it does have some valid reasons

You can already ask information about self-hosting in the help channel. We already have many channels plus threads and the search on discord is quite good.

seems like self-hosting has enough documentation to get going but not much support / resources / documentation to make that functional, have secrets management, etc

the documentation points to some good practices about these that i appreciate, but no direct documentation on how to do that

and so a channel where people can talk thru these and other things about self-hosting, ex) managing the docker container, could help

Could Supabase have built-in Role-based authorization and management.

is that for your 'app users' or for your project/organization members?

what kind of roles are you thinking about?

For the app users. Example would be like what Django comes with out of the box.

Track changes via repository and git commits similair to nhost, that would be ultra

What sort of changes and do you have an example of this you could point me to please?

I could imagine to add the local developed migrations and maybe dump files (if they contain functions & triggers - sry not that savy with sql) to a repository and  on merged pr to run the migrations against supabase hosting.

I think if this is possible the way to multiple environments could be flattened as prod would be connected to master and own instance of supabase

As dev would have its own instance of supabase

We currently use Postgres and believe it's a great solution for most problems. As far as I can tell MongoDB is not on our roadmap.

as i understand it, supabase relies on PostgreSQL fundamentally

I'd love to see a REPL combination like svelte.dev + sqlfiddle for people to share a minimum reproducible examples.