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 Postgres project in your own account, or use one you already have, and pick its region. London, Frankfurt, Sydney, wherever your data-residency story needs it to be.
2. 02Run the setup SQL yourself. We give you the script and a link straight into your own SQL editor. It creates the tables, the 119 policies, the functions and the buckets. Nobody at Pental runs it for you, and you can read every line before you do.
3. 03Register one auth hook so your project stamps its own session tokens with the claims its policies read. Two dropdowns in your project settings.
4. 04Hand Pental the project ID and a publishable key. Publishable, not secret: it is safe to hold precisely because every table is behind the policies you just installed.

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 security119 policies, with row-level security enabled on 56 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, required by 86 of them. 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.

What a Breach of Pental Would Reach

This is the question worth asking any platform in this space, so here is ours answered precisely.

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