Hosted or self-hosted for a client project: how to decide

A client asks for an internal tool, or a portal that will hold customer records. The stack gets decided in one meeting. Then someone asks whether the database should be hosted or self-hosted, and the room splits along habit lines. The useful answer is not a preference. It is the output of six questions about duties, and it is often different for the app, the database and the files.

Start from duties, not from preference

Hosted means a provider runs the machines. It does not mean the provider runs the project. On AWS the split is stated as security of the cloud versus security in the cloud: AWS protects the infrastructure, while the customer patches the guest operating system and applications, configures the firewall, manages the data, decides who has access and configures the database. That is the clearest public description of the line. See the AWS shared responsibility model.

Data protection law draws a second line that does not move with the hosting choice. When a provider stores personal data on a client's behalf it is a processor, the client is the controller, and the controller stays answerable. The European Data Protection Board uses exactly this example in its guidelines on controller and processor: an employer whose hosting provider processes employee data must give instructions and sign a contract under Article 28, and the controller "remains responsible for the implementation of appropriate technical and organisational measures". Hosted or self-hosted changes who can carry a duty. It does not change who answers for it.

The contract side, meaning the processor agreement, the sub-processors and the location question, is covered in where your client's data lives. The operational difference between a personal database and a production one is in self-hosting a database: personal versus production. This article is the decision between them. It is an explanation, not legal advice.

The six questions

1. Where may the data be, and what does the client's own contract say?

Write down what the system will store, then check what the client has already promised someone else. A client selling to public bodies, banks or healthcare may have a clause about where customer data may be processed, and that clause was signed before your project existed.

Region selection is the first concrete control. Each Supabase project is deployed to one primary region, which determines where the primary data lives; the documentation also warns that "region selection is a data-location control, not proof of regulatory compliance", because a general Europe region can place a project in London or Zurich, which are not EU member states (Supabase regions). Read the fine print for the specific region, not the continent.

Backups are copies too. A nightly dump replicated to a second country is still personal data in that second country, and a support engineer with console access is still a person who can read it. If the client's answer is "it must stay on our hardware", the hosted shortlist is empty and the question is settled.

2. Who must be able to restore it, and within how long?

Ask for two numbers in the client's words: how much data may be lost if the system dies, and how long it may stay down. Those answers decide the backup design more than the hosting model does.

Then check whether the provider's backups give you those numbers. On Supabase, automatic daily backups exist on Pro, Team and Enterprise plans with 7, 14 and 30 days of retention; point-in-time recovery is a paid add-on that archives write-ahead logs, claims a recovery point objective of two minutes in the worst case, and replaces daily backups when enabled; a restore takes the project offline (Supabase backups). The same page notes that database backups exclude Storage API objects, so file restore is a separate procedure.

If the client says "we will restore it ourselves", hosted is acceptable only when they can obtain a copy they can load. The docs say physical backups are not available for direct download, so that means a logical dump through the CLI or pg_dump. Test that path before the contract is signed, not during an incident.

3. Who patches it, and who decides when?

A managed service removes the system administrator, not the decision. Supabase runs Postgres upgrades when you start them from the dashboard; the project goes offline and a failed upgrade brings the original database back (Supabase upgrades). Someone still has to notice that a new minor version exists, read the notes, pick a window and press the button.

Self-hosted, that someone is you, and the window is yours to find. The failure mode is not a dramatic crash. It is a version that nobody upgraded for two years, an extension that no longer builds, and an upgrade that now needs a weekend instead of twenty minutes. Name the person who reads release notes. If the name is missing from the handover, the patch will not happen.

4. What budget and skills exist after handover?

Hosted turns operations into a monthly line that grows with compute, storage, backup retention and add-ons such as point-in-time recovery. Self-hosted turns it into hours, plus a machine, plus the person who answers the phone. Neither is cheaper in the abstract.

The question that matters is what exists after the project ends. A client with an operations team, a container platform and an on-call rota can absorb a self-hosted database, and often prefers it because the data never leaves their network. A five-person company with no technical staff cannot. If we self-host for them, we become the only people who can fix it, which is a single point of failure dressed up as control.

5. What happens when the vendor changes its terms?

Providers change terms, prices and plans. Supabase's terms say it "may change this Agreement (except for any Orders) from time to time at its discretion", with reasonable notice, and that continued use after the effective date counts as acceptance (Supabase terms). That is normal contract language, and it is also a risk you are accepting on the client's behalf.

Ask the client a blunt question: if this provider doubled the price next year, what would we do? If the honest answer is "pay", that is a decision, and it should be written down. The mitigations are boring and effective: keep the core record in ordinary Postgres tables, avoid building the product around a provider-only feature, and know in advance what a migration week would cost.

6. How does the client leave if the relationship ends?

There are two exits, from the vendor and from us, and both need a tested path. For a Postgres database the portable format is a logical dump: pg_dump writes a script or an archive that can be loaded on other machines and other architectures (PostgreSQL pg_dump). The same documentation says plainly that it is "generally not the right choice for taking regular backups of production databases", so use it for exits and use physical backups or write-ahead logs for recovery.

A database dump is not the project. Users and password hashes, storage objects, scheduled jobs, DNS records and mail credentials all live somewhere else. List every one of them, decide who holds the original, and rehearse the export once while everyone is calm.

What the answers point to

Hosted fits when the client has no operations capacity, the requirements are ordinary, the data may sit in a named region, the client accepts the vendor as a processor, and the monthly cost is budgeted rather than hoped for. That is a real case, not a compromise. It also fits when the alternative is a server in an office that nobody backs up.

Self-hosted fits when a contract or a regulator requires the data to stay on the client's infrastructure, when the client already runs servers and has people on call, when the workload needs an extension, a version or a configuration that the managed plan does not offer, or when steady heavy load makes a fixed machine cheaper than a usage bill.

Most projects we see are mixed. The application runs on a managed platform, the database sits on the client's own virtual machine, files go into the client's object storage, mail goes through a provider. Answer the six questions per component instead of once for the whole stack.

The answer that should worry you is not "hosted" or "self-hosted". It is "hosted because it is easier for us" or "self-hosted because it is more secure", with no named operator and no tested restore behind either.

Handover obligations, either way

• Credentials. Domain and registrar, DNS, the provider account with billing in the client's name, the database superuser, encryption keys, mail credentials, API tokens. Hand them over through a password manager, record which human holds each one, and revoke ours where the contract says we are done.
• Documentation. An architecture diagram, the environment variables, and a runbook with three procedures: deploy, restore, and escalate. Written for the person who joins after us.
• Backup proof. The date of the last restore test, who ran it, how long it took and what was missing. A green backup job proves that a job ran. It does not prove that the data can come back.
• A named operator. One person with a name, a phone number and a written scope, either inside the client or under a support contract with hours attached. "The team" is nobody at three in the morning.

The same four items apply to both models; only the person performing them changes.

What getting it wrong costs, in mechanisms

A restore gap costs the writes between the last usable backup and the incident. With daily backups only, that is up to a day of work, and the loss is not the data, it is the trust of the people who entered it.

An unpatched system costs the window between disclosure and exploitation, which is short. If a breach touches personal data, the controller has 72 hours from becoming aware to notify the supervisory authority, and a processor has to inform the controller without undue delay; the EDPB sets out both duties in its breach notification guidelines. A client who learns about the breach from a customer has already lost that window.

Lock-in costs a migration, and a migration is priced in schema, auth, storage, DNS and retesting, not in a download. The region mistake costs the same migration, at the worst possible moment. An unnamed operator costs the hours spent finding out who has the credentials, which is usually longer than the fix.

Romanian clients also work under Law 190/2018, which implements specific GDPR provisions nationally, and they report breaches to ANSPDCP. That does not change with hosting; it changes what the client must be able to show.

How we run this at Danube Labs

We write the six answers into the first project document, before any infrastructure is chosen, and the same document becomes the handover checklist. When the client has no operator, we say so in the document and price the support instead of leaving it implicit.

If you want a second opinion on the split, see our web development work or book a free intro call.