Hello, I have a question around the platform. We're a multi-tenant company meaning that we build the "same" data models for each of our tenant. Effectively, we run the same models but the parameters that we use are different per tenant. Concretely, we can run 10 different instances of our same "package" each instance being defined various variables alike

env_var('tenant_name')

env_var('output_database_name')

and so on. Having said that, does Elementary supports differentiating between different runs based on variables and it is also possible to merge them as one, so that we can get the average "execute time" for our models across tenants, for example. Thanks!

hi @CAB, sorry for the late response 😅 i dont believe we have a clean solution for your use case, as it is pretty unusual, but maybe i can help you find a dirtier one 😈 how does elementary work currently in your company? does every project write to the same elementary schema? or do you have a schema per instance?

Hello! Thanks for replying! We've created internal tooling that generates the elementary.html file based on a CLI, allowing us to select which tenant we want to display Elementary reports on. For example:

make elementary

yields a prompt where you can select a tenant, and when a tenant is selected, we boot up our dbt docker container with the selected information and generate the elementary reports. This makes is so that you can only see the information of one tenant at a time, as we override the previous html file. Ideally, we would be able to see an aggregated report container the information of all tenants. To explicitely answer your question; all project write in different elementary schema based on the tenant_name, tenant_environment.

Firstly, that tool sounds pretty cool 😉 a neat idea might be for you to create a

union_elementary_schema

, which contains views that union the elementary schema from all of your tenants, and then running

edr

agains this schema.

I thought about doing this, but I wasn't sure if there could potentially be clashes with how you folks generate identifiers throughout the different tables. Is that a wrong assumption of mine?

hmm that might be an issue, since they are all the same dbt project. you can try changing the name in

dbt_project.yml

according to the env variables, that way the identifiers would be different, something like

name: 'my_project_{{env_var("tenant_name")}}_{{env_var("output_database_name"}}'

I'll consider that; the issue is that we're dependent on that name being hard-coded to something specific for the time being. Another question I'd have with your suggestion: How would I go about filtering one tenant vs. another after I've unioned the schema? It feels like there is no good way to filter that in the current reporting UI.

It will be tough, elementary is really not built for that sort of thing Tho if you do modify the project name, then in the sidebar it should be separated by project

d, I'll see what I can do on my hand. Thank you for taking the time to answer back! I appreciate it! 🙂 I'm happy to talk with whoever would be interested in learning more about our use case so that you can consider addressing multi-tenancy issues in a subsequent product roadmap!