Creating Your Database: Three Ways to Run It
Your portal runs on a database you own, in one of three places: PostgreSQL in your own cloud, self-hosted Supabase, or Supabase Cloud. What each is, its pros and cons, and the full guide for each.
Every Pental portal runs on a database the firm owns. Pental holds your account, your subscription and your domain routing, and, to reach your database, its address, its publishable key and a provisioning credential your database records every use of. Your clients, findings, evidence and reports live in your database, under security policies your database enforces, where Pental cannot read them. Where that database runs is your choice, and there are three places it can.
The same portal in all three
- The same portal, the same features and the same setup SQL, with every row-level security policy and second-factor check.
- The only database key Pental keeps is the publishable one, which reads nothing the policies do not allow. It never holds the secret or service key, the database’s password or a gateway’s setup token.
- A guided setup on your pental.io dashboard, with each step checked from your browser as you go.
- Room to change your mind: you can move to either of the others later, with everything in it.
PostgreSQL in your cloud
Your cloud’s own PostgreSQL, or a server of yours, with the small Pental gateway beside it. Nothing from Supabase. It suits firms standardised on Azure, AWS or Google Cloud that want the data in their own tenancy, on their provider’s managed database.
Pros
- Your cloud’s own managed database (Azure Database for PostgreSQL, Amazon RDS or Cloud SQL), under the contract and controls you already have, with daily backups on from the first command.
- One command creates the database, deploys the gateway and prints what the setup asks for.
- On Azure the database has no public address, and on AWS it sits in private subnets.
- Updates apply themselves every day, only when Pental has signed them, and your dashboard applies one at once.
Cons
- Your cloud bills you for the database and for a gateway that is always running.
- The setup token is yours to keep safe: it applies an update on demand, and a move needs it.
- The gateway is one more service to keep current: a new version is the same command, pasted again.
Self-hosted Supabase
Supabase’s open-source stack on a server you run, from a kit we give you. It suits firms that must keep everything on infrastructure they run, in their own cloud account or their own office.
Pros
- Everything runs on your own server, in your Azure, Google Cloud or AWS account or on your own hardware.
- It sets itself up: on first start the stack builds the portal’s database, with no SQL to copy anywhere.
- Updates apply themselves every day, only when Pental has signed them, and one command takes an update straight away.
- The same open-source Supabase software, Studio dashboard included.
Cons
- You run the server: the operating system, Docker, disk space, monitoring and backups are yours to look after.
- It needs a Linux server with Docker, a DNS name pointed at it and ports 80 and 443 open to the internet.
- It is one server, so the portal is up when that server is.
Supabase Cloud
A managed Postgres project in your own Supabase account, in the region you pick. It suits trying Pental out, or a firm that would rather not run a server: the quickest start, and it moves to your own cloud later with everything in it.
Pros
- Nothing to install, patch or keep running: Supabase runs the database, and its dashboard is where you look after it.
- The quickest of the three to set up, and every step is checked from your browser as you go.
- On a paid Supabase plan it is backed up every day, in the region you chose when you created it.
Cons
- Updates are one paste rather than automatic: when a release changes the schema, an administrator copies the SQL into the project’s SQL editor and runs it.
- The free tier is for trying it out: Supabase keeps no restorable daily backups on it, so a firm working on it for real wants a paid plan.
- The data sits with Supabase as your hosting provider, in your own account. A client who needs it in your own cloud or on your own servers may prefer one of the other two.
How to choose
| If | Choose |
|---|---|
| Your firm runs on Azure, AWS or Google Cloud and wants the provider’s own database | PostgreSQL in your cloud |
| Everything has to be on servers you run, in your cloud account or your office | Self-hosted Supabase |
| You would rather run nothing yourself | Supabase Cloud |
| You want to try Pental first, or are not sure yet | Supabase Cloud, the quickest start: you can move to your own cloud later with everything in it |
The full guides
Changing your mind later
The move copies everything (people, clients, findings, files and sealed secrets) from one home to another, in your own browser or on your own computer, with your databases’ own credentials. Nothing passes through Pental. Saving pauses on the current database while it runs, reading and signing in carry on, and the portal switches over only when you say so.
Choose Yours in the Trial
The setup offers all three, checks every step from your browser as you go, and you can move to another later with everything in it.
Only need the reporting? Our reporting tool is free and open source, on your own server.
Also Worth Reading
Setting Up Your Database on PostgreSQL in Your Cloud
Your cloud’s own PostgreSQL on Azure, AWS or Google Cloud, or a server of yours, with the small Pental gateway beside it. One command builds it all, and it applies Pental’s signed updates itself.
DatabaseSetting Up Your Database on Self-Hosted Supabase
Supabase’s open-source stack on a server you run, from a kit we give you. One paste on the server puts in Docker if it is missing, makes the stack’s secrets and starts it, and it sets up and updates its own database.
DatabaseSetting Up Your Database on Supabase Cloud
A Supabase project in your own account, set up in five steps the setup checks as you go: the project, its publishable key, the setup SQL, the access token hook, then connect.