Multi-Tenant Architecture

One of the core architectural decisions in Devlog.ist was implementing multi-tenancy. Here's how we did it.

Why Multi-Tenancy?

Each user gets their own isolated data space while sharing the same application infrastructure. This allows us to:

• Scale efficiently - One codebase, many users
• Ensure data isolation - Each user's data is completely separate
• Simplify deployments - Single deployment serves all tenants

Our Approach: PostgreSQL Schemas

We chose PostgreSQL schema-based multi-tenancy:

// TenantManager resolves the current tenant
class TenantManager
{
    public function setTenant(Tenant $tenant): void
    {
        DB::statement("SET search_path TO {$tenant->schema}");
    }
}

Benefits

1. Strong data isolation - Each tenant has its own schema
2. Easy migrations - Run migrations per schema
3. Flexible queries - Can query across tenants when needed (admin)

Challenges Solved

• Session management - Tenant context persists across requests
• Queue jobs - Jobs carry tenant context
• Filament integration - Admin panel respects tenant boundaries

This architecture has served us well as we scale to support more developers!