Per-Tenant Database Isolation Architecture

Executive summary

PulseCargo provisions a separate SQL Server database for every customer tenant. This is more expensive operationally than the row-level filtering pattern most multi-tenant SaaS uses, and it is the right trade-off for freight forwarders’ procurement and compliance environment.

This paper describes how the isolation works in practice, what threats it mitigates that row-level filtering does not, and what audit evidence it produces.

1 — The pattern most SaaS uses, and why it’s not enough

The dominant multi-tenant SaaS pattern is shared-schema with tenant ID. One database. All tenants’ rows in the same tables. A tenant_id column on every row. Application code adds WHERE tenant_id = @currentTenant to every query.

This pattern is cheap to operate. It works at scale. It is also one developer mistake away from a cross-tenant data leak, and that mistake has happened publicly to enough vendors that procurement teams now ask about it explicitly.

The failure modes are well documented:

• Forgotten WHERE clause. A new query, a refactor, a stored procedure migration. One missing predicate exposes one tenant’s data to another.
• ORM filter bypass. Query filters in EF Core, Hibernate, ActiveRecord can be bypassed via raw SQL, dynamic queries, or framework escape hatches.
• Cache key reuse. A tenant ID dropped from a cache key returns another tenant’s cached result.
• Background job context loss. A background worker pulls “all rows” without tenant context.
• Reporting layer. BI tools connecting directly to the database often bypass application-layer filters entirely.

These failure modes are not hypothetical. The OWASP API Top 10 (BOLA — Broken Object Level Authorization) is the most-reported API vulnerability of the past three years and the underlying cause is, in most cases, exactly this pattern.

PulseCargo chose a different pattern.

2 — What PulseCargo does instead

PulseCargo provisions a separate SQL Server database for each tenant. The naming convention is:

• PulseCargoDb — the portal database, holding tenant identities, billing plans, service agreements, portal admin accounts, and the cross-tenant infrastructure.
• PulseCargo__<tenant-slug> — one per customer tenant, holding all of that tenant’s customer data: shipments, orders, containers, customs entries, invoices, documents, audit logs, AI query logs.

The web tier, API tier, and background workers receive a tenant identifier on every request via the TenantResolutionMiddleware. The middleware looks up the tenant slug, computes the connection string for that tenant’s database, and binds that connection to the request scope. Every database call within the request — whether through Entity Framework Core, Dapper, or direct ADO — uses that bound connection.

A query that does not have a tenant scope cannot connect to a tenant database, because there is no tenant database to connect to without a tenant identifier. The forgotten-WHERE-clause failure mode does not exist; there is no shared table to forget the WHERE clause on.

3 — What this protects against that row-level isolation does not

Threat	Row-level isolation	Per-tenant database isolation
Forgotten WHERE clause exposes other tenants’ rows	Possible — depends on every query being correct	Impossible — separate database
ORM query filter bypass via raw SQL	Possible	Impossible
Background job pulls all rows without tenant context	Possible	Impossible — job must specify tenant to get a connection
Cache key reuse returns wrong tenant’s data	Possible	Cache keys themselves are tenant-scoped because connection strings are
BI tool connects directly and reads cross-tenant	Possible — must layer additional security	Impossible — BI tool credential is per-tenant
Backup restored to wrong place exposes other tenants	Possible	Impossible — each tenant has their own backup; restore is to that tenant only
Compliance auditor asks “show me cross-tenant access controls”	Multi-layer answer (filters, RLS, application code, audits)	Single-layer answer (separate connection string)

The last row matters disproportionately. SOC 2 Type II reviews, ISO 27001 audits, and Fortune 500 procurement security questionnaires all ask some variant of “how is one customer’s data separated from another’s?” The shorter and stronger the answer, the faster the review concludes.

4 — Operational cost

This pattern is not free. The trade-offs:

4.1 Higher per-customer storage cost

Each tenant database has its own indexes, transaction logs, statistics, and overhead. The marginal storage cost of a small tenant is higher than it would be in a shared-schema model.

We accept this cost. It is materially smaller than the cost of a cross-tenant data leak, and it scales linearly rather than catastrophically.

4.2 More expensive cross-tenant analytics

Aggregated analytics — the cross-tenant industry benchmarks PulseCargo offers as an opt-in feature at the Professional tier — require collecting data from every participating tenant database and computing the benchmark separately. This is where most shared-schema vendors get cheap aggregate queries.

We solve this by treating cross-tenant analytics as a separate process: a background job iterates participating tenants, computes per-tenant statistics, and writes the aggregate to a dedicated benchmark store. The cost is a once-daily job rather than instant queries; the benefit is that the aggregation is k-anonymous (k ≥ 5) by construction and the participating tenants have explicit opt-in via Tenants.EnableAggregatedAnalytics.

4.3 More work at provisioning time

A new tenant requires database creation, schema migration, starter-pack import, and EF migration history backfill. PulseCargo’s scripts/backfill-tenant-ef-history.ps1 and tenant-provisioning pipeline automate this; it is roughly a two-minute provisioning step.

4.4 More attention to schema migrations

Schema changes have to be applied across every tenant database, not just one. PulseCargo uses EF Core migrations applied at deploy time per tenant, with rollback paths. The discipline cost is real but the deployment pipeline handles it transparently.

5 — How this composes with the rest of the security posture

Per-tenant database isolation is the substrate. The rest of the security model layers on top:

• AES-256 encryption at rest via SQL Server TDE and Azure Blob Storage encryption.
• TLS 1.3 enforced for all in-transit data.
• Native multi-factor authentication (TOTP) with optional Twilio SMS factor and Microsoft 365 / Google Workspace SSO federation at portal and tenant scope.
• Role-based access control with portal-admin, tenant-admin, tenant-user, and per-client-association roles.
• Audit logging on every inbound request via AuditLoggingMiddleware, on every CargoWise webhook, on every Synthetic Intelligence query.
• Data subject rights endpoints for GDPR Art. 5 / 32 / 33 and CCPA / CPRA § 1798.100 / .105 / .150 — /request, /request-deletion, /export, /opt-out ship as user-initiated; admin-initiated export ships separately.
• Software escrow through NCC Group, Iron Mountain, or EscrowTech with ZIP deposits including source code, per-tenant plugins, SQL backup, and SHA-256 manifest. Rehydration tested end-to-end — never dry-run only.
• Multi-framework compliance tracking — SOC 2, ISO 27001, GDPR / CCPA, OWASP, NIST, and additional industry frameworks. SOC 2, ISO 27001, GDPR, CCPA, and CTPAT have populated control libraries today; additional frameworks tracked with templates being authored. Full framework list available on request.

6 — Tenant isolation audit results

PulseCargo conducted a comprehensive tenant-isolation audit on 2026-04-24. 61 controllers and approximately 140 endpoints were reviewed for cross-tenant data exposure. Zero CRITICAL findings. The full audit report is shareable with security teams on request.

The one INFO-level finding identified — outbound integration audit logging not yet implemented for all third-party services (Stripe Connect, TMS provider probes, AI providers) — is being expanded to close the SOC 2 CC4.1 / CC7.2 evidence gap. The pattern is in place for eAdaptor; remaining services are in the build queue.

7 — What this means for procurement reviews

If you are a freight forwarder evaluating PulseCargo against vendor-security standards, the recommended question pattern is:

1. “How do you isolate tenant data?” Per-tenant SQL Server database isolation, resolved at the middleware layer. Not row-level filtering.

2. “What happens if a developer makes a mistake?” A query without tenant context cannot connect to a tenant database. The forgotten-WHERE-clause failure mode does not exist.

3. “Show me your last cross-tenant audit.” Tenant Isolation Audit dated 2026-04-24, 61 controllers, ~140 endpoints, zero CRITICAL findings. Available on request.

4. “Show me the data subject rights flow.” Self-service endpoints under /api/me/privacy/* plus admin-initiated under /api/admin/users/{id}/privacy/*. Both ship today.

5. “What about backups?” Each tenant has its own backup. Restoration is to that tenant’s database only. Software escrow available with NCC Group / Iron Mountain / EscrowTech, including end-to-end tested rehydration.

6. “What about your compliance certifications?” SOC 2 Type II is on the active certification path. ISO 27001 evidence is being collected. GDPR / CCPA controls map to specific endpoints today. The compliance framework platform is the substrate for ongoing evidence collection.

8 — About PulseCargo

PulseCargo is the Synthetic Intelligence layer for freight forwarders, sitting on top of the existing TMS (CargoWise live today; Magaya, Descartes, GoFreight on the roadmap). Per company, not per seat. Five tiers from Starter Lite (self-service evaluation) to Enterprise+ (multi-region, dedicated infrastructure). Talk to sales for tier scoping and pricing.

To request the full Tenant Isolation Audit report, the SOC 2 readiness package, or a security-team briefing: pulsecargo.ai/contact or security@pulsecargo.ai.

---

This paper is © 2026 PulseCargo, Inc. PULSECARGO is filed with the USPTO under Section 1(b) Intent to Use; the ™ designation is in effect.