You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Was spinning up a project and was going to do a database per organization with sqlite, as that combination seems very appealing for my use case but I got
** (Spark.Error.DslError) multitenancy -> strategy:
Data layer does not support multitenancy
Postgres just seems too heavy weight for what i want to do, and i don't really want to have to deal with setting up a cloud database instance, was hoping to just keep it simple with sqlite. Was wondering if this is on the roadmap at all?
Per-database multi tenancy is something we'd like to support both in postgres & sqlite, but at the moment it's something you'd effectively need to roll yourself. You can set the repo in the context:
Opened #224, which implements this: strategy :context on AshSqlite, meaning one database file per tenant.
Worth flagging for anyone who finds this issue first — the workaround suggested above does not work. Setting %{data_layer: %{repo: ...}} in a change and a preparation selects between repo modules: both the read path and the write path invoke the result as a module, so passing a repo instance raises ArgumentError: Modules (the first argument of apply) must always be an atom. Database-per-tenant needs an instance, which is put_dynamic_repo/1 and is per-process.
#224 adds a tenant_binder instead, which the data layer calls once per statement — including the paths a caller cannot wrap from outside, like Ash.count/2 and atomic updates. It is stacked on #223 (transactions) and should merge second.
Activity
zachdaniel commentedon Feb 8, 2025
Per-database multi tenancy is something we'd like to support both in postgres & sqlite, but at the moment it's something you'd effectively need to roll yourself. You can set the repo in the context:
You could then add this to each resource's global change & preparation blocks:
Support context multitenancy
C-Sinclair commentedon Aug 21, 2026
Opened #224, which implements this:
strategy :contexton AshSqlite, meaning one database file per tenant.Worth flagging for anyone who finds this issue first — the workaround suggested above does not work. Setting
%{data_layer: %{repo: ...}}in a change and a preparation selects between repo modules: both the read path and the write path invoke the result as a module, so passing a repo instance raisesArgumentError: Modules (the first argument of apply) must always be an atom. Database-per-tenant needs an instance, which isput_dynamic_repo/1and is per-process.#224 adds a
tenant_binderinstead, which the data layer calls once per statement — including the paths a caller cannot wrap from outside, likeAsh.count/2and atomic updates. It is stacked on #223 (transactions) and should merge second.improvement: support `strategy :context` multitenancy via a tenant bi…
improvement: support `strategy :context` multitenancy via a tenant bi…
improvement: support `strategy :context` multitenancy via a tenant bi…
improvement: support `strategy :context` multitenancy via a tenant bi…
improvement: support `strategy :context` multitenancy via a tenant bi…
improvement: support `strategy :context` multitenancy via a tenant bi…
improvement: support `strategy :context` multitenancy via a tenant re…