Tenant separation in Reynt is not a condition someone has to remember to write into every query — it is a rule in the database. Add per-tenant keys, operation in EU data centres, and a data processing agreement you can put in front of your own customers.
No credit card required — after 14 days the trial ends by itself.
Per tenant
Its own derived keys for data, search, and signatures
Every table
Tenant data sits behind forced row level security
90 days
Backup retention, run redundantly in EU data centres
Bolt multi-tenancy on afterwards and it hangs off every single query. Here it hangs off the database.
Every tenant-scoped table carries a forced row-level rule. Every request runs on a connection whose tenant was set first — without it the database hands nothing back. A forgotten filter in the code cannot expose another tenant’s data.
From one master key, each tenant gets its own derived set: one for personal data, one for searching it, one for signing. They exist before the first record is ever written.
Every tenant has a key pair. Checkout, guest registration, and the contact form only ever hold the public key: guest data is encrypted the moment it arrives. The private key is opened by the back office alone — whoever takes over the booking site cannot read what it wrote.
Encrypted fields stay findable: a blind index takes the search to the right record without the plaintext having to be read for it.
Sign-in through Zitadel, with roles and permissions per member. Machines get their own API keys within the same limits. Checks always happen on the server, never only in the interface.
Run redundantly in EU data centres, backups retained for 90 days, an Art. 28 GDPR data processing agreement, and a DSA notice-and-action procedure. You can export your data at any time.
The difference only shows once something goes wrong.
With Reynt
Bolted on afterwards
Where separation lives
With Reynt
Bolted on afterwards
When a query forgets the filter
With Reynt
Bolted on afterwards
Keys
With Reynt
Bolted on afterwards
What the public booking site can do
With Reynt
Bolted on afterwards
Searching encrypted fields
With Reynt
Bolted on afterwards
Background work
With Reynt
Bolted on afterwards
Evidence during procurement
With Reynt
Bolted on afterwards
Four steps nobody triggers by hand.
It gets its own keys before anything can be stored at all.
The database connection is set to it before the first row is read.
Role and permission decide what the request may do — regardless of what the interface offers.
Processing, retention, and exportability are written down, not promised.
A forgotten filter in the code cannot surface another tenant’s data
Every tenant holds its own keys — including against every other tenant
The public booking site encrypts guest data; it cannot read it
Operations, backups, and contracts stay in the EU
Procurement gets something to read instead of assurances