What Multi-Tenant Actually Means
Multi-tenant architecture serves all customers from a single deployment. Each tenant gets isolated workspace with separate data, configuration, and branding on shared infrastructure.
For real estate platforms, the critical question is how to isolate tenant data so Developer A’s records never leak into Developer B’s environment.
Database-per-Tenant vs. Shared Database
Shared Database, Shared Schema
All tenants share tables. A tenant_id column separates data. Cheapest but riskiest — a single missing WHERE clause exposes data.
Shared Database, Separate Schemas
Each tenant gets their own schema within a shared database. Better isolation but complex migrations.
Database-per-Tenant (QubeHub’s Approach)
Each tenant receives their own dedicated PostgreSQL database. Complete physical separation. The gold standard for high-value transactions.
QubeHub uses database-per-tenant isolation. Every property developer gets their own PostgreSQL database with independent connection strings, migrations, and backup schedules.
Security Benefits of Tenant Isolation
Physical Data Separation: No application-level WHERE clause between tenants. Data lives in entirely separate databases.
Independent Encryption: Each tenant database can use its own encryption keys.
Audit Logging: Tenant-specific audit logs make compliance straightforward.
Independent Backup: Each tenant can be backed up and restored independently.
In real estate, your data is your competitive advantage. Pricing strategies, lead pipelines, conversion funnels — the architecture that protects them should leave zero room for cross-contamination.
— QubeHub.ai EngineeringScalability for Multi-Project Developers
Adding a new tenant is an operational task — provision a database, run migrations, configure — not an architectural challenge. Tenant provisioning takes seconds.
Performance: Caching, Pooling, and Resolution
Tenant Resolution Caching: LRU cache with 5-minute TTL. Warm requests resolve in under 1 millisecond.
Connection Pooling: PrismaClient instances cached in an LRU pool (50 entries, 30-minute TTL). Active tenants maintain warm connections.
Async Context Propagation: Tenant context propagated via AsyncLocalStorage through the entire request lifecycle.
Result: 50ms cold start, under 1ms warm requests. Multi-tenant overhead is negligible.
Why It Matters for Real Estate
High-Value Transactions: A single unit sale can represent hundreds of thousands of dollars.
Regulatory Compliance: GDPR, KYC, and AML requirements demand defensible isolation.
Competitive Intelligence: Developers compete fiercely on pricing. Database isolation eliminates theoretical risk.
Operational Independence: Data exports, backup restorations, and migrations affect only one tenant.
Shared DB vs. Isolated DB Comparison
| Dimension | Shared Database | Database-per-Tenant (QubeHub) |
|---|---|---|
| Data isolation | Application-level (WHERE clause) | Physical separation |
| Breach blast radius | All tenants exposed | Single tenant only |
| Backup granularity | All-or-nothing | Per-tenant independent |
| Migration complexity | Single migration, all tenants | Per-tenant, progressive rollout |
| Noisy neighbour risk | High | None |
| Compliance auditing | Complex filtering | Clean per-tenant audit trails |
| Onboarding speed | Instant (add row) | Seconds (provision database) |
| Per-tenant customisation | Limited | Full |
| Infrastructure cost | Lower | Slightly higher |
| Enterprise buyer confidence | Low | High — architectural isolation |