SaaS Architecture Patterns for Scalable Platforms

Building multi-tenant Software-as-a-Service (SaaS) platforms requires finding the sweet spot between hosting costs, system performance, and tenant isolation compliance. A single database leakage incident can destroy a startup's reputation. Developers must design databases and file stores so that data scoping is automated and secure.

This research paper explores SaaS tenancy architectures, comparing database-per-tenant, schema-per-tenant, and shared-schema designs. It provides concrete examples for implementing PostgreSQL Row-Level Security (RLS), dynamic AWS S3 directory isolation middleware, and composite indexing.

1. Tenancy Models Comparison

When architecting SaaS platforms, we evaluate three database separation models:

1. Database-Per-Tenant: Every tenant receives a dedicated database. Highest isolation security, but raises host overhead costs and complicates database updates (e.g. running migrations across 1,000 databases).
2. Schema-Per-Tenant: Tenants share the same database cluster but reside inside distinct database schemas. High speed, but migration scripts remain complex.
3. Shared Database, Shared Schema: Tenants share tables. Columns include a tenant_id. Highly cost-effective and simple to manage, but requires automated query scoping to prevent leakages.

2. PostgreSQL Row-Level Security (RLS)

Instead of managing tenant filtering solely in the application code, we can configure Row-Level Security (RLS) directly in the database engine. In PostgreSQL, we enable RLS policies on tables, ensuring queries automatically filter rows using active session parameters:

-- 1. Enable RLS on the target table
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;

-- 2. Create the policy checking current session variable
CREATE POLICY tenant_isolation_policy ON orders
    FOR ALL
    USING (tenant_id = NULLIF(current_setting('app.current_tenant_id', true), '')::integer);

-- 3. Application database connection helper:
-- Before resolving any order query, the web server executes:
-- SET LOCAL app.current_tenant_id = 14;
-- Subsequent queries like 'SELECT * FROM orders' are automatically scoped.

3. Isolating Tenant File Storage (AWS S3)

Separating databases is only half the battle. Document storage (like invoices, receipts, and client profile attachments) must also be isolated. We implement Laravel middleware that dynamically scopes the S3 storage root directory for each tenant request:

namespace App\Http\Middleware;

use Closure;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Storage;
use Illuminate\Support\Facades\Auth;

class ScopeTenantS3Storage
{
    public function handle(Request $request, Closure $next)
    {
        if (Auth::check()) {
            $tenantId = Auth::user()->tenant_id;
            
            // Set dynamic S3 prefix for current request thread
            config([
                'filesystems.disks.s3.root' => "tenants/tenant_{$tenantId}/uploads",
            ]);
            
            // Re-resolve the filesystem drive to apply config overrides
            Storage::forgetDisk('s3');
        }

        return $next($request);
    }
}

4. Architecture Diagram

This visual outlines request routing: incoming HTTP headers identify the tenant, which configures database session variables before querying shared clusters.

5. Performance Benchmarks

The table outlines database query performance across different tenant models at high scale (10,000,000 orders database benchmark):

Conclusion

Building scalable SaaS platforms requires embedding tenant filters deep inside the system. By combining database Row-Level Security with dynamic AWS storage middleware and composite index designs, we achieve high-speed queries and strict tenant isolation at a lower hosting price point.