Check PostgreSQL extensions before choosing DigitalOcean Advanced Edition

DigitalOcean's PostgreSQL Advanced Edition became a more realistic migration target on October 6, 2026. You can now enable 20 additional extensions, including pg_trgm, citext, and pgcrypto. That removes a compatibility obstacle for some applications. It does not make every Standard Edition database portable.

Start with your extension inventory and recovery requirements. If either fails the checks below, keep the current database while you resolve the gap. This guide ends with a tested compatibility decision, before a production cutover.

Affiliate disclosure: I may earn a commission at no extra cost to you if you use the DigitalOcean affiliate link below. Sources checked October 7, 2026. This is a documentation-based guide; I have not provisioned a paid cluster, run these examples against DigitalOcean, or measured failover performance for this article.

What changed, and when

Advanced Edition reached general availability on September 17. A September 30 release note said you could no longer add extensions with CREATE EXTENSION. The October 6 note supersedes that restriction for 20 named extensions. The five pre-installed extensions remain available. This is an extension-support update to an existing GA product, rather than a new database launch. DigitalOcean release notes

The useful question is whether your application's dependencies now fit. A support ticket from last week, an old comparison, or a Standard Edition extension list can give you the wrong answer. Check the current Advanced Edition table for the PostgreSQL major version you intend to run.

Inventory the database before shopping

Using your existing approved connection, run this read-only SQL in each source application database. Extensions are installed per database; checking only defaultdb can miss the dependency that matters.

SELECT current_database(), current_user;
SHOW server_version;
SELECT e.extname, e.extversion, n.nspname AS object_schema
FROM pg_extension AS e
JOIN pg_namespace AS n ON n.oid = e.extnamespace
ORDER BY e.extname;

Save the results with your migration notes. pg_extension records installed extensions and their versions. Also inspect application migrations and scheduled jobs for dependencies that are expected but not installed in this particular environment. PostgreSQL extension catalog

Compare every name with DigitalOcean's Advanced Edition extension allowlist. As of this check:

The new support does not grant permission to install arbitrary PostgreSQL extensions. A name appearing in a generic PostgreSQL catalog is not a substitute for the provider's allowlist. Do not remove an extension from production just to make a migration look compatible.

Decide whether the edition solves your problem

Advanced Edition puts a connection pooler in front of the cluster and uses consensus-based primary election. Clients keep the same endpoint when the primary changes. Active connections can still be interrupted, so the application needs to reconnect and handle an uncertain transaction outcome. Advanced supports PostgreSQL 16, 17, and 18; new clusters default to 18. Advanced Edition architecture

Choose it when the supported feature set and availability model justify the cost for your workload. Do not upgrade a quiet development database simply because pg_trgm is newly available on Advanced. Check whether your current edition already supplies everything you need.

There are migration constraints beyond extensions. Advanced Edition currently lacks the online import tool, cross-region cluster relocation, custom CNAME support, and the Prometheus-compatible external metrics endpoint. You also cannot use DigitalOcean's online migration feature to move between its managed clusters. Plan a separately tested data-transfer method rather than assuming an edition switch will copy the database. Current PostgreSQL limits

Edition selection is permanent for a cluster. Before creating a target, confirm the exact edition, PostgreSQL version, CPU option, and region together. Region choices depend on the selected plan; a general PostgreSQL availability listing does not guarantee your preferred Advanced configuration. Keep the target near the application and in the appropriate VPC. Cluster creation and region selection

Price the whole cluster

DigitalOcean's pricing page currently starts Advanced Edition at US$130 per month for an 8 GiB RAM, 2-vCPU primary. Standby and read-only nodes cost the same as the primary. For that minimum configuration:

These are node-cost calculations, before tax and additional resources, not measured bills or quotes. The $130 starting figure does not buy the two-node configuration. Additional Advanced storage is listed at $0.115 per GiB per month. Include any read-only nodes, temporary migration clusters, overlapping source costs, and application hosting in the budget. PostgreSQL pricing

There is another date to watch. On October 15, 2026, Advanced is scheduled to gain Shared CPU plans with 8–64 GiB RAM. The announcement does not give their prices, so do not price them using today's dedicated-node minimum.

From October 15, accounts that have never created either a PostgreSQL or MySQL cluster lose the option to create Standard clusters above 4 GiB or with standby/read-only nodes. That restriction begins November 30 for all accounts creating new clusters. Previously created clusters are unaffected, including their documented resize, restore, fork, and node-addition options. An account that created and later deleted a cluster belongs to the November cohort. Plan-change notice

Do not rush an existing database into a migration because of the headline. If you automate cluster creation, separately check the API, Terraform, or doctl changes applicable to your account before those dates.

Test one dependency in an isolated target

Allow roughly 30–60 minutes for a small compatibility check, plus provisioning and a separate restore rehearsal. You need database administration experience, permission to incur the target's charges, an approved test dataset, and a PostgreSQL client using libpq 16 or later. A live migration needs its own maintenance window and owner.

Create the test target only after the inventory and price checks pass. Restrict trusted sources to the test application and administrator path. Do not open it to 0.0.0.0/0. Use an empty test database and keep the application disconnected from production notifications, schedules, and other write destinations.

Advanced uses the system trust store. For psql, enable full certificate verification and set sslrootcert=system; the Control Panel's copied connection string does not add the latter setting automatically. Do not reuse Standard Edition's downloaded-CA instructions. Connection and TLS guide

From a trusted administrator terminal, replace all four placeholders below with the test target's Connection Details. -W prompts for the password instead of placing it in the command text. This opens a session; it does not create a cluster or database.

psql --no-psqlrc --set=ON_ERROR_STOP=on -W \
  "host=YOUR_TEST_CLUSTER_HOST port=YOUR_TEST_CLUSTER_PORT dbname=YOUR_TEST_DATABASE user=YOUR_ADMIN_USER sslmode=verify-full sslrootcert=system"

First verify the destination and inspect the example dependency:

SELECT current_database(), current_user;
SELECT name, default_version, installed_version
FROM pg_available_extensions
WHERE name = 'pg_trgm';

The view is read-only. A non-null installed_version means the extension is already installed in this database. Record that version; do not assume it matches the source. PostgreSQL available-extension view

If this is the intended empty test database and pg_trgm is available but not installed, run:

CREATE SCHEMA extension_preflight;
CREATE EXTENSION pg_trgm WITH SCHEMA extension_preflight;
SELECT extname, extversion
FROM pg_extension
WHERE extname = 'pg_trgm';
SELECT extension_preflight.similarity('hello', 'hello') = 1 AS trigrams_ok;

These commands create a fresh schema and load extension objects in the test database. Keep that schema owned by the administrator, without write access for untrusted roles. The last query should return true; it is an expected check, not an observed result. If any step fails, stop and inspect the error. Avoid using IF NOT EXISTS as proof of compatibility: PostgreSQL says it does not verify that an existing extension matches the requested one. CREATE EXTENSION behavior

Repeat the check only for dependencies your app actually needs. This first database is only an installation smoke test. Use a separate fresh database for the restore rehearsal, preserving the source's extension object schemas, grants, and search-path requirements. Run the application's real extension-dependent queries there against approved test data. Successful installation is only the first acceptance check.

Rehearse recovery before planning cutover

Restore an approved, access-controlled copy of the application database into an isolated target. Use a PostgreSQL dump/restore workflow suitable for the source and destination versions, and review extension versions, ownership, grants, sequences, and restore errors. pg_dump makes a consistent export of one database; roles and other cluster-global objects need separate treatment. A logical dump is not continuous replication. PostgreSQL pg_dump documentation

Record a short acceptance checklist:

• Every required extension installs in the correct database, with a reviewed version.
• Representative searches, writes, background tasks, and permission checks behave as expected.
• The application verifies TLS and reconnects after a dropped connection without duplicating a transaction.
• A restored copy contains a recent known record and can complete a harmless application task.
• The measured restore duration fits the maintenance window, and somebody owns the go/no-go decision.

Keep the source as the production writer during rehearsal. For the eventual cutover, stop writes, take the final consistent copy, verify the target, and only then redirect clients. Once the target accepts new writes, simply pointing back at the old database can lose those changes; rollback requires reconciliation or a separately proven reverse path.

The buying decision is ready when you can explain why the new edition helps, show that your dependencies work, and afford both the intended topology and the migration overlap. If a required extension is missing or the restore is unproven, keep that as an explicit blocker.

Existing customers can inspect plans in their current account. If DigitalOcean fits a new project, visit DigitalOcean (affiliate link), then select Databases and review the complete configuration before purchasing.