Create your first service

A service is what you buy: one managed PostgreSQL instance with a defined vCPU, RAM, storage and I/O allocation, in one location, on one major version. It contains logical databases, schemas and roles at no extra charge, and it is the unit everything else in the dashboard hangs off.

Create one #

1. Open Services and press Create a service.
2. Location. Where the service runs and where its primary backup repository lives.
3. Version. PostgreSQL 16, 17 or 18. New services default to 18.
4. Plan. Sets vCPU, RAM, storage and the I/O allocation.
5. Protection. Backup retention: 7, 30, 90 or 365 days.
6. Name and confirm. Name the service, check the summary, then press Create service.

Provisioning runs as a job. The service appears in your list while it is still being built.

What each choice commits you to #

Location #

The location is fixed for the life of the service. A service does not move between locations after creation, so choose for the latency your application needs and for any residency requirement you have.

Its second backup repository is in a different country from the first, which is what allows your data to survive the loss of a whole location. The country pairs are published on the locations page before you buy.

Version #

The major version is fixed when the service is created and the platform refuses a request for any other. To move to a newer major, create a new service and copy the data across. See versions and upgrades.

Plan #

The plan sets four numbers, and all four are enforced by the kernel rather than advertised. Pick for the working set you expect rather than the total data size: a database whose hot pages fit in memory behaves very differently from one whose pages do not.

You can move up a plan later. You cannot move down, because every smaller plan also has less storage and storage does not shrink. See scaling.

Protection #

Retention decides two things at once: how far back you can recover, and how long data you delete stays inside backup images. Longer retention costs more because it consumes real storage across both repositories. See retention.

What happens when you confirm #

1. The control plane reserves your CPU, memory, storage and I/O allocation atomically, before any host is touched. A reservation is a row with a timeout, not a derived number.
2. A host is selected that satisfies every hard constraint: the location, the major version, capacity in all four dimensions after the recovery reserve, and host health.
3. The service is provisioned with its own user, its own cgroup and its own filesystem subtree.
4. Your endpoints are published and the service accepts connections.

Provisioning is asynchronous, idempotent and resumable. A failure either completes on retry or rolls back fully. It does not leave capacity reserved and unaccounted for.

What you will see #

The service's page opens on Overview. The tabs this documentation covers are Connect, Backups, Configuration, Alerts and Activity.

You get two endpoints on a hostname that does not change, even if we move the service to another host:

Both are TLS-only, and both are on the Connect tab with copy-paste examples. The two ports are your service's own — services in a location share their hosts' addresses and are told apart by port — and they do not change for the life of the service.

Your service is created with one logical database, appdb. Backups start immediately and your first restore verification runs within 48 hours.

What you do not get #

You do not get PostgreSQL superuser, and you do not get host access. You get a managed elevated role that can create schemas and roles, tune an allowlisted set of parameters and install approved extensions. The reasoning is in the privilege model.

CREATEDB is withheld, which is what makes the published database count a limit rather than a claim. CREATEROLE is granted, which is why the role count is a guideline. See databases and roles.

Troubleshooting #

The create form refuses with a capacity message. The location cannot take the service at that size right now. It is an answer about capacity in that location and not a fault in your request, and the same request can succeed later. Try a different location, or a smaller plan.

Creation is refused because of billing. billing.standing_denied means the organisation's billing state does not currently allow the operation. Check the billing screen. See payment failures.

The service stays in a provisioning state. Provisioning is a job and the Activity tab records what it did. Nothing is charged for a service that never reached a running state.

Related #

• Connect
• Plan limits
• Scaling a service