support for accessing multiple postgres database in graphql

[sandipmavani]

If possible also need dynamic change instance or database on runtime.

[revskill10]

@sandipmavani I think schema stitching is the way in this case.

[RAbraham]

graphql newbie here. My understanding of schema stitching is that it allows one to combine different schemas together from disparate sources. My use case here is that I want multi-tenancy within the same database instance by assigning a different database to a different user(of course, my solution may not be the best one for multitenancy, but I'm making a demo)

[ecthiender]

Does using different Postgres schemas[1] for modelling different tenants (instead of databases) help in your use-case? Hasura currently provides support for multiple schemas in a single database out of the box. [1]: https://www.postgresql.org/docs/current/ddl-schemas.html

…

On Wed, Mar 20, 2019 at 7:40 PM Rajiv Abraham ***@***.***> wrote: graphql newbie here. My understanding of schema stitching is that it allows one to combine different schemas together from disparate sources. My use case here is that I want multi-tenancy within the same database instance by assigning a different database to a different user(of course, my solution may not be the best one for multitenancy, but I'm making a demo) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#821 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAlnw_zlPbjjRn1RXJFbiCFav6HHVDxNks5vYkFagaJpZM4Xv_xt> .

[RAbraham]

@ecthiender Unfortunately, a schema per user is not enough. I need to allow users to create multiple schemas.

[coco98]

Well, you could have users create their own schemas within the same database too right? The use-case sounds interesting. Would love to understand more!

…

On Fri, Mar 22, 2019 at 12:23 PM, Rajiv Abraham ***@***.***> wrote: @ecthiender <https://github.com/ecthiender> Unfortunately, a schema per user is not enough. I need to allow users to create multiple schemas. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#821 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAIAWABbbcRTQR0r2ydCg7WcSb7rs0Jqks5vZQOEgaJpZM4Xv_xt> .

[jvice152]

i have a similar use case.

I cant speak for @sandipmavani , but we are isolating tenants on a database level. Id love to do schema but I dont think schea stitching is scalable as we add more and more tenants in. I also don't see the reason for holding N copies of a schema in memory when they are all the same, this would just hammer startup time/performance etc. It would be wonderful to be able to switch schemas at runtime, or provided in an optional header/argument

[RAbraham]

@coco98, just to give you context I'm making a demo/prototype platform. While there are advanced multi tenancy options available, the fastest thing I can think of is creating a database per person. Compared to the single database for multiple users with each having his own schema, the issues is that I think I have are:

• schemas become global namespaces. if one user wants to create a schema securities.stock, he'll have to append his username(or something similar) rabraham_securities.stock which is not bad but I prefer that they don't have to :)
• I'll have to ensure that each person can view/edit/delete schemas and data that they have access to(and not others) which would need additional code that I have to build. Right now, a separate database makes this easy.
• I'm not 100% sure of this one but it'll be easier for me to predict how much data each person is using and limit or charge based on storage if I use a separate database for now?

Let me know if you can think of better solutions.

Solving this ticket may be a long term solution and I, of course, speak without understanding the complexity, but could it be a matter of having another field called database_name in your api?

[ZhangShurong]

any updates?

[gwert]

Maybe not the simplest and cleanest option for everyone (or even this use case), but the foreign-data wrapper module (postgres_fdw) might be a way to solve this problem for some.

[fjdelaba]

Hi, has anyone found a solution for this?

[HuxleyMc]

Hi, has anyone found a solution for this?

This blog post from Hasura explains it well

https://hasura.io/blog/remote-joins-a-graphql-api-to-join-database-and-other-data-sources/

[tirumaraiselvan]

Hey folks,

This will be possible in v1.4. We also demo'ed the preview in the last 2 community calls: https://www.youtube.com/watch?v=8rfAkAiE2_I&ab_channel=Hasura

[tirumaraiselvan]

This is now released in v2.0.0 (currently in alpha): https://github.com/hasura/graphql-engine/releases/tag/v2.0.0-alpha.1