This section contains upgrade guides for CYPEX administrators, DBAs, and operations engineers. Use these guides when moving an existing CYPEX deployment from one major version to the next, especially when the upgrade involves schema or permission-model changes.
From v2.0.0 onward, multi-tenant isolation is a database property: PostgreSQL Row-Level Security (RLS) scopes every query. Application-layer filters are not the security boundary.
The guides are written with factual upgrade behavior in mind: what the migrations actually do, what is additive, what is breaking, what is behavior-changing, and what the rollback constraints are.
- CYPEX operators planning a production upgrade.
- DBAs reviewing schema, RLS, and role changes.
- Tech leads deciding whether to upgrade and on what timeline.
The v2.0.0 upgrade moves CYPEX from a single-tenant model to multi-tenant Organizations. Isolation is enforced with PostgreSQL Row-Level Security (RLS) — not application-layer filters. This guide covers breaking changes, behavior changes, the admin pre-upgrade checklist, verification queries, and rollback constraints.
- Conceptual overview
- Upgrade test matrix
- Breaking changes
- Behavior changes
- Additive changes
- Pre-upgrade checklist
- RLS impact on existing data
- Roles and permissions
- Default password policy
- Rollback constraints
Step-by-step procedure for setting up multiple organizations after the v2.0.0 upgrade: prepare the database, enable RLS, assign clients to organizations, verify the migration, and roll back if needed.
- CYPEX internals — for the underlying architecture and how Organizations fit into the platform.
- User management — for the user / role model that Organizations build on top of.
- Release Management — for per-application version control, which still applies on top of multi-tenant Organizations.