Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.
Hi everyone 👋
I’m currently discussing this with my team and would love to hear opinions from the community.
The question is simple:
From what I’ve seen and in my own experience, I tend to prefer one database per app. It feels cleaner since each project owns its own migrations and seeders, and deployments don’t risk breaking other apps.
But I also understand the counter-argument: with a shared DB you avoid duplicating schemas and sometimes reporting is easier.
👉 Based on your professional experience, which approach works best long-term in Laravel projects?
I’d like to reinforce this discussion with my team using insights from the community.
Thanks a lot 🙏
@adrianchodev in my opinion:
One database per Laravel app is usually best, each project manages its own migrations/seeders, avoids conflicts, and makes deployments safer.
One shared database only makes sense if apps are tightly coupled around the same schema and you truly need central reporting without a data warehouse.
Based on my experience, one database per Laravel app is usually best and safest.
@tisuchi Thank you for your appreciation.
It depends a bit on what you mean with database.
Are we talking a single database server with multiple schemas, or are we talking multiple database servers.
You can safely use a single server with multiple schemas, the RDBMS can handle a lot of traffic.
@Tray2 Thanks for the clarification! In my case, I mean separate schemas per application vs. one shared schema across multiple apps. Since Laravel migrations and seeders are app-specific, I see a real risk of conflicts if two projects touch the same schema. That’s why I lean towards giving each app its own schema, even if they all run on the same server. This way I can still maintain a single server while improving maintainability.
Would you agree this is usually the safer long-term practice?
They should have their own schema, the only only time they should share the schema, is when it's a multi-tenant app, or there is web version and one mobile app for the same app.
Ive seen the odd case of multiple applications using the same schema (the same database) and it never ends well. Its a bit of a maintenance nightmare, and certain scenarios might require you to take all apps off line at once.
If you go down this route, I would create a separate application and repo just for the migrations and put one person in charge of it. Any changes needed to the schema for one app have to go through this one person so that they can consider the global implications. All migrations would need to be through the database app.
Don't use the database for sessions or queues, Use another technology like redis where you can tag the content per application.
Im sure there are loads of other issues that are not immediately apparent when you choose to walk down the road less travelled.
@Snapey Thanks a lot for taking the time to reply. Your insights are really valuable and help me a lot in this discussion.
@adrianchodev You should have a database per separate Laravel application. I’m not sure why you would “share” a database between multiple, unrelated applications.
Please or to participate in this conversation.