Do you actually need a multi-tenancy package?

About this episode

The episode discusses evaluating multi-tenancy needs and the implications of choosing an architectural approach.

Ever feel like a project requirement says "we need multi-tenancy," and you're not even sure what that means in your specific context? In the latest episode of the No Compromises podcast, we discuss how to evaluate multi-tenancy needs before committing to an architectural approach. We break down what multi-tenancy actually means, from separate databases to custom domains and per-tenant configuration, and why the real question isn't which package to use, but whether you need one at all. We also explore when hand-rolling a simple solution beats adopting a full package, what legal and compliance requirements can force your hand, and why this is one of those decisions that's genuinely hard to undo later. 00:00 Defining what multi-tenancy actually means 02:11 Different ways to structure multi-tenant systems 03:44 When separate databases are truly necessary 04:57 Questions to ask before choosing an approach 08:25 Package vs. rolling your own trade-offs 11:30 Silly bit If you want guidance on decisions like these, check out our code review service to get expert eyes on your architecture.

People in this episode

Hosts: Joel Clermont, Aaron Saray

Topics covered

• multi-tenancy
• architecture
• database management
• compliance
• software development

Keywords

• multi-tenancy
• architecture
• databases
• compliance
• software packages
• custom domains
• configuration

More episodes of No Compromises

• How much logic is too much logic in a PHP enum · June 6, 2026 · 13 min
• Your codebase is not a museum for old code · May 23, 2026 · 14 min
• Do you actually own the code you ship? · May 9, 2026 · 15 min
• Local and production should match even for Laravel tools · April 11, 2026 · 13 min
• When weird code needs to explain itself · March 28, 2026 · 11 min
• Are you testing your app or just the framework? · March 14, 2026 · 13 min