Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.
Wondering if anyone knows how or of a package that allows migrations to be done on multiple databases without having the additional connection in the config file. Currently I have two different connections, one for the default and another for the tenants. The tenant connection has the credentials input, but it doesn't have the database name since each tenant will have a different database name. Problem is when I'm doing the initial setup and need the migrations to be run it will do it for the default or the tenant(if I edit the file to include the database name). I had found a package that would do it but it is not currently compatible with laravel 5. Obviously if I have to do it manually it can be done. It would just be a pain. Thanks in advance for suggestions.
I'm not sure why you don't want to specify another connection.
You can have more than one connection specified, and switch between them as required when doing the migrations for different tables.
These connections can be specified separately in your env file, and so can be different on development and production.
See http://laravel.com/docs/5.0/database#accessing-connections
I do have another connection. I have my default and I have my tenant connections. It is a single codebase multi database app. I was trying to find a solution where I didn't have to have 100+ different database configs in the file. The database name is different for each tenant (based off of their given subdomain). So database name would be tenant1, tenant2, etc.
IMHO, when I start thinking of deploying a database automatically per tenant, it is (nearly) always a smell of a project that will never be deployed because of it's complexity.
Imagine the pain for changing your database schemes etc. So much work.
Before trying to resolve this kind of problem, ask yourself if you really need to complicate this as much.
Can you explain why you want to implement a per tenant database logic?
Because the data has to be kept separate for each client. This is an application that is for a medical field. Trust me, I've thought about doing the single database, but couldn't run the risk of one overlooked query that exposes data from one clinic to another. Also because the application uses phone information for the clients, and if a client has been to more than one clinic it would be hard to determine which clinic the request should go to if it were a single database. I understand when it comes to migrations it will definitely take longer than having a single database, but having something that can do migrations on multiple databases would make this less of a pain.
@Jmrtech does your app keeps in some table a list of all the tenant database names?, if you do, then you already have the solution, let me know so I can help you.
Please or to participate in this conversation.