Graphql-engine: 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.

On Wed, Mar 20, 2019 at 7:40 PM Rajiv Abraham [e-mail]
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
https://github.com/hasura/graphql-engine/issues/821#issuecomment-474846157,
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 [e-mail]
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
https://github.com/hasura/graphql-engine/issues/821#issuecomment-475685543,
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