Built for many tenants, isolated by design.
If several business units or customers share one installation, they must be kept apart reliably. We enforce that separation in the database itself, not in the application code, so a bug in the application cannot expose one group’s data to another.
In plain termsData from different groups is walled off by the database, so even a software mistake cannot mix it.
Cloud native, stated as properties
Six things that matter operationally.
| Property | Why it matters to you |
|---|---|
| Elastic | Capacity follows the number of entities modeled, not the number of users watching. |
| Horizontally scalable | Growth is added capacity, not a larger machine and a maintenance window. |
| Independently upgradable | A platform upgrade does not require your data to be migrated first. |
| Observable | Health, throughput and latency are first-class metrics, so your operations team can run it. |
| Resilient by redundancy | No single instance holds the only copy of a tenant’s state. |
| Deployable where you need it | Containers on your own infrastructure, Kubernetes, or a cloud deployment. |
Where it runs: three supported topologies
| Topology | Shape |
|---|---|
| Single-host containers | The whole stack in one container composition: database, API service, web application and an optional identity provider for testing. |
| Kubernetes | The same services deployed to an environment that already runs a cluster. |
| Cloud with a managed database | The application services beside a managed database instance, with provisioning and retention scripts. |
In every topology a standard relational database is the store, and a vanilla install is a supported target, not a degraded one. Migrations run at boot, and the serving role is an application role with isolation enforced on it rather than a superuser. Provisioning a database and serving traffic from it are separate privileges, which is the property a security reviewer looks for first.
Isolation at the data layer, not the application
| Layer | Control |
|---|---|
| Data | Row-level isolation enforced by the database itself, so an application defect cannot widen visibility |
| Access | Role and workspace evaluated on every request |
| Identity | Per-tenant single sign-on and provisioning |
| Definitions | Ontologies, domains and policies are tenant-scoped and cannot bleed across tenants |
| Reasoning | No shared queue or shared execution context between tenants |
| Audit | Actions recorded and queryable within the tenant boundary |
| Memory | Tenant-scoped; retention policy applies within it |
Why the data layer. If isolation is enforced in the application, one missed condition (in one query, one new endpoint, one refactor) is a cross-tenant leak. Pushing the control into the database means the application’s failure mode is closed rather than open. It is the single most important architectural security decision in the product.
No noisy neighbors
Because a shared queue is a shared fate.
No shared execution context between tenants
One tenant’s heavy reasoning does not occupy the queue another tenant’s live operation depends on.
Reasoning can run where the decision is made
Including locally in a browser, so analytical load does not compete with the live stream. See low latency.
Per-tenant scale
Capacity is provisioned against the entities a tenant models, so a large tenant does not set the cost or the latency floor for a small one.
Review the isolation model with your security team
We will walk your reviewers through the tenancy layers above and answer their questionnaire directly.