PostgreSQL¶

Servala provides fully managed PostgreSQL instances: a powerful, open-source relational database known for its reliability, feature set, and standards compliance.

Availability¶

PostgreSQL is available on selected cloud providers and zones. See the availability matrix for the current list.

Supported versions¶

PostgreSQL major versions selectable in the portal:

The major version is fixed for the lifetime of the instance and cannot be changed later. Select the newest version that your application supports.

Minor and patch updates are applied automatically during maintenance windows. Version upgrade mechanics are described in Maintenance & Upgrades.

Compute plan and sizing¶

Compute resources (CPU and memory) are selected through the compute plan when you provision the instance. Storage is configured independently:

• Storage range: from 10 GB to 500 GB.
• Storage expansion: storage can be increased later as your data grows, but disk space can never be reduced.

The available compute plans and their resource allocations are shown directly in the portal. See Compute Plans & SLAs for details on compute sizing and service levels.

Configuration options¶

When provisioning a PostgreSQL instance in the portal, you configure options across these sections:

General¶

• Friendly name: a display name for this database, shown throughout the portal.
• PostgreSQL Version: the major version: 16, 17, or 18 (latest). The major version is fixed for the lifetime of the instance and cannot be changed later. See Supported versions.
• Database Instances: 1 instance, or 3 instances for high availability. Three instances run one primary and two read-only replicas with automatic failover, so maintenance and node failures do not take the database offline. Defaults to 1.
• Storage Size: disk space for the database, from 10 GB to 500 GB. Storage can be increased later, but never reduced.
• Network Access: choose how the instance is reached from outside the cluster:
  • TCP Gateway (shared public endpoint): routes traffic through a shared gateway on an assigned port.
  • Load Balancer (dedicated public IPv4 address): allocates an exclusive public IPv4 address and standard port for the instance.

Backup¶

• Backup Schedule: a cron expression in UTC defining when the daily base backup runs (for example 0 22 * * * for 22:00 UTC). Each field accepts *, a single number, or step values such as */n. Lists and ranges are not supported. Leave this field empty to let the platform automatically assign a time between 22:00 and 04:00 UTC.
• Retention (days): the number of days to keep backups (minimum: 1 day, default: 6 days). Point-in-time recovery covers this full retention period, because the WAL archive is kept for the same time.
• Point-in-Time Interval: how often the write-ahead log (WAL) is archived, setting the worst-case recovery point objective (RPO). Completed 16 MB log segments are archived immediately. This setting forces an archive after the specified interval even if a segment is not full. Enter a duration in seconds (such as 300) or with a time unit (such as 5min). Leave empty for the default of 300 seconds (5 minutes).

Maintenance¶

• Maintenance Day: the day of the week (Monday to Sunday) when weekly maintenance updates and restarts are performed. Leave empty to let the platform choose. A single-instance database is briefly unavailable during maintenance. A three-instance database fails over instead.
• Maintenance Start Time (UTC): the start time for the maintenance window in UTC (hourly from 00:00 to 23:00). Leave empty to let the platform choose a time between 21:00 and 05:00 UTC.
• Run VACUUM During Maintenance: when enabled, runs VACUUM across all databases during the maintenance window. This helps workloads with high update or delete volume where background autovacuum may not reclaim space quickly enough. pg_repack runs during maintenance regardless of this setting.

Monitoring¶

• Alert Email Address: the email address that receives alert notifications for this database, for example when it runs out of disk space or a replica is down. Only one address is supported. Use a group or distribution list if several people should get the alerts. Leave empty to disable email alerts. See Monitoring.

High availability and replication¶

When provisioning your instance, you select the number of database instances:

• Single instance (1 instance): a single PostgreSQL server without replication. Data is stored on persistent volumes and survives restarts, but there is no standby server. A host failure or maintenance restart causes brief unavailability while the instance restarts. Recommended for development, staging, or non-critical workloads.
• High availability (3 instances): a high-availability cluster with one primary instance and two read-only replicas using streaming replication. If the primary instance fails, a replica is automatically promoted to primary, and client connections automatically route to the new primary. Running two standby replicas ensures that high availability is preserved even after a failover while a replacement replica is provisioned.

For details on changing replica topology, see Scaling.

Connections and connection pooling¶

A PostgreSQL instance accepts a limited number of client connections. The limit is the server setting max_connections. Two facts matter for planning:

• The limit applies to the whole instance. It is not a per-database setting.
• Every client connection uses one backend process on the instance that serves it, and that process holds its own private memory. Only a small part of the memory is shared.

The default of PostgreSQL is 100 connections. Check it with SHOW max_connections;.

A few slots are reserved for superusers (superuser_reserved_connections, three by default), so your applications have fewer slots than max_connections. When all slots are in use, new clients are refused with FATAL: sorry, too many clients already.

Why the limit is not raised on request¶

A higher max_connections is not free and does not make the database faster:

• Memory: every slot adds a backend process with private memory, and PostgreSQL also scales some shared resources with max_connections. The memory that is left for the caches and for the buffers of a query (work_mem, one per sort or hash operation) gets smaller. More connections lower the memory headroom of the instance and raise the risk of a MemoryCritical alert.
• CPU: more processes mean more context switching between them.
• Contention: more sessions compete for the same locks and the same CPU. Waiting sessions add latency instead of throughput, see PostgreSQLBackendsWaiting.

PostgreSQL serves a few dozen busy sessions very well. A few hundred mostly idle sessions only consume memory. When your workload needs more concurrency, the correct fix is a pool that keeps the number of open sessions small.

Reduce the number of connections¶

1. Use a connection pool in your applications, with a fixed maximum size. Add up the pool sizes of every application and of every copy of an application. The sum must stay below the number of slots that your applications can use.
2. Prefer a pooler with transaction pooling, for example PgBouncer. A server connection is then used for one transaction rather than for one client session, so many more clients fit behind the same small number of backend processes.

Per-database and per-role limits¶

PostgreSQL can cap the connections of one database or of one role. This protects one workload from another, for example a reporting tool that must not take all slots. You set these limits yourself, because you have administrative access:

ALTER DATABASE appdb CONNECTION LIMIT 40;   -- -1 means no limit
ALTER ROLE app CONNECTION LIMIT 20;         -- -1 means no limit

SELECT datname, datconnlimit FROM pg_database;
SELECT rolname, rolconnlimit FROM pg_authid;

Keep three things in mind:

• A cap is an extra limit below max_connections. It never raises the total. The role postgres from the connection secret is a superuser, so you can set these limits without help from Servala.
• The caps are counted separately. Their sum can be larger than max_connections, so a cap does not guarantee a free slot.
• A role limit is never enforced for superusers.

Backup & point-in-time recovery¶

Servala provides automated daily base backups alongside continuous write-ahead log (WAL) archiving:

• Automated base backups: taken daily according to your configured backup schedule (or an automatically assigned off-peak window).
• Continuous WAL archiving: write-ahead logs are archived to object storage whenever a 16 MB WAL segment fills up or when the configured Point-in-Time Interval elapses (default: every 5 minutes).
• Point-in-time recovery (PITR): you can restore your database to any specific second within the retention window (default: 6 days, minimum: 1 day).
• Storage location: backups and WAL archives are stored safely in an S3-compatible object store, independent of the database cluster storage.
• Direct access: organization administrators can reveal the credentials of the backup bucket and work with the archive using barman-cloud-backup-list and barman-cloud-restore. See Direct backup access below.

Self-service restore¶

Organization administrators and owners can restore a PostgreSQL instance from the portal, either to the latest available state or to a specific point in time. The restore always goes into a new instance, started from the source instance's base backups and WAL archive. See Self-service restore for the procedure.

Two PostgreSQL specifics are worth knowing:

• The point in time is entered in UTC and can be any second inside the retention window, not only a moment at which a base backup ran.
• The restore reads the archive belonging to the major version of the new instance. Leave the major version of the restore as it is, otherwise the restore finds no backups. For the same reason, a restore to a point before a major version upgrade is the way back out of one.

Direct backup access¶

Organization administrators and owners can reveal the credentials of the backup bucket on the instance detail page and work with the archive using their own tooling. See Backups for where to find the panel, who can reveal credentials, and the warnings that apply.

PostgreSQL backups are physical base backups plus a continuous write-ahead log (WAL) archive, written by Barman Cloud. A single base backup file is not usable on its own: a restore needs the backup, its metadata, and the WAL segments that span it. Use the barman-cloud-* tools (from the barman package) rather than downloading individual objects. The panel reveals the Access Key ID and the Secret Access Key.

export AWS_ACCESS_KEY_ID='<access key>'
export AWS_SECRET_ACCESS_KEY='<secret key>'

aws s3 ls --endpoint-url <endpoint> s3://<bucket>/       # list server-name prefixes
barman-cloud-backup-list --endpoint-url <endpoint> s3://<bucket> <server-name>
barman-cloud-restore --endpoint-url <endpoint> s3://<bucket> <backup-id> /path/to/restore

The Server name shown in the panel is the prefix of the current major version's archive (for example postgresql-17). After a major version upgrade, the archive of the previous version stays in the bucket under its old prefix; the aws s3 ls command lists all of them.

barman-cloud-restore writes a data directory to local disk that you can start with a matching PostgreSQL version. For point-in-time recovery, use barman-cloud-wal-restore as the restore_command of that server. If you only need a logical dump, restore locally first and run pg_dump against it.

Plain aws s3 sync or rclone also work for copying the raw objects, for example to keep an off-site copy.

Maintenance & optimization¶

Servala manages routine maintenance to ensure database reliability, performance, and security:

• Maintenance windows: updates and restarts occur within your chosen maintenance day and start time (or during assigned off-peak hours between 21:00 and 05:00 UTC).
• High availability behavior: for 3-instance clusters, maintenance rolling updates fail over between nodes with minimal disruption. For single-instance deployments, maintenance restarts cause a brief service interruption.
• Automatic table optimization (pg_repack): pg_repack runs during maintenance to remove bloat from tables and indexes without holding heavy locks, preserving read and write availability.
• Optional maintenance VACUUM: enabling Run VACUUM During Maintenance executes a VACUUM over all databases in the maintenance window, which is recommended for write-heavy or delete-heavy workloads.

For general maintenance information, see Maintenance & Upgrades.

Extensions¶

The following extensions are available out of the box. Enable an extension in your database with CREATE EXTENSION <name>;.

Managing users and databases¶

You receive administrative access to your PostgreSQL instance. Creating and managing additional databases, roles, and users inside the instance is your responsibility, using standard PostgreSQL tooling with your credentials. Servala manages the instance itself, not the databases and users you create within it.

Limits & quotas¶

The following limits and constraints apply to PostgreSQL instances:

• Storage size: minimum 10 GB, maximum 500 GB. Storage can be scaled up later, but cannot be reduced.
• Instance count: 1 instance (standalone) or 3 instances (high availability).
• Backup retention: minimum 1 day.
• Major version changes: the major version is locked at creation time and cannot be changed in place.
• Connections: max_connections depends on the selected compute plan. A few slots are reserved for superusers. See Connections and connection pooling for why the limit is not raised on request, and for the way to need fewer connections.
• Compute: CPU allocation and memory limits depend on the selected compute plan.

Connecting to your instance¶

PostgreSQL is accessed over TCP, so you choose a network access mode (shared TCP Gateway or dedicated Load Balancer) when you provision the instance. This determines the hostname and port you connect to.

After provisioning, retrieve your connection credentials from the instance detail page. Always connect through the gateway hostname provided in the connection secret: the server certificate is issued for that hostname, so certificate verification only succeeds when you use it.

TLS¶

Connections are encrypted with TLS. The connection credentials include three TLS items:

• CA Certificate (ca.crt): the certificate authority that signed the server certificate. The client uses it to verify the server.
• TLS Certificate (tls.crt) and TLS Key (tls.key): a client certificate and its private key, used for client certificate authentication.

Servala uses self-signed certificates without a separate intermediate CA chain, so you cannot verify the connection against a system or public CA bundle. To verify the server, the client must use the ca.crt from the connection secret as the root certificate.

For a fully verified connection, save ca.crt locally and connect with sslmode=verify-full and sslrootcert:

psql "host=<gateway-hostname> port=<port> dbname=<database> user=<username> password=<password> sslmode=verify-full sslrootcert=ca.crt"

Or use a connection string:

postgresql://<username>:<password>@<gateway-hostname>:<port>/<database>?sslmode=verify-full&sslrootcert=ca.crt

sslmode=verify-full checks both that the server certificate is signed by the CA in ca.crt and that the hostname matches the one you connect to, which is why you must use the gateway hostname from the connection secret.

Capability matrix¶

How the managed-service features apply to PostgreSQL:

Behind the scenes¶

Servala runs PostgreSQL with CloudNativePG, a Kubernetes operator that manages the instance, its replicas, and the streaming replication between them.

Further reading¶

• PostgreSQL on servala.com
• PostgreSQL upstream documentation
• CloudNativePG documentation