Hybrid Tenant Architecture

Problem

The client was building a B2B marketplace where transport companies stored sensitive operational data. With a shared database, one bad query or access control bug could leak Company A's data to Company B, a massive problem for enterprise customers. But spinning up fully isolated infrastructure per tenant would burn through their runway at the current stage.

Constraints

• Full app-and-db isolation per tenant would multiply infra and operational overhead.
• Shared everything storage increased blast radius and customer trust concerns.
• We needed a model that supported tenant growth without creating per tenant deployment workflows.
• The team needed operational simplicity over maximal architectural purity at this stage.

Solution

• Implemented a hybrid tenancy architecture.
• Kept a shared app tier for routing, auth, and business logic.
• Provisioned a separate Turso database per tenant for stronger data boundaries.
• Chose this middle ground over full single tenant stacks to keep cost and operations manageable while still improving isolation materially.

Outcome

• Improved tenant isolation significantly without adding per tenant app servers.
• Reduced cross tenant data risk compared to shared database approaches.
• Preserved a deployment model small teams can actually maintain week to week.
• Established an architecture that can evolve toward stricter isolation later without a full rebuild now.

Stack

• Node.js (Fastify)
• Turso (LibSQL / SQLite)
• Fly (infrastructure)