Skip to content

Data Handling and Isolation

How customer data is separated in a multi-tenant ForgeVault deployment: the mechanisms, what is deliberately shared, and the higher-isolation options.

Status. This is the isolation architecture for the managed multi-tenant VirtualForge cloud, which is under active development. It is a set of settled design decisions and it is what we are building — not a description of a platform already serving production tenants.

ForgeVault is available today through an Endeavor Engineering engagement, provisioned and operated for you; in that model your instance is dedicated by construction, which is a stronger position than anything below. The Seeq connectors are a separate case again: they run inside your own environment and read your historian directly, so your data never leaves your estate.

Two kinds of data, handled differently

Your operational data — time-series measurements, ingested data, and the metadata describing them — lives in a database dedicated to your organization, and within it, in your own schema.

Platform and account data — organizations, users, subscriptions, and configuration — lives in a shared platform database. It holds no operational data. This is a deliberate trade, and it is called out again under What is shared.

The isolation layers

Four layers, so that a defect in one does not expose data:

1. API authorization. Every request is authenticated and carries an organization identity. The API scopes all database work to that organization before a query is issued, and the check is server-side — a modified request cannot bypass it. Cross-organization access is prohibited outright rather than permitted-and-filtered.

2. Database and schema separation. Your operational data is in its own database, and within it your own schema. Connections for your operations target that database and are schema-scoped. There is no cross-database or cross-schema access between customers.

3. Row-level security. Where any table is shared, database-level RLS policies enforce organization-scoped visibility. This is defence in depth: it holds even if the application layer has a bug.

4. An explicit identifier on every row. Time-series rows carry the organization identifier as a real column, which gives both a queryable audit trail and a validation point inside the schema.

Schema names are opaque

Schema names derive from an internal identifier, not from your company name — customer_a3f8b2c1 rather than customer_acme_corp. That avoids name collisions, removes a class of injection risk, and means a rebrand does not require a data migration.

What is shared

Stating this plainly, because a vendor claiming total isolation on shared infrastructure is either misinformed or selling:

  • The platform database is shared. Account and organizational records for all customers live in one database instance. Row-level security and application-layer scoping enforce separation there; it is not a per-customer database.
  • Compute may be shared in the standard tier. A database-level performance problem on shared infrastructure can therefore affect more than one customer's responsiveness. It does not affect data separation.
  • Encryption uses a managed key by default. Storage is encrypted at rest, but the standard tier uses a provider-managed key rather than one held per customer. A customer-managed key is available on the higher tiers below.

Higher isolation tiers

For regulated or otherwise demanding requirements, isolation can be extended. These are engagement options rather than self-service settings — talk to us about which fits.

Tier What you get
Standard Dedicated database for your operational data, your own schema, shared platform database and compute, managed encryption key
Dedicated instance Your operational database on its own instance: performance isolation, dedicated backups, and a dedicated encryption key
Dedicated deployment A fully dedicated VirtualForge and ForgeVault stack, with no shared infrastructure at any layer. This is also the route to an on-premises deployment

Data residency

Where data must remain in a particular jurisdiction, the mechanism is a dedicated instance in the required region, with your organization assigned to that deployment. This is handled per engagement rather than as a self-service region picker — raise it early, because it shapes which tier applies.

Backups, retention and deletion

Backups are taken at the database level and encrypted, with retention set to meet compliance and contractual requirements. As with the rest of this page, that describes the managed multi-tenant design; for a ForgeVault instance we operate for you today, backup and retention are agreed as part of the engagement.

Deletion and extraction requests — including data-subject requests where they apply — are handled as an operational procedure with us rather than as a self-service function. If you have a specific obligation with a defined response window, raise it during contracting so the commitment and the mechanism are agreed in writing rather than assumed.