Can Your PostgreSQL Extension Move to Amazon RDS?
Decide whether an extension-dependent PostgreSQL workload can move to RDS by checking exact versions, installation authority and replacement behavior.
An extension-dependent PostgreSQL workload is a candidate for Amazon RDS only when the proposed target supports its required extension arrangement, the authorized operator can establish it, and the application behavior survives the chosen transfer or replacement. A supported extension name answers one of those questions. It does not establish that the needed version, configuration, objects, permissions or upgrade path are ready.
This article helps a database owner and application lead choose between retaining an extension, replacing its behavior, changing the target or deferring the move. Its output is an extension decision record for one workload. The worked example is constructed, including its extension aliases and supplied results. No database, AWS account, installation or compatibility test was executed. PostgreSQL references use version 18 to define concepts, not to assert that a particular RDS version is available to the reader.
Identify the application dependency before checking a support list
Begin with the operation the application relies on. A product might use an extension's function to normalize identifiers, an operator class to search them, or a background process to maintain partitions. Inventory the actual caller, dependent objects and required behavior. An extension can be installed but unused by the declared workload; an application can also rely on a module configured outside an ordinary extension-installation record.
PostgreSQL's pg_extension catalog records installed extension names, versions, owners and an object-schema reference. The read-only pg_available_extension_versions view instead describes versions available for installation, including prerequisites and trust-related fields. Preserve that distinction in an authorized inventory. Neither an installed list nor an available list independently discovers every application dependency.
Have the application owner trace queries, migrations, generated expressions, indexes, scheduled work and administrative tools that use the dependency. Keep references to reviewed code and object definitions in the record. Do not copy credentials or business documents into a planning spreadsheet. If the team cannot determine whether a background task uses the extension, mark that consumer unresolved rather than removing it from scope.
Bind availability to the proposed RDS engine release
AWS publishes extension versions by RDS PostgreSQL release. Check the exact proposed engine release and extension version, not a table for a different major version. AWS also notes that extension versions do not automatically upgrade during engine-version upgrade workflows. An engine upgrade therefore needs an explicit extension decision rather than an assumption that both advance together.
Use documentation to select a candidate, then request permitted target evidence for that candidate. A source database's catalog cannot establish what another server can install. AWS warns that the rds.extensions display can be inaccurate for extensions added in a minor release. Reconcile the documented release support and authorized target observations instead of treating one display as conclusive proof of absence or presence.
Keep availability, installation and usable behavior as three separate fields. A version may be documented but not installed. An installed extension can still lack a required setting or object privilege. A successful administrative call can coexist with a failing application role. Each finding changes the next action, so a single compatible checkbox would hide useful information.
Separate supported files, installation policy and runtime privilege
PostgreSQL's CREATE EXTENSION reference explains that installation runs the extension's script and requires its supporting files to be available. It also warns that IF NOT EXISTS does not verify that an existing extension matches what the current script would create. A no-error installation attempt is therefore unsuitable as the sole identity check.
RDS has additional extension installation rules. Trusted extensions can be installed by appropriately privileged database users on supported releases. The rds.allowed_extensions setting can restrict new installation, including required dependencies. Removing an already installed extension from that list does not stop its existing use. Treat the setting as an installation control, not an immediate runtime revocation mechanism.
Where the selected release supports delegated extension management, review that path separately. The rds_extension role and delegated allowlist are not universal authority over every extension, and created objects can need additional privileges. Do not grant the application administrative roles to conceal an incomplete installation or access plan. Establish a bounded management identity and the intended runtime identity as different duties.
Compare complete arrangements, including replacement work
There are four useful responses to an incompatible dependency. Retain the extension on a supported target; adopt a supported extension version through a reviewed change; replace the required behavior; or retain another placement while resolving the gap. The smallest apparent change is not always the smallest operating commitment.
| Candidate arrangement | Evidence needed before preferring it |
|---|---|
| Same required extension arrangement | Exact target support, configuration, transfer coverage and application checks |
| Supported version change | Available update path, changed behavior, affected objects and recovery boundary |
| Application or database replacement | Equivalent required behavior, converted state, all callers and an operating owner |
| Different placement or deferral | Continuing support, explicit dependency gap and an owned reassessment trigger |
PostgreSQL's ALTER EXTENSION documentation requires a suitable update script or series of scripts for an update. Do not infer that two available versions imply a supported transition, or that a reverse update exists. A separately restored target and an in-place extension update are different procedures with different state and recovery consequences.
Replacement is also more than substituting a similarly named function. An application can depend on null handling, error behavior, ordering, accepted input, index semantics and privileges. Document which properties must remain equal and which intentional differences the product owner can accept. A change that improves a sample's appearance may still break a unique business identifier or invalidate a stored search result.
Worked example: a replacement preserves rows but changes identity
Assume a fictional application uses identifier_ext revision E1. This is an invented extension alias, not an available PostgreSQL product. Its declared operation removes surrounding ordinary spaces and converts ASCII letters to uppercase. It preserves internal punctuation and returns a missing value unchanged. A dependent uniqueness rule uses that result as the customer key. The application owner stipulates those requirements before reviewing a replacement.
The source's required inputs are three records: A contains " acme-7 ", B contains "ACME7", and C contains a missing value. Quotation marks delimit the string values and are not input characters. Their required normalized outputs are ACME-7, ACME7 and missing. A proposed replacement R1 additionally removes the hyphen. R2 follows the stipulated operation. All outputs below are supplied teaching values, not database observations.
| Supplied arrangement | Result for the declared population |
|---|---|
| Original E1 contract | A and B remain distinct; C remains missing |
| Replacement R1 | A and B both become ACME7, violating required identity distinction |
| Replacement R2 | Supplied outputs match all three required values |
| R2 through the wrong runtime role | Matching administrative output cannot close missing application access evidence |
The row count remains three in every supplied packet. That count cannot establish the uniqueness contract. R1 is rejected under the current requirement even if it installs cleanly and runs quickly. R2 is a candidate for further evaluation, not an accepted migration: target support, object dependencies, actual permissions and transfer evidence remain unobserved.
If the product owner intentionally changes the contract to merge hyphenated identifiers, the decision reopens. It now needs a collision policy, affected-customer treatment and converted dependent state. It cannot inherit R2's equivalence conclusion. Likewise, adding Unicode case rules changes this deliberately ASCII-only example. Expected results must be defined for those inputs before another library's behavior can be judged.
Inspect configuration and recovery without changing production
Some extension arrangements depend on preload modules or parameter settings. AWS's extension overview distinguishes those cases from an ordinary extension installation. Its parameter modification guidance distinguishes dynamic changes from static changes that require a reboot. Parameter-group changes can affect every associated instance. An assessment should identify that scope, not prescribe a shared production change to see whether it works.
Begin with authorized metadata and code inspection under an agreed load and data boundary. A later rehearsal needs a separately authorized isolated target, approved synthetic or sanitized data, scoped identities, a spending bound and a cleanup owner. Installation and update scripts can perform work; they are not harmless inventory reads. Keep production endpoints and unintended downstream destinations outside the rehearsal's authority.
Stop if the target identity is uncertain, a required extension dependency is absent, a collector encounters protected content outside scope or an unexpected process can contact a real destination. Preserve failed observations. Do not drop the extension with cascading dependencies as an improvised rollback. Returning a binary or parameter to its previous version cannot by itself restore transformed data, dependent objects or external effects.
For transfer and final writer handover, use the existing database migration strategy. For comparison-sensitive operations, use the collation compatibility record. For OID-backed attachment contents, use the large-object transfer decision. Those are independent acceptance questions; passing this extension review cannot close them.
Complete one extension decision record
Keep one record per required arrangement rather than one row per extension name. Two workflows using the same installed extension can have different input, access and recovery obligations. Link related records when a shared update changes both. The reusable fields below are planning prompts, not commands or a certificate.
| Record field | What belongs in it |
|---|---|
| Workload and operation | Required behavior, callers, population and independently expected outputs |
| Source evidence | Exact installed version, configuration, owner, dependent objects and evidence date |
| Target candidate | Exact RDS release, documented support, available versions and unresolved observations |
| Management and access | Installation policy, dependencies, management authority and intended runtime role |
| Chosen arrangement | Retain, update, replace or defer, with rejected alternatives and reasons |
| State and recovery | Transfer scope, affected stored objects, last reversible boundary and recovery owner |
| Review result | Failed requirement versus missing evidence, next permitted check and invalidating change |
Ask the application owner to supply one input whose result would make the proposed replacement unacceptable. Ask the database owner to identify the exact target support and management path. Resolve the first disagreement between those two records before agreeing a migration date. An Ampity AWS migration review can scope that compatibility question without treating an extension list as a completed migration assessment.