Your database. In your account. In your region. Actually.

What sits where.

The trust boundary is short enough to state in full. Pental's side holds what is needed to bill you and route your domain. Your side holds the business.

Guided setup, no DBA required.

Owning the database does not mean administering it. Supabase runs the infrastructure, backups and upgrades; the setup is a guided step during onboarding.

1. 01Create a free Supabase account, or use the one you already have. It is your account, on your email, under your control.
2. 02Create a project and pick its region. London, Frankfurt, Sydney, wherever your data-residency story needs it to be. This choice is yours and it is permanent evidence of where the data sits.
3. 03Paste two values into Pental. The platform installs its schema into your project: the tables, the 180 policies, the functions, the lot.
4. 04Sign in to your new portal. From here the portal is the only interface you ever need. The database sits underneath, yours to query whenever you feel like checking our claims.

Six mechanisms, none of them a policy document.

“We take your privacy seriously” is a sentence. These are constraints the database enforces on every request, including requests from us.

• Physical isolationOne firm, one database. There is no shared table holding several firms’ rows, so there is no tenant filter to get wrong and nothing else in the database to reach. The usual multi-tenant arrangement rests on every query remembering a where-clause; here the separation exists before any query runs.
• Row-level security180 policies across 47 tables, evaluated by Postgres on every query. Application code cannot wave a request through and neither can a bug in it. A request that fails a policy receives zero rows, not an error describing what it was denied.
• Freshness-gated MFAEvery data-access policy also requires that the session has recently proved possession of a second factor, checked at 98 sites in the schema. A token lifted off a laptop is not enough to read a finding, because possession of a token is not the question the database asks.
• Per-project signing keysYour project signs its own session tokens with its own keys. A token from any other environment does not fail an authorisation check against your data, it fails to validate at all.
• Secrets encrypted at restSMTP passwords, AI keys and integration tokens are encrypted on write, inside your database, with a key generated in that same database. The plaintext column is nulled. Nine secret columns get this treatment, and the encryption key never leaves your project.
• Dual-signed server callsThe narrow set of operations Pental’s servers can ask your database to perform is signed twice, by two parties holding their keys separately, bound to a single operation and tenant, with nonce-based replay protection. The most sensitive reads refuse server credentials entirely and require a signed-in user of your firm.

Why “we cannot read your data” is architecture, not marketing.

Follow what a read of your findings actually requires, and where each requirement leaves Pental.

1. 01The row lives in your project, not on a server of ours, so there is no internal database for a Pental employee to browse.
2. 02Reading it requires passing row-level security, which Postgres evaluates on every query. Those policies demand an authenticated user of your firm.
3. 03They also demand a recent second-factor check. Resetting or enrolling a factor requires an administrator signed in to your portal, and that administrator is one of your people, not one of ours.
4. 04Sessions are signed with your project's keys, so a credential from anywhere else fails validation outright.
5. 05The server-side operations that do exist are dual-signed, single-purpose and replay-protected, and the most sensitive reads refuse server credentials entirely. There is no general-purpose read path to misuse, which is what “no code path in” means.

Region, backups, and the day you leave.

• Residency you can point atThe region is chosen by you at creation, in your own hosting account. When a client's security questionnaire asks where their data is held, the answer is a fact about your infrastructure, not a paragraph about ours.
• Backups on your scheduleSupabase backs your project up as part of the platform, and because the database is yours you can additionally dump, snapshot or replicate it on any schedule your policy requires, with your own tools.
• Export any timeEverything is exportable from the portal, and everything is also just rows in your Postgres, reachable with psql. No export request, no ticket, no waiting.
• Cancelling is undramaticEnding the subscription ends your access to the software. Your project carries on exactly as it was, in your account, with every row intact, because it was never in our custody to hand back.

Every number on this page is a query away.

Connect to your own project with your own credentials and count for yourself. The figures we publish are properties of the schema the install creates.

The full layer-by-layer account, including authentication, enumeration resistance and secret handling, lives on the security page