Upgrade test matrix

This page lists the upgrade scenarios that were exercised against the v2.0.0 migration scripts, the result of each, and the explicit answer to the most common question: does RLS change row visibility for existing single-tenant data?

Short answer

Info
No. RLS does not change row visibility for existing single-tenant data. All existing rows remain visible to all existing users after the upgrade.

The mechanism is described in detail on RLS impact on existing data. The short version: the upgrade creates a Default Organization, maps every existing role to it, and the RLS policies explicitly allow organization_id IS NULL rows to be visible. Existing single-tenant data therefore continues to be readable.

Scenarios

The migration was validated against three representative scenarios. Each scenario starts from a v1.9.3 instance and runs the v2.0.0 migration scripts in order (Organizations schema, RLS helpers, RLS policies, and the default password policy migration).

Scenario A — single-tenant, no LDAP, single schema

Aspect	Result
Migration applies cleanly	✅
Default Organization created	✅
All existing roles mapped to Default Organization	✅
`organization_id` column added, NULL for existing rows	✅
Existing rows visible to existing `cypex_user` after upgrade	✅
Existing rows visible to existing `cypex_admin` after upgrade	✅
Password policy applied (no prior policy)	✅
Backend boots and serves traffic	✅

Scenario B — LDAP-enabled

Aspect	Result
Migration applies cleanly	✅
LDAP-mapped users retain access	✅
New `organization_id` column does not interfere with LDAP sync	✅
Existing rows visible to LDAP users	✅
Default password policy not enforced on LDAP users	✅

Scenario C — multi-schema (multiple modules)

Aspect	Result
Migration applies cleanly	✅
All modules mapped to Default Organization	✅
Module isolation across schemas preserved	✅
Existing rows visible across all modules	✅
New `cypex_default` virtual module created	✅

Results summary

Scenario	Result	Notes
A — single-tenant	✅ Pass	Baseline scenario.
B — LDAP-enabled	✅ Pass	LDAP users unaffected by RLS.
C — multi-schema	✅ Pass	Default Organization covers all modules.

What was not covered

The test matrix does not cover:

Custom RLS policies added by individual deployments — these may conflict with the new policies and must be reviewed manually. See the pre-upgrade checklist.
Custom password policies already present in cypex.t_config — the new default uses ON CONFLICT DO NOTHING and does not override them. See Default password policy.
Custom integrations that bypass CYPEX and write directly to the database — these must set request.jwt.claims and supply organization_id themselves.
Very large databases (> 1 TB) — timings in Prepare the existing database are extrapolations.

If your deployment falls outside the tested scenarios, treat the upgrade as a custom migration: replicate to staging, run end-to-end, validate before production.

Explicit statement on row visibility

Info
RLS does not change row visibility for existing single-tenant data.

This was the primary acceptance criterion for the migration. See RLS impact on existing data for the mechanism and the verification queries you can run to confirm it on your own instance.