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. This cannot be modified after creation.
• Database Instances: choose between a standalone single instance (1) or a high-availability replicated setup (3).
• Storage Size: disk capacity between (>10 GB).
• Network Access: choose how the instance is exposed over the network:
  • 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.
• 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.
• Maintenance Start Time (UTC): the start time for the maintenance window in UTC (hourly from 00:00:00 to 23:00:00). Leave empty to let the platform choose a time between 21:00 and 05:00 UTC.
• Run VACUUM During Maintenance: when enabled, runs a full 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.

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.

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.

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 & Restore 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.
• Compute and connections: CPU allocation, memory limits, and maximum database connections 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