Tenant-safe ITSM on PostgreSQL. Every customer gets a separate CMDB and ticketing environment without you paying for a second VM plus Windows and SQL licences.
An honest interim status: Tenant separation is currently implemented logically (shared database, tenant-filtered access). Full isolation with a dedicated database per tenant is under active development – in the module maturity the module currently stands at around 53 %. For productive MSP scenarios the DB isolation is a prerequisite and part of the pilot scope.
# One service, many tenants PostgreSQL 18 ├─ ordivis_alpha CMDB · tickets · IPAM ├─ ordivis_beta CMDB · tickets · IPAM ├─ ordivis_gamma CMDB · tickets · IPAM └─ registry Tenants · memberships Isolation: a dedicated database per tenant Hardware: 1 VM instead of N VMs
Every customer gets their own database on the same PostgreSQL server, plus a central registry for tenants and memberships. Physically separated data – and losing a customer is a database drop, not a deletion project.
Instead of providing a separate VM plus Windows and SQL licences for every customer, all tenants share one server. The second customer costs you no second infrastructure.
No node counter, no tiers. However large a single tenant's network grows – your costs stay predictable.
A registry database manages the assignment. New customers are created by provisioning, not by a server rollout.
The modular monolith updates the entire instance in a transaction-safe update run – no patch marathon across distributed systems.
Run Ordivis Platform at your site or on the customer's premises – nobody forces you into a third-party cloud. You keep control of operations, SLAs and data.
Talk to us about tenant tiers and reseller terms.