Aiven for PostgreSQL

To back up an Aiven for PostgreSQL database, Backup connects to it like any other Postgres. Aiven runs real, standard PostgreSQL under the hood, so pg_dump works cleanly. Three Aiven specifics are worth knowing before you start: which connection string to hand Backup, how Aiven's SSL and optional IP filter fit in, and what a restore test does if you've enabled Aiven's own extensions.

Which connection string

Aiven gives every service one service URI. It already carries everything Backup needs: the host, the non-standard port, the default database defaultdb, and the avnadmin user. It looks like:

postgres://avnadmin:<password>@<service-name>.<project>.aivencloud.com:12691/defaultdb?sslmode=require

The port is service-specific and non-standard: Aiven assigns one in the 12000s / 13000s range rather than the usual 5432. Use whatever port your service shows. The host is a public aivencloud.com name and resolves to IPv4, so Backup's IPv4 egress reaches it directly.

Find the connection details

1. In the Aiven Console, open your project and select the PostgreSQL service.
2. On the service Overview page, find the Connection information panel.
3. Copy the Service URI (or pick individual fields: host, port, user, password, database).
4. Paste it into Backup's credentials step, and set SSL mode to require.

Aiven requires TLS for every connection and the service URI already ends in sslmode=require. That mode encrypts the connection without you having to pin Aiven's CA certificate, which is why require is all Backup needs. Aiven issues a per-project CA cert, but that's only for the stricter verify-ca / verify-full modes.

avnadmin works out of the box, but it's Aiven's elevated admin user. For a backup that only ever reads, create a read-only role instead — see below.

Network access

An Aiven service is publicly reachable by default: its IP filter is 0.0.0.0/0, so the avnadmin password is the only thing gating access, and Backup connects with no extra setup.

If you've narrowed the service's Allowed IP addresses (or plan to), add Backup's egress IP so it isn't blocked:

1. In the Aiven Console, open the service and go to Service settings.
2. Scroll to Allowed IP addresses and click Change.
3. Add 18.196.207.101 (a single address, /32), then Save.

Every backup, restore, and restore test reaches your database from that one static IPv4 address, so allow-listing it once covers all of them. Don't remove 0.0.0.0/0 unless you've added every other client that needs in. See network access.

A read-only role instead of avnadmin

avnadmin is not a Postgres superuser on Aiven, but it has elevated rights. A backup only reads, so give it a role scoped to SELECT. Connect once as avnadmin and run, per schema you back up:

CREATE ROLE backup_ro WITH LOGIN PASSWORD '<strong-password>';
GRANT CONNECT ON DATABASE defaultdb TO backup_ro;
GRANT USAGE ON SCHEMA public TO backup_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO backup_ro;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO backup_ro;

The ALTER DEFAULT PRIVILEGES line makes sure tables created later are also readable, so the backup doesn't silently miss new tables. Repeat the grants for each additional schema. Then give Backup a service URI using backup_ro instead of avnadmin.

Restore tests and managed extensions

Every backup can be restore-tested: Backup restores it into a throwaway vanilla Postgres engine and confirms your data comes back.

Aiven's PostgreSQL is standard Postgres, so an ordinary dump restores cleanly. The one Aiven-specific case is aiven_extras — Aiven's own extension that lets avnadmin do superuser-like things. It isn't installed by default; it only ends up in your dump if you ran CREATE EXTENSION aiven_extras. When present, it lives in its own aiven_extras schema and can't be created on a generic engine that doesn't ship it.

That's not your application data, it's Aiven platform tooling, so a restore test treats its absence as expected, notes it in the log, and still records a clean Passed. What the test proves is what matters: your schemas, tables, and rows all restore. Details: Provider-managed extensions.

If your database uses an extension the managed engine doesn't bundle (for example PostGIS or TimescaleDB), point restore tests at a scratch target instead — see restore testing.

From there, it's the standard flow

Backup runs a full pg_dump on your schedule and writes the encrypted archive to storage you control. You can download any backup and restore it with standard Postgres tools, independent of Norcube, which is the point of an off-site copy. Ready to wire it up? Connect a database.