PostgreSQL¶

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

Full service description

For features, plans, and pricing, see PostgreSQL on servala.com.

Availability¶

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

Supported versions¶

Version	Status	End of life
to be filled in

Version upgrade mechanics are described in Maintenance & Upgrades.

Compute plan and sizing¶

Compute resources (CPU, memory, and storage) are selected through the compute plan when you provision the instance. The available plans and their sizes are shown directly in the portal, so they are not duplicated here. See Compute Plans & SLAs for how plans and service levels work.

Configuration options¶

Service-specific parameters available when provisioning, in addition to the compute plan:

Instances: run a single instance or a replicated three-instance cluster (see High availability and replication)
PostgreSQL version: select the major version (see Supported versions)
Extensions: see Extensions

High availability and replication¶

When you provision an instance, you choose how many instances the cluster runs:

Single instance (no replication): one PostgreSQL server. Your data survives a restart, but there is no standby to take over. A node failure means a short downtime while the instance restarts. Suitable for development, testing, and workloads that tolerate brief interruptions.
Three instances (replicated): one primary and two read-only replicas kept in sync through streaming replication. If the primary fails, a replica is automatically promoted and applications reconnect through the same endpoint. Running two replicas keeps a standby available even after a failover.

Changing the number of instances is described in Scaling.

Extensions¶

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

Show all available extensions

Extension	Description
`adminpack`	Administrative functions for PostgreSQL
`amcheck`	Functions for verifying relation integrity
`autoinc`	Functions for autoincrementing fields
`bloom`	Bloom access method: signature file based index
`btree_gin`	Support for indexing common datatypes in GIN
`btree_gist`	Support for indexing common datatypes in GiST
`citext`	Data type for case-insensitive character strings
`cube`	Data type for multidimensional cubes
`dblink`	Connect to other PostgreSQL databases from within a database
`dict_int`	Text search dictionary template for integers
`dict_xsyn`	Text search dictionary template for extended synonym processing
`earthdistance`	Calculate great-circle distances on the surface of the Earth
`file_fdw`	Foreign-data wrapper for flat file access
`fuzzystrmatch`	Determine similarities and distance between strings
`hstore`	Data type for storing sets of (key, value) pairs
`insert_username`	Functions for tracking who changed a table
`intagg`	Integer aggregator and enumerator (obsolete)
`intarray`	Functions, operators, and index support for 1-D arrays of integers
`isn`	Data types for international product numbering standards
`lo`	Large Object maintenance
`ltree`	Data type for hierarchical tree-like structures
`moddatetime`	Functions for tracking last modification time
`old_snapshot`	Utilities in support of `old_snapshot_threshold`
`pageinspect`	Inspect the contents of database pages at a low level
`pg_buffercache`	Examine the shared buffer cache
`pg_freespacemap`	Examine the free space map (FSM)
`pg_prewarm`	Prewarm relation data
`pg_stat_statements`	Track planning and execution statistics of all SQL statements executed
`pg_surgery`	Perform surgery on a damaged relation
`pg_trgm`	Text similarity measurement and index searching based on trigrams
`pg_visibility`	Examine the visibility map (VM) and page-level visibility info
`pg_walinspect`	Functions to inspect contents of the write-ahead log
`pgaudit`	Provides auditing functionality
`pgcrypto`	Cryptographic functions
`pgrowlocks`	Show row-level locking information
`pgstattuple`	Show tuple-level statistics
`plpgsql`	PL/pgSQL procedural language
`postgres_fdw`	Foreign-data wrapper for remote PostgreSQL servers
`refint`	Functions for implementing referential integrity (obsolete)
`seg`	Data type for representing line segments or floating-point intervals
`sslinfo`	Information about SSL certificates
`tablefunc`	Functions that manipulate whole tables, including crosstab
`tcn`	Triggered change notifications
`tsm_system_rows`	`TABLESAMPLE` method which accepts number of rows as a limit
`tsm_system_time`	`TABLESAMPLE` method which accepts time in milliseconds as a limit
`unaccent`	Text search dictionary that removes accents
`uuid-ossp`	Generate universally unique identifiers (UUIDs)
`vector`	Vector data type and ivfflat and hnsw access methods (pgvector)
`xml2`	XPath querying and XSLT

More extensions on the roadmap

Support for additional extensions from the CloudNativePG PostgreSQL extension containers is on the roadmap.

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.

Backup¶

Backups are taken automatically, with no action required. The defaults are:

Schedule: one backup per day, at a randomly chosen time between 22:00 and 04:00.
Retention: backups are kept for 6 days.
What is backed up: a base backup together with the continuously archived write-ahead log (WAL).
Point-in-time recovery (PITR): you can restore to any point within the retention window. The WAL is archived at least every 5 minutes, so the recovery point objective (RPO) is at most 5 minutes.

Backups are stored in an object store.

More self-service on the roadmap

Configuring the backup schedule, retention, and related settings yourself is on the roadmap, as is self-service restore. For now, restoring an instance from a backup is handled by Servala support.

For how backups and restores work across services, including how to request a restore, see Backups & Restore.

Limits & quotas¶

Maximum database size: to be filled in
Connection limits: to be filled in

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:

Capability	This service	How it works
Backups & Restore	Automated backups with point-in-time recovery	Backups & Restore
Monitoring	Metrics and alerting	Monitoring
Maintenance & Upgrades	Patches and version upgrades	Maintenance & Upgrades
Scaling	Compute, storage, and replicas	Scaling
Network Access	Shared TCP Gateway or dedicated Load Balancer	Network Access
Logs	Instance logs in the portal	Logs
Security	TLS in transit	Security
Service Levels	Availability tiers	Service Levels

Limitations & known issues¶

Some PostgreSQL extensions may not be available

Behind the scenes¶

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