Environments that are actually separate

Most low-code platforms give you environments. Rather fewer make them mean anything at the database level.

In Parsware, creating an environment provisions its own PostgreSQL schema. The tables your maker declares are created in that schema and nowhere else. Nothing carries an EnvironmentId column that every query has to remember to filter on.

Why that difference matters

A filter column is a convention, and conventions are kept by code. Every query, every report, every background job has to remember it. Miss it once — in a join, in a report, in a hand-written query somebody added at four in the afternoon — and the failure is silent: rows come back, they look plausible, and they belong to a different environment.

With a schema per environment there is nothing to remember. A query issued against the wrong environment does not return the wrong rows; it fails, because the table it is looking for is not there. That is the difference between isolation and a rule everybody has to keep.

What it costs, said plainly

Physical isolation is not free:

• Cross-environment questions get harder. "List every environment for this tenant" cannot be one query against one table, so the small registry data — which environments exist, who owns them, what solutions are installed — stays in shared, row-filtered tables. Only the operational data is split.
• Schema changes are per environment. Importing a solution applies its DDL to exactly one schema. Promotion is an explicit import, never an automatic sync — which is the behaviour you want, and it is more work than a single shared table would be.

What you get on day one

A new environment is not empty. It arrives with the standard tables already in it — Account and Contact, with the field sets you would expect — so there is something to build against before anybody has declared anything.

And deleting one drops its schema. Not a flag, not a nightly sweep that might miss something: the data goes when the environment does.