To do that with Ash the way it generally works is that you can set a context in your action to set (or override the default) repo. For example:

read :read do
  prepare fn query, _ -> 
    repo = figure_out_repo()
    Ash.Query.set_context(query, %{data_layer: %{repo: repo}})
  end
end

You can abstract this using a module-backed preparation, and attach it to a resource using the global preparations block in the resource, to trigger it on all queries:

preparations do
  prepare SetDynamicRepo
end

Not necessarily a full breakdown, but that should give you a starting point

Totally, makes sense. We ultimately want Ash to be able to support all of those models too, even though naturally database per tenant will be a bit more challenging than the alternatives. I could even see a case for building database-per-tenant multi tenancy into ash_postgres as a first class thing at some point.

So, there are two relevant answers here.

Changes are the equivalent of preparations for other action types

Preparations are for read actions only, but changes can do the same thing for all other action types.

changes do
  change SetDynamicRepo
end

Keeping process context

For this, you need to add an Ash.Tracer. Ash.Tracer can “move” process context from one process to any process that Ash starts.

defmodule YourApp.DynamicRepoTracer do
  use Ash.Tracer

  def get_process_context() do
     get_dynamic_repo()
  end

  def set_process_context(repo) do
    set_dynamic_repo(repo)
  end
end

And then you can configure the tracer statically:

config :ash, tracer: [YourApp.DynamicRepoTracer]

YMMV on using put_dynamic_repo, but will be interested to hear how it goes if you go that route.