Nothing is hard-deleted
Records are never removed to make a problem go away. A mistake is corrected by a recorded reversal or correction document, and the original stays visible, which is what makes the trail evidence rather than a story.
HomeSecurity
Security & integrity
Isolation the application cannot forget.
In a multi-tenant system, “we filter by customer” is a promise every query has to keep. Corva moves that promise one layer down, into the database, where it fails closed instead of failing quietly.
Tenant isolation
Row-level security, enforced by Postgres itself.
Every tenant-owned table carries a policy the database applies to every query. The application sets who it is acting for; the database decides what that entitles it to see.
The important property is the failure mode. If the tenant context is missing (a bug, a forgotten parameter, a new code path, a direct connection) the policy does not fall back to “show everything”. It matches nothing. A query without a valid tenant context returns an empty result, and a write without one is refused.
That is what fail-closed means, and it is why isolation here does not depend on every developer, forever, remembering a WHERE clause.
- Row-level security policies on tenant-owned tables
- Missing context yields nothing, never everything
- Cross-tenant reads and writes are refused, not filtered later
- Isolation is covered by automated tests on every change
Same query, three contexts
tenant = northwindSees only Northwind's rows
142 rows
tenant = acmeSees only Acme's rows
87 rows
tenant = <unset>Fails closed, no fallback
0 rows
Illustrative row counts. One table, one query text: the database, not the application, decides the result.
Integrity
A history that resists tampering, by design.
Authority is checked before the write
Permissions are evaluated inside the transaction, before anything changes. An override is itself a recorded event, naming who authorized it and when.
Least privilege at the database
The application's database role can move business data but cannot alter the schema; structural changes run separately under a role the running service does not have.
Concurrency
Correct when everything happens at once.
A warehouse at its busiest is exactly when a system's guarantees get tested. These are the four concurrency failures that quietly corrupt distribution systems, and how Corva settles them.
No oversellTwo claims on the last case are serialized by the database. One wins and the other is told immediately: the quantity cannot go negative and a customer is not promised stock that is gone.
Gapless numberingInvoice and document numbers are allocated so the sequence holds under concurrent load: no duplicates, and no missing numbers to explain to an auditor.
Idempotent operationsA double-clicked button, a retried API call or a replayed job produces one shipment, one invoice, one posting, not two.
Deadlock-aware orderingCommands take locks in a consistent order and hold them for the shortest possible time, so heavy days degrade in throughput rather than in correctness.
These are verified the only way they can be: with tests that actually run the race. Concurrency and isolation suites are part of the gate every change has to pass.
Coming soon
Ask us the hard questions.
Isolation model, posting rules, concurrency behavior — we would rather answer them now than have you discover the answers later.
hello@corvaerp.com