Full disclosure, I’m drunk and didn’t read this entire thread, but…

Should I run a database to use dynamic repo?

Yes. We have a multi-tenant app. We have one Postgres database that has a clients table which basically has a mapping of {client_name: database_instance}. This database is a “normal” Ecto.Repo.

Each “shard” (aka client specific database) is also a normal Ecto.Repo, and all of them have to be started up on application boot.

defmodule Datastores.Shard.Supervisor do
  @moduledoc false

  def child_spec(config) do
    %{
      id: __MODULE__,
      start: {__MODULE__, :start_link, [config]},
      type: :supervisor
    }
  end

  def start_link(config \\ []) do
    Datastores.Shard.dynamic_repos()
    |> Enum.map(fn name ->
      config = Keyword.merge(Datastores.Shard.config(name), config)
      %{
        id: {Datastores.Shard, name},
        start: {Datastores.Shard, :start_link, [config]}
      }
    end)
    |> Supervisor.start_link(strategy: :one_for_one, name: __MODULE__)
  end

  def stop do
    Supervisor.stop(__MODULE__)
  end

end

So once all the “shards” are started, then you can use get_dynamic_repo to reference them.

Happy to help more once I’m more sober. I really really like put_dynamic_repo, get_dynamic_repo, and c:default_options. Between those functions/callbacks, it’s pretty easy to make a multi-tenanted Ecto application… until you get to migrations…

What errors does it throw?

Hmmm… at first I though I understood what you were asking, but looking deeper I’m less convinced I understand the issue.

I’m chiming in because I’m using dynamic repos for what may be similar purposes. I also have no default and the setup is working well for me. I’ll start from the beginning with my use case and maybe you can see how it aligns with yours. I’m also working on a multi-tenant application, but only targeting PostgreSQL. The nature of my application and its use cases/usage patterns allow me to use a database per tenant instance of the application. In addition I have a management database which controls things, but I don’t want that (or any one tenant) to be considered the “default” database or repo within the application. If a dynamic repo has not been set for the process via put_dynamic_repo, I want any attempted uses to fail. There simply is no default.

Now having said that, there are bits of the Repo I need running. So for example I do have an Ecto configuration setup in config.exs, but it’s very simple:

import Config

config :msbms_syst_datastore,
  ecto_repos: [MsbmsSystDatastore.Runtime.Datastore]

(assume that the MsbmsSystDatastore.Runtime.Datastore module above is just the repo module, with use Ecto.Repo because that’s what it is with just a different name).

The top of MsbmsSystDatastore.Runtime.Datastore looks like:

defmodule MsbmsSystDatastore.Runtime.Datastore do
  @moduledoc false

  use Ecto.Repo,
    otp_app: :msbms_syst_datastore,
    adapter: Ecto.Adapters.Postgres

[CLIP]

end 

And that’s all that’s there related to Ecto.Repo. I do identify the adapter for the repo.

I believe, but am not sure, that having that configuration is sufficient for Ecto to start up things like it’s process registry and it’s own necessary components. Note that there is no database configuration beyond identifying the adaptor to use. Just the enumeration of the repo module existing. In fact, that’s the whole of my config.exs file.

This particular application has no “MyApp.Application” module nor does it start anything up special.

Are you configuring anything at compile time?

Would love to hear how you’re handling migrations.

This is how we’re doing it: