Verify pg_cron >= 1.5 support per platform + vendor-specific enablement steps

[NikolayS]

Goal

Evidence-backed confirmation of pg_cron >= 1.5 support on each Postgres platform we want to list as "runs PgQue's automated ticker", plus the exact vendor-specific steps to enable pg_cron — to feed (a) the pgque.dev "Runs on" logo wall and (b) a new vendor-specific enablement section in docs/installation.md.

Why pg_cron >= 1.5

PgQue's automated ticker (pgque.start()) schedules a 1-second pg_cron slot (ticker_loop re-ticks sub-second). That requires pg_cron's sub-minute / "[1-59] seconds" interval scheduling, introduced in pg_cron 1.5.0. On older pg_cron the auto-ticker can't run at sub-minute cadence (you'd use an external scheduler instead). So a platform only qualifies for the wall if its pg_cron is >= 1.5.

What each verification comment must include (per platform, with EVIDENCE)

• Platform (official name) and category (managed cloud / Postgres-compatible / k8s operator)
• pg_cron available? and the exact version offered (>= 1.5? yes/no/uncertain)
• Enable steps from official docs: the exact flag/parameter to set (e.g. cloudsql.enable_pg_cron=on, alloydb.enable_pg_cron=on, RDS parameter-group shared_preload_libraries=pg_cron, Azure add to shared_preload_libraries, Supabase dashboard toggle, Neon cron.database_name via API), whether a restart/reboot is required, then create extension pg_cron; and setting cron.database_name to the PgQue database.
• Official doc URL (the evidence).
• Verdict: include on wall / exclude (and why).

Platforms to check

Managed: Amazon RDS, Amazon Aurora, Google Cloud SQL, Google AlloyDB, Azure Database for PostgreSQL (Flexible Server), Supabase, Neon, Aiven, DigitalOcean, PlanetScale (Postgres), Render, Vercel Postgres.
Postgres-compatible: YugabyteDB.
Kubernetes operators: CloudNativePG, StackGres, Percona Operator for PostgreSQL.
Excluded: Crunchy Bridge (acquired). ClickHouse (not a Postgres database).

Per-platform evidence comments to follow.

[NikolayS]

Amazon RDS for PostgreSQL

Platform (official name): Amazon RDS for PostgreSQL
Category: Managed cloud

pg_cron available? Version(s)? >= 1.5?

Yes — available, and well above 1.5.

pg_cron is supported on RDS for PostgreSQL engine versions 12.5 and higher. Per the official Extension versions matrix, current minor releases ship modern pg_cron across all PgQue-supported majors:

PG major	pg_cron versions offered (newest → older, current matrix)
18	1.6.7 … 1.6.5
17	1.6.7 … 1.6.2
16	1.6.7 … 1.5.2 (oldest minors shipped 1.5.2)
15	1.6.7 … 1.5.2 … 1.4.1 (oldest minors)
14	1.6.7 … 1.5.2 … 1.4.1 … 1.4 (oldest minors)

The latest offered is 1.6.7. pg_cron >= 1.5 is confirmed on all current/recent RDS minor releases of PG 14–18. (Note: very old PG14/15 minors shipped 1.4.x; pick a current minor to get >= 1.5.)

The sub-minute / '[1-59] seconds' interval scheduling that PgQue's 1-second auto-ticker relies on was introduced in pg_cron 1.5.0. RDS offers 1.6.x today, so the ticker slot is supported.

Exact ENABLE steps (from official docs)

1. Modify the custom DB parameter group for the instance: add pg_cron to the shared_preload_libraries parameter value. (If rds.allowed_extensions is set, also add pg_cron to that list.)
2. Reboot/restart the DB instance so the parameter-group change takes effect. (Required — pg_cron is a shared_preload_libraries extension.)
3. Connect as an rds_superuser account (e.g. postgres) and run:

   create extension pg_cron;

   By default, metadata and scheduling live in the postgres database.
4. To run the ticker against the PgQue database instead of postgres, set the cron.database_name parameter (in the parameter group) to your PgQue database. Alternatively, schedule the job in postgres and update cron.job set database = '<pgque_db>' where jobid = ... as an rds_superuser.

Logo source

• simple-icons slug: amazonrds (Amazon RDS) — https://simpleicons.org/?q=amazon%20rds . Generic AWS mark slug: amazonwebservices.
• AWS Architecture Icons / brand assets: https://aws.amazon.com/architecture/icons/
• Trademark: "Amazon RDS", "Amazon Web Services", "AWS" and the AWS logo are trademarks of Amazon.com, Inc. or its affiliates. Use per AWS Trademark Guidelines (https://aws.amazon.com/trademark-guidelines/).

Evidence (official doc URLs)

• Setup + enable steps: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL_pg_cron.html
• Extension versions matrix (pg_cron version per PG major): https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html
• AWS blog (cross-reference): https://aws.amazon.com/blogs/database/schedule-jobs-with-pg_cron-on-your-amazon-rds-for-postgresql-or-amazon-aurora-for-postgresql-databases/

Verdict

INCLUDE on the "Runs on" wall. pg_cron >= 1.5 confirmed (1.6.7 offered today; >= 1.5 on all current PG 14–18 minors). Auto-ticker supported.

[NikolayS]

Amazon Aurora PostgreSQL

Platform (official name): Amazon Aurora PostgreSQL-Compatible Edition
Category: Postgres-compatible

pg_cron available? Version(s)? >= 1.5?

Yes — available, and well above 1.5.

pg_cron is supported on Aurora PostgreSQL engine versions 12.6 and higher. Per the official Aurora Extension versions matrix, current minor releases ship modern pg_cron across all PgQue-supported majors:

PG major	pg_cron versions offered (newest → older, current matrix)
17	1.6.7 … 1.6.5
16	1.6.7 … 1.6.0
15	1.6.7 … 1.6.0 … 1.5 … 1.4.2 (oldest minors)
14	1.6.7 … 1.6.0 … 1.5 … 1.4 (oldest minors)

The latest offered is 1.6.7. pg_cron >= 1.5 is confirmed on all current/recent Aurora minor releases of PG 14–17. (Note: oldest PG14/15 minors shipped 1.4.x; pick a current minor to get >= 1.5.)

The sub-minute / '[1-59] seconds' interval scheduling that PgQue's 1-second auto-ticker relies on was introduced in pg_cron 1.5.0. Aurora offers 1.6.x today, so the ticker slot is supported.

Exact ENABLE steps (from official docs)

1. Modify the custom DB cluster/parameter group: add pg_cron to the shared_preload_libraries parameter value.
2. Reboot/restart the DB instance so the parameter-group change takes effect. (Required — pg_cron is a shared_preload_libraries extension.)
3. Connect as an rds_superuser account (e.g. postgres) and run:

   create extension pg_cron;

   By default, metadata and scheduling live in the postgres database.
4. To run the ticker against the PgQue database instead of postgres, set the cron.database_name parameter to your PgQue database. Alternatively, schedule the job in postgres and update cron.job set database = '<pgque_db>' where jobid = ... as an rds_superuser.

Logo source

• simple-icons slug: amazonaurora (Amazon Aurora) — https://simpleicons.org/?q=aurora . Generic AWS mark slug: amazonwebservices.
• AWS Architecture Icons / brand assets: https://aws.amazon.com/architecture/icons/
• Trademark: "Amazon Aurora", "Amazon Web Services", "AWS" and the AWS logo are trademarks of Amazon.com, Inc. or its affiliates. Use per AWS Trademark Guidelines (https://aws.amazon.com/trademark-guidelines/).

Evidence (official doc URLs)

• Setup + enable steps: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/PostgreSQL_pg_cron.html
• Aurora Extension versions matrix (pg_cron version per PG major): https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html
• AWS blog (cross-reference): https://aws.amazon.com/blogs/database/schedule-jobs-with-pg_cron-on-your-amazon-rds-for-postgresql-or-amazon-aurora-for-postgresql-databases/

Verdict

INCLUDE on the "Runs on" wall. pg_cron >= 1.5 confirmed (1.6.7 offered today; >= 1.5 on all current PG 14–17 minors). Auto-ticker supported.

[NikolayS]

Google Cloud SQL for PostgreSQL

Category: managed cloud

pg_cron available? Yes. Native, first-class support.

Version offered: pg_cron 1.6.4 (for PostgreSQL 10 and later), per the official Cloud SQL extensions reference. This is >= 1.5 ✅ — sub-minute / seconds scheduling (introduced in pg_cron 1.5.0) is supported.

Enable steps:

1. Set the instance database flag cloudsql.enable_pg_cron=on.
2. Restart required — applying this flag restarts the instance.
3. Connect to the target database and run create extension pg_cron;.
4. pg_cron runs in the database named by cron.database_name (defaults to postgres). On Cloud SQL set this via the cron.database_name flag if you want cron to live in a non-default database. Jobs run as background workers, so size max_worker_processes accordingly.

Notes / gotchas (from Google's docs and community): schedules are evaluated in UTC unless cron.timezone is set; a single background worker runs jobs sequentially.

Logo source: No AlloyDB-style dedicated slug needed — use simple-icons googlecloud (the general Google Cloud mark) or Google Cloud brand assets / svgl.app. "Google Cloud" and "Cloud SQL" are trademarks of Google LLC; use per Google brand guidelines, for identification only.

Official docs:

• Configure PostgreSQL extensions (version table, lists pg_cron 1.6.4): https://docs.cloud.google.com/sql/docs/postgres/extensions

Verdict: INCLUDE on the wall. pg_cron 1.6.4 confirmed (>= 1.5).

[NikolayS]

Google AlloyDB for PostgreSQL

Category: Postgres-compatible

pg_cron available? Yes. Supported extension.

Version offered: AlloyDB's public Supported database extensions reference lists pg_cron as supported but does not publish an exact pg_cron version number (unlike Cloud SQL, which states 1.6.4). Treat the exact version as "not officially documented." The modern flag model (alloydb.enable_pg_cron plus settable cron.database_name / cron.timezone) indicates a current build; sibling Cloud SQL ships 1.6.4. Because an exact >= 1.5 version is NOT explicitly confirmed in AlloyDB's official docs, flag this as unverified for the strict >= 1.5 gate.

Enable steps:

1. Set the instance flag alloydb.enable_pg_cron=on (per the AlloyDB flags reference).
2. Restart required — the AlloyDB flags reference states setting this flag requires an instance restart.
3. Connect to each target database and run create extension pg_cron;.
4. After the flag is on you can also set pg_cron flags such as cron.database_name and cron.timezone.

Logo source: simple-icons has no AlloyDB-specific slug — note this explicitly. Use simple-icons googlecloud (general Google Cloud mark) or pull the AlloyDB product icon from Google Cloud brand assets / svgl.app. "AlloyDB" and "Google Cloud" are trademarks of Google LLC; identification use only, per Google brand guidelines.

Official docs:

• Supported database extensions (lists pg_cron, no version number): https://docs.cloud.google.com/alloydb/docs/reference/extensions
• AlloyDB flags (alloydb.enable_pg_cron, restart required): https://docs.cloud.google.com/alloydb/docs/reference/alloydb-flags
• Configure database extensions (create extension procedure): https://docs.cloud.google.com/alloydb/docs/instance-configure-extensions

Verdict: HOLD / verify before including. pg_cron is supported and the enable path is clean, but AlloyDB's official docs do not state a pg_cron version, so the strict ">= 1.5 confirmed" gate is not satisfied from official sources alone. Confirm by running select extversion from pg_extension where extname='pg_cron'; on a live AlloyDB instance before adding to the wall.

[NikolayS]

Neon (managed cloud)

Platform: Neon — serverless managed Postgres. Category: managed cloud.

pg_cron available? Yes. Version 1.6 (listed for PG 14, 15, 16, 17). 1.6 >= 1.5 ✅ — auto-ticker supported.

Enable steps (verified against official docs):

1. Set cron.database_name to the target database. This is passed via pg_settings in the compute endpoint settings using the Update compute endpoint API (these params are Neon-managed; if you can't set it via the API/settings, open a support ticket with your endpoint ID + database name).
2. Restart the compute (Restart compute endpoint API). Restart is required and drops current connections.
3. create extension if not exists pg_cron;

Critical limitation: "pg_cron jobs will only run when your compute is active." Neon recommends pg_cron only on computes running 24/7 or with scale-to-zero disabled — jobs do not fire while the compute is idle/scaled down. Relevant for the auto-ticker (won't tick during idle).

Logo: simple-icons slug neon — verified present (https://cdn.simpleicons.org/neon → HTTP 200). Trademark: Neon logo is a trademark of Neon Inc. (now Databricks); use per their brand/component icon guide.

Official docs:

• https://neon.com/docs/extensions/pg_cron
• https://neon.com/docs/extensions/pg-extensions

Verdict: INCLUDE (pg_cron 1.6 >= 1.5). Note the scale-to-zero caveat prominently for the auto-ticker.

[NikolayS]

Azure Database for PostgreSQL — Flexible Server

Category: Managed cloud (Microsoft Azure)

pg_cron availability

• Available: YES. Listed in the official supported-extensions table.
• Version: 1.6 for every supported PostgreSQL major (11–18, including 14/15/16/17/18).
• >= 1.5? YES. 1.6 supports the sub-minute scheduling needed for the auto-ticker.

Enable steps (restart required)

1. Allowlist the extension: add pg_cron to the azure.extensions server parameter.
2. Load the library: add pg_cron to the shared_preload_libraries server parameter (e.g. pg_stat_statements,pg_cron).
3. Restart the server — required. Per docs: attempting CREATE EXTENSION when pg_cron is not in shared_preload_libraries, or the server wasn't restarted after it was added, errors with pg_cron can only be loaded via shared_preload_libraries.
4. create extension pg_cron; in the target database.

cron.database_name: Azure does not require setting cron.database_name. Instead it exposes cron.schedule_in_database(...) / cron.alter_job(job_id, database := ...) (pg_cron 1.4+) to run jobs in a specific database. Note: scheduling with a non-null username requires superuser and is NOT supported on Azure — omit/null the username; jobs run as the scheduling user, which needs azure_pg_admin.

Logo

• simple-icons slug: microsoftazure (Microsoft Azure).
• Trademark: "Microsoft Azure" and the Azure logo are trademarks of Microsoft Corporation. Use for identification/reference only; not an endorsement.

Official docs

• Extension versions: https://learn.microsoft.com/en-us/azure/postgresql/extensions/concepts-extensions-versions
• pg_cron considerations (restart/shared_preload_libraries): https://learn.microsoft.com/en-us/azure/postgresql/extensions/concepts-extensions-considerations#pg_cron

Verdict

INCLUDE. pg_cron 1.6 (>= 1.5) is available. Auto-ticker is supported after enabling shared_preload_libraries + restart.

[NikolayS]

Supabase

Category: Managed cloud (Supabase, managed Postgres)

pg_cron availability

• Available: YES. First-class "Supabase Cron" Postgres Module is built on pg_cron.
• Version: 1.6.4 (current on Supabase per official docs).
• >= 1.5? YES. 1.6.4 supports the special pg_cron sub-minute (seconds) syntax — needed for the auto-ticker.

Enable steps (no restart for enabling the extension)

• Dashboard: Integrations -> Cron, enable the Cron Postgres Module (toggles on the pg_cron extension). Schedules can be standard cron, the pg_cron seconds syntax, or natural language.
• SQL: create extension if not exists pg_cron;
• Jobs are created via SQL (cron.schedule(...)) or the Dashboard; stored in cron.job; the extension creates a cron schema.

cron.database_name / restart: On hosted Supabase, pg_cron targets the default database out of the box — no cron.database_name change needed for the standard project DB. cron.database_name only matters in self-hosted/custom-DB-name setups, and changing it requires a server restart (it is a startup-only GUC). Docs also note older projects may need to upgrade Postgres (v15.6.1.122+) to get the latest pg_cron.

Logo

• simple-icons slug: supabase.
• Trademark: "Supabase" and the Supabase logo are trademarks of Supabase, Inc. Use for identification/reference only; not an endorsement.

Official docs

• Cron overview: https://supabase.com/docs/guides/cron
• pg_cron extension: https://supabase.com/docs/guides/database/extensions/pg_cron

Verdict

INCLUDE. pg_cron 1.6.4 (>= 1.5) is available with a one-click Dashboard toggle or create extension. Auto-ticker (incl. sub-minute) supported.

[NikolayS]

Aiven for PostgreSQL (managed cloud)

Platform: Aiven for PostgreSQL. Category: managed cloud.

pg_cron available? Yes. Default version 1.6; supported versions per PG major (14/15/16/17): 1.0, 1.1, 1.2, 1.3, 1.4, 1.4-1, 1.5, 1.6. Default 1.6 >= 1.5 ✅ — auto-ticker supported.

Enable steps (verified against official docs):

• pg_cron is preloaded by Aiven (in shared_preload_libraries). No manual restart needed by the user for that.
• Create it in the target DB: create extension pg_cron;
• Any DB user can manage extensions (default avnadmin or users created via Console/API/CLI/Terraform).
• Aiven docs note pg_cron metadata lives in one database; the Aiven howto walks through restart-then-create extension but the preload is handled by the platform.

Logo: simple-icons slug aiven does NOT exist (https://cdn.simpleicons.org/aiven → HTTP 404). svgl.app has no clean Aiven entry, and vectorlogo.zone aivenio is 404. Use the official Aiven brand kit / visual guidelines instead:

• Press/brand assets: https://aiven.io/press
• Visual guidelines PDF: https://aiven.io/assets/press/aiven-visual-guidelines.pdf
  Trademark note: Aiven logo is a trademark of Aiven Ltd. Their guidelines require the wordmark be used with the crab mark (wordmark-without-crab is disallowed). Follow their visual guidelines.

Official docs:

• https://aiven.io/docs/products/postgresql/howto/use-pg-cron-extension
• https://aiven.io/docs/products/postgresql/reference/list-of-extensions-for-each-version

Verdict: INCLUDE (pg_cron default 1.6 >= 1.5). Logo must come from the Aiven brand kit, not simple-icons.

[NikolayS]

DigitalOcean Managed PostgreSQL (managed cloud)

Platform: DigitalOcean Managed Databases — PostgreSQL. Category: managed cloud.

pg_cron available? Yes — listed as a supported extension ("Job scheduling tool") across PG 13–18. ⚠️ The official supported-extensions page does not publish the exact pg_cron extension version per PG release, so I could not confirm >= 1.5 from official docs. This needs verification by running select extversion from pg_extension where extname='pg_cron'; (or select * from pg_available_extensions where name='pg_cron';) on a live DO cluster before including.

Enable steps:

1. create extension pg_cron;
2. defaultdb-only constraint (verified): postgresql.conf is not user-configurable on the managed service, so cron.database_name cannot be changed — pg_cron only operates on the defaultdb database. The auto-ticker and scheduled jobs must live in defaultdb. No user-driven restart is exposed.

Logo: simple-icons slug digitalocean — verified present (https://cdn.simpleicons.org/digitalocean → HTTP 200). Trademark: DigitalOcean logo/name are trademarks of DigitalOcean, LLC; use per their brand guidelines.

Official docs:

• https://docs.digitalocean.com/products/databases/postgresql/details/supported-extensions/
• https://www.digitalocean.com/community/questions/what-is-usecase-for-pg_cron-extension-if-cron-database-cannot-be-changed (defaultdb constraint)

Verdict: INCLUDE pending version check. Extension is present, but the official docs omit the pg_cron version. Treat as conditional INCLUDE — confirm >= 1.5 on a live cluster. Document the defaultdb-only limitation for the auto-ticker.

[NikolayS]

PlanetScale for Postgres — pg_cron research

What it is: PlanetScale's first-party managed PostgreSQL offering (distinct from their original MySQL/Vitess product). It runs real, dedicated PostgreSQL with configurable extensions managed per-branch via the dashboard.

pg_cron available? Yes. PlanetScale ships pg_cron as a natively supported extension. It is a true server-side background-worker extension (loaded via shared libraries, requires a database restart), not a cron-job workaround.

Version / >= 1.5? PlanetScale's official docs and changelog confirm pg_cron is supported but do not publish an explicit version string (the docs describe parameters, not the version). Given this is a recently launched product on a modern PostgreSQL base, the underlying version is almost certainly current (1.6.x). Action item before listing on the wall: confirm >= 1.5 empirically with:

select default_version from pg_available_extensions where name = 'pg_cron';

Treat as "likely qualifies" but version-unverified from docs alone.

Enable steps (from official docs):

1. PlanetScale org dashboard → select the database.
2. Open the Clusters page → choose the branch.
3. Open the Extensions tab → enable pg_cron and configure parameters.
4. Click Queue extension changes, then Apply changes. This triggers the required database restart (pg_cron loads via shared libraries).
5. In the database:

   create extension if not exists pg_cron;

6. cron.database_name (default postgres) controls which database holds the pg_cron metadata/jobs. Set it to the database where you ran create extension. Other tunables exposed: cron.max_running_jobs, cron.launch_active_jobs, cron.log_run, cron.log_statement, cron.log_min_messages.

Logo: simple-icons slug planetscale (verified, https://cdn.simpleicons.org/planetscale → 200). PlanetScale name/logo are trademarks of PlanetScale, Inc. — use only to denote compatibility, per simple-icons trademark guidance.

Official docs:

• https://planetscale.com/docs/postgres/extensions/pg_cron
• https://planetscale.com/changelog/postgres-extensions-pg-cron-partman-bgw

Verdict: Strong candidate — include pending a one-line version check (>= 1.5). Background-worker pg_cron with proper restart + cron.database_name support means auto-ticker is supported. Only blocker is that docs don't state the exact version; verify before publishing on the wall.

[NikolayS]

Render managed PostgreSQL — pg_cron research

What it is: Render's first-party managed PostgreSQL service. Extensions are enabled per-database by running create extension in a psql session (for PG13+); there is no user control over shared_preload_libraries.

pg_cron available? No. pg_cron is not supported on Render Postgres.

• It does not appear in Render's official supported-extensions list.
• Render staff confirmed explicitly on the official community forum: "We were mistaken. pg_cron is not supported right now," and pointed users to an upvotable feature request instead.

Why: pg_cron requires its background worker to be loaded via shared_preload_libraries at server start. Render does not expose shared_preload_libraries to users, so the extension cannot be activated even though create extension works for other extensions. Render's recommended workaround is an external cron job that connects to the database — which is exactly what PgQue's pg_cron auto-ticker is meant to avoid.

Version / >= 1.5? N/A — not available at any version.

Enable steps: N/A.

Logo: simple-icons slug render (verified, https://cdn.simpleicons.org/render → 200). Render name/logo are trademarks of Render Services, Inc.

Official docs / sources:

• https://render.com/docs/postgresql-extensions (supported extensions list — pg_cron absent)
• https://render.discourse.group/t/postgres-pg-cron-extension/2298 (Render staff: pg_cron not supported)

Verdict: Exclude from the wall. pg_cron is unsupported on Render at any version, so the auto-ticker (needs pg_cron >= 1.5) cannot run. PgQue still installs and works via external/manual ticker, but Render does not meet the pg_cron auto-ticker bar.

[NikolayS]

Vercel Postgres — pg_cron research

What it is: Not a first-party database anymore. Vercel deprecated its own Vercel Postgres product. Per Vercel's official docs: "Vercel Postgres is no longer available. If you had an existing Vercel Postgres database, we automatically moved it to Neon in December 2024." Postgres on Vercel is now purely a Marketplace re-sell — you provision a third-party provider (Neon being the native/default Postgres integration) and Vercel injects the connection env vars. There is no Vercel-operated Postgres engine.

pg_cron available? Only insofar as the underlying provider supports it. The default path is Neon, which ships pg_cron (Neon lists pg_cron as a default-loaded extension, version 1.6.x, i.e. >= 1.5). So a "Vercel Postgres" database is really a Neon database and inherits Neon's pg_cron support and behavior.

Version / >= 1.5? Inherited from Neon: pg_cron 1.6.x → qualifies. But this is Neon's capability, not Vercel's.

Enable steps: Whatever the chosen Marketplace provider requires. For the Neon default, this is Neon's pg_cron flow (per-branch, create extension pg_cron;, autoscaling/compute caveats), governed by Neon's docs — not Vercel's.

Logo: simple-icons slug vercel (verified, https://cdn.simpleicons.org/vercel → 200). Vercel name/logo are trademarks of Vercel, Inc.

Official docs / sources:

• https://vercel.com/docs/postgres (states Vercel Postgres deprecated, migrated to Neon Dec 2024, now Marketplace-only)
• https://neon.com/docs/guides/vercel-postgres-transition-guide (Neon's transition guide)
• https://neon.com/docs/extensions/pg_cron (Neon pg_cron, 1.6.x)

Verdict: Do NOT list Vercel Postgres separately on the wall. It is not an independent platform — it is a Marketplace re-sell of Neon (default) and inherits Neon's pg_cron entirely. Listing it would duplicate the Neon entry and misrepresent it as a first-party DB. Cover it under the Neon entry; if anything, add a one-line footnote that "Vercel Postgres = Neon via Vercel Marketplace."

[NikolayS]

YugabyteDB — Postgres-compatible distributed database

pg_cron available? Yes. YugabyteDB ships pg_cron as a pre-bundled module. The docs describe it as a fully supported, HA-aware integration (leader-based). The official docs do not print an exact default_version string on the pg_cron page; the StackGres/RDS-class builds at this PG line are pg_cron 1.6.x, and YugabyteDB tracks current upstream. Treat as >= 1.5 (meets auto-ticker requirement), but note the version number is not explicitly pinned on the doc page — worth confirming against a live select * from pg_available_extensions where name = 'pg_cron'; on the target YB version before shipping a hard claim.

Enable steps:

1. Set the flag enable_pg_cron = true on all YB-Masters and YB-TServers (cluster-wide gflag — this is the YB-specific part; not just shared_preload_libraries).
2. Optionally set ysql_cron_database_name (defaults to yugabyte) — pg_cron runs in exactly one database.
3. As superuser: create extension pg_cron;

Distributed / leader specifics (important for PgQue ticker):

• pg_cron runs on a single elected pg_cron leader node; only the leader schedules and runs jobs.
• On leader failure another node is auto-elected (HA), but no jobs run for the first ~1 minute after a failover, and in-flight jobs are not retried.
• Job changes can take up to 60 seconds to be picked up by the leader.
• You may connect to any node to schedule.

Implication for PgQue: the auto-ticker on YB has a worst-case ~60s gap on failover/changes. Acceptable for the rotation ticker, but document the failover gap.

Logo: YugabyteDB is not in simple-icons. Best real-logo source: official Yugabyte brand assets / press kit (yugabyte.com). seeklogo.com hosts SVGs but those are unofficial redistributions. Use the vendor brand kit; "YugabyteDB" name and logo are Yugabyte trademarks — attribution/trademark terms apply.

Official docs: https://docs.yugabyte.com/stable/additional-features/pg-extensions/extension-pgcron/ , https://www.yugabyte.com/blog/enhanced-cron-job-resilience-in-yugabytedb/

Verdict: INCLUDE (pg_cron supported, treated >= 1.5). Caveat: pin the exact version against a live instance; document the leader-failover ticker gap.

[NikolayS]

CloudNativePG — Kubernetes operator (CNCF Sandbox)

pg_cron available? Not in the default operand image, and not among the extensions the project officially maintains. The CNPG operand images (ghcr.io/cloudnative-pg/postgresql:NN) do not bundle pg_cron. The community postgres-extensions-containers repo (ImageVolume-based extensions) officially maintains only: pgAudit, pg_crash, pgvector, PostGIS, TimescaleDB (Apache-2), wal2json — pg_cron is not on that list.

So pg_cron on CNPG requires the user to supply it themselves. Two paths:

1. Custom operand image — extend the CNPG PostgreSQL image and install the OS package (e.g. apt-get install -y postgresql-NN-cron). The pg_cron version is then whatever the PGDG package provides (currently 1.6.x — >= 1.5).
2. ImageVolume extension — mount a pg_cron extension image as a volume. Requires PostgreSQL 18+ and Kubernetes 1.33+, and you must build/provide the pg_cron extension image yourself (no official CNPG-maintained one exists yet).

Enable steps (custom-image path):

1. Build image with pg_cron installed.
2. shared_preload_libraries: CNPG auto-manages shared_preload_libraries for a set of well-known extensions, but you should declare pg_cron explicitly via .spec.postgresql.shared_preload_libraries: ["pg_cron"] (operator merges with managed entries).
3. Create the extension via .spec.bootstrap.initdb.postInitSQL (create extension pg_cron) or run it manually post-bootstrap.
4. Restart required: changes to shared_preload_libraries require an instance restart; the operator handles a rolling restart.

Logo: CNCF project. Official artwork repos: https://github.com/cloudnative-pg/artwork and https://github.com/cncf/artwork (mascot "Peggie"). Use the SVG from the project's own artwork repo — that is the canonical, real logo with stated usage/trademark terms. (Not in simple-icons.)

Official docs: https://cloudnative-pg.io/documentation/current/postgresql_conf/ , https://github.com/cloudnative-pg/postgres-extensions-containers , https://cloudnative-pg.io/docs/1.28/imagevolume_extensions/

Verdict: INCLUDE with an asterisk. pg_cron version is >= 1.5 when the user installs it (PGDG package is 1.6.x), but it is not in any official CNPG image — PgQue must tell CNPG users they need a custom image or a self-built ImageVolume. Document as "supported via custom image, not out of the box."

[NikolayS]

StackGres (OnGres) — Kubernetes operator

pg_cron available? Yes. StackGres ships a large managed extension catalog (120+ / "150+" extensions) and pg_cron is part of it — the official major-version-upgrade documentation uses pg_cron version 1.6 in its worked example, which confirms both availability and version. pg_cron 1.6 >= 1.5 → meets the auto-ticker requirement. (Exact set of offered pg_cron versions varies by StackGres release / target PG major; verify against the live pg_available_extensions or the StackGres extensions catalog for the chosen version.)

Enable steps (SGCluster spec):

1. Declare it under spec.postgres.extensions:

   apiVersion: stackgres.io/v1
   kind: SGCluster
   spec:
     postgres:
       extensions:
         - name: pg_cron
           # version: '1.6'   # optional pin

   On kubectl apply, StackGres dynamically downloads the extension into the container (no custom image needed — this is StackGres's main advantage here).
2. pg_cron needs preloading: add shared_preload_libraries = pg_cron (plus any cron.database_name) to the SGPostgresConfig referenced by the cluster.
3. Apply the change; a restart is required for shared_preload_libraries to take effect — perform it via an SGDbOps restart operation.
4. Run create extension pg_cron; in the target database.

Logo: StackGres is not in simple-icons. Best real-logo source: the StackGres brand assets on stackgres.io (project site / press materials) and the OnGres repo (gitlab.com/ongresinc/stackgres, GitHub mirror ongres/stackgres). StackGres is an OnGres trademark; use the vendor brand SVG.

Official docs: https://stackgres.io/doc/1.5/administration/extensions/ , https://stackgres.io/doc/latest/administration/database-operations/major-version-upgrade/ (shows pg_cron 1.6) , https://stackgres.io/extensions/

Verdict: INCLUDE. pg_cron 1.6 confirmed available, installed declaratively via the SGCluster spec (no custom image). Strongest k8s-operator story of the four. Note the SGDbOps restart for shared_preload_libraries.