Skip to content

Other Managed PostgreSQL Services

This section applies to any managed PostgreSQL service not covered above, including DigitalOcean Managed Databases, Neon, Railway, Render, Supabase, Aiven, Tembo, and similar platforms. It also describes what a managed service must offer for pg_auto_mv to be installable.

What a Service Must Provide

If you were able to install pg_relay on a managed PostgreSQL service, you can install pg_auto_mv on the same service. A managed PostgreSQL service supports pg_auto_mv if it provides all of the following:

Requirement Why it is needed
A superuser-equivalent role with CREATE privileges pg_auto_mv creates a schema, types, tables, views, functions, and triggers. These require CREATE on the database and USAGE on pg_catalog.
Standard PostgreSQL DML and DDL support pg_auto_mv uses triggers, PL/pgSQL functions, EXECUTE, FOR UPDATE SKIP LOCKED, and clock_timestamp(). All are standard PostgreSQL — no extensions beyond pg_relay are required.
The ability to run arbitrary SQL statements You must be able to execute the contents of sql/pg_auto_mv--1.0.sql and sql/pg_auto_mv--1.0--1.1.sql via psql or any SQL client. This is available on every managed service that provides a connection string.
pg_relay already installed The pgrelay schema must exist in the target database. pg_auto_mv registers its action channels in pgrelay.actions as its final installation step. If pgrelay does not exist, the SQL file will fail.
The pg_relay Processor running The Processor is a separate binary that connects to the database and dispatches queued events. Without it, pg_relay (and therefore pg_auto_mv) cannot execute refreshes.
Session-mode or direct connections The pg_relay Processor requires a session-pinned backend for its instance-slot advisory lock. Transaction-mode poolers (e.g. PgBouncer transaction pooling, Supabase's port 6543) are not supported. Your application can use a transaction pooler; the Processor must not.

The key principle: if your managed service has enough access for pg_relay, it has enough access for pg_auto_mv. pg_relay is the harder installation — it involves deploying a Go binary and configuring it as a persistent service. pg_auto_mv is a single SQL file run against the database.

Services Known to Support pg_relay (and therefore pg_auto_mv)

The following platforms provide a superuser-equivalent role and the ability to run arbitrary SQL:

  • DigitalOcean Managed Databases — the doadmin user has sufficient privileges.
  • Neon — the project owner role has sufficient privileges. Neon uses serverless compute; the pg_relay Processor must run externally (a VM, container, or similar).
  • Railway — the default railway user has superuser privileges.
  • Render — the admin user on a Render PostgreSQL instance has sufficient privileges.
  • Supabase — use the postgres role (available in the Database settings panel, not the default anon API key). Connect on port 5432 (direct session connection), not 6543 (transaction pooler).
  • Aiven for PostgreSQL — the avnadmin user has sufficient privileges.
  • Tembo — the postgres user has superuser on Tembo instances.

This list is not exhaustive. If your service provides a role with SUPERUSER or CREATEROLE + CREATEDB and lets you run arbitrary SQL, it is compatible. If you are able to install pg_auto_mv on a service not listed here, let us know at [email protected] and we will update our documentation accordingly.

Generic Installation Steps

These steps work on any compatible managed service.

Step 1 — Confirm pg_relay is installed:

SELECT COUNT(*) FROM pgrelay.actions;

If this fails, install pg_relay first.

Then confirm the pgrelay.schedule type from Prerequisite 2 is present and is 1.1.2+:

SELECT pgrelay.describe(ARRAY[pgrelay.on_day_times('mon=0500', 'tue=1730')]);
-- Mon at 05:00; Tue at 17:30 UTC

If this fails with function ... does not exist, the schedule type is missing or predates 1.1.2 — run schedule/install.sql from pg_relay 1.1.2+ before continuing. It upgrades in place and preserves existing values.

Step 2 — Create the pgauto_mv schema:

psql -h your-host -U admin_user -d your_database \
     -c "CREATE SCHEMA pgauto_mv;"

Step 3 — Deploy pg_auto_mv:

psql -h your-host -U admin_user -d your_database \
     -f sql/pg_auto_mv--1.0.sql \
     -f sql/pg_auto_mv--1.0--1.1.sql

Set PGSSLMODE=require if your service enforces SSL (most do):

export PGSSLMODE=require
psql -h your-host -U admin_user -d your_database \
     -f sql/pg_auto_mv--1.0.sql \
     -f sql/pg_auto_mv--1.0--1.1.sql

Step 4 — Verify:

-- Both rows must be present
SELECT channel FROM pgrelay.actions WHERE channel LIKE 'pg_auto_mv.%';

-- All tables must exist
SELECT table_name
FROM information_schema.tables
WHERE table_schema = 'pgauto_mv'
ORDER BY table_name;

When a Service Cannot Support pg_auto_mv

A managed service that cannot support pg_relay also cannot support pg_auto_mv. The typical blockers are:

  • No superuser-equivalent role. Some services (e.g. AWS RDS read replicas, Azure read replicas) provide only read-only access. pg_auto_mv cannot be installed on a read-only endpoint — install it on the primary and let the read replica receive data via replication.
  • Transaction-mode pooler enforced. If the service provides only a transaction-mode pooler and no session-mode connection path, the pg_relay Processor cannot maintain its instance-slot lock. Contact your provider — most offer a session-mode port alongside the pooler.
  • The pg_relay Processor cannot maintain a persistent connection. Some serverless platforms (e.g. Neon's autosuspend) put the database to sleep when idle. The Processor must maintain a persistent 1-second poll loop. Run the Processor on external compute (a VM or container) that can hold a long-lived connection.