I would generally advice to not put anything in this file.

The main scope of this file is to simply generate the necessary repo functions based on the features provided by your underlying database engine, hence why it’s defined here and not in the application config. For example if you are using a database that doesn’t support transactions, calling Repo.transact or similar functions will raise a compile-time warning, making it easier to make sense of it.

The only exception I can see where it would make sense is if you are planning on adding additional core functionality for your repo that is not supported out of the box and requires you manually calling the adapter functions.

Remember that innocent line, use Ecto.Repo, is itself bringing a large amount of functionality into the module filling out much of the typical purpose of the module. For many, that’s going to be sufficient on its own without needing to go further.

In an application I’m working on, I’ve actually got a fair amount of code there… but I’m also a bit off the standard Ecto implementation. My application uses dynamically defined and started datastores (meaning at runtime), so the Repo doesn’t really represent a single database in my application, but rather is the means by which to start, stop, and manage multiple repositories. So putting this management code in the Repo module makes sense with this broader definition. But again, most won’t have that.

In the end, I’d just leave you with… if you don’t have any specific, clear need of anything that’s best represented as being part of your “datastore”… don’t sweat it: those few lines are just fine and will take you far. Once there’s a real reason to put something there, you’ll likely be feeling it.