Amazon RDS for PostgreSQL FAQs

Amazon RDS for PostgreSQL currently supports PostgreSQL 13, 14, 15, 16, and 17. RDS for PostgreSQL also supports PostgreSQL 11 and 12 through Amazon RDS Extended Support. See the Amazon RDS User Guide for details.

You can check the list of supported extensions in the Amazon RDS User Guide. To request support for additional extensions, you can send an email to rds-postgres-extensions-request@amazon.com with the extension name and use case.

RDS for PostgreSQL supports several parameters to log activity on your PostgreSQL DB instance. You can learn more about them in the Amazon RDS User Guide for more information.

Yes, you can read about the limitations of RDS for PostgreSQL instances in the Amazon RDS User Guide.

In the context of RDS for PostgreSQL, version numbers are organized as follows: PostgreSQL version = X.Y-R(n).

From the Amazon RDS standpoint, a version change would be considered major if the first part of the version number is being changed. Example: going from 15.9 to 17.1.

A version change would be considered minor if the second part of the version number within the release is being changed. Example: going from 17.1 to 17.2.

R(n) denotes the follow on release to a minor version that may include new features, performance improvements, and bug fixes. A minor version may or may not have R(n) release. Example: going from 17.1 to 17.1-R2 or 17.1-R3

Refer to the PostgreSQL Versioning Policy for more information.

Yes, please refer to the Amazon RDS FAQs for versioning guidance.

Trusted Language Extensions (TLE) for PostgreSQL enable developers to build high performance extensions and run them safely on Amazon RDS. In doing so, TLE improves your time to market and removes the burden placed on database administrators to certify custom and third-party code for use in production database workloads. You can move forward as soon as you decide an extension meets your needs. With TLE, independent software vendors (ISVs) can provide new PostgreSQL extensions to customers running on Amazon RDS.

PostgreSQL extensions are executed in the same process space for high performance. However, extensions might have software defects that can crash the database. 

TLE for PostgreSQL offers multiple layers of protection to mitigate this risk. TLE is designed to limit access to system resources. The rds_superuser role can determine who is permitted to install specific extensions. However, these changes can only be made through the TLE API. TLE is designed to limit the impact of an extension defect to a single database connection. In addition to these safeguards, TLE is designed to provide DBAs in the rds_superuser role fine-grained, online control over who can install extensions and they can create a permissions model for running them.

Only users with sufficient privileges will be able to run and create using the “CREATE EXTENSION” command on a TLE extension. DBAs can also allow-list “PostgreSQL hooks” required for more sophisticated extensions that modify the database’s internal behavior and typically require elevated privilege.

Aurora and Amazon RDS support a curated set of over 85 PostgreSQL extensions. AWS manages the security risks for each of these extensions under the AWS shared responsibility model. The extension that implements TLE for PostgreSQL is included in this set. Extensions that you write or that you obtain from third-party sources and install in TLE are considered part of your application code. You are responsible for the security of your applications that use TLE extensions.

You can build developer functions, such as bitmap compression and differential privacy (such as publicly accessible statistical queries that protect privacy of individuals).

 TLE currently supported creating extensions in JavaScript, Perl, Tcl, PL/pgSQL, and SQL. 

Once the rds_superuser role activates TLE for PostgreSQL, you can deploy TLE extensions using the SQL CREATE EXTENSION command from any PostgreSQL client, such as psql. This is similar to how you would create a user-defined function written in a procedural language, such as PL/pgSQL or PL/Perl. You can control which users have permission to deploy TLE extensions and use specific extensions.

TLE for PostgreSQL accesses your PostgreSQL database exclusively through the TLE API. The TLE supported trusted languages include all functions of the PostgreSQL server programming interface (SPI) and support for PostgreSQL hooks, including the check password hook.

You can learn more about the TLE for PostgreSQL project on the official TLE GitHub page.

For RDS for PostgreSQL, blue/green deployments are supported for version 11.1 and all higher major and minor versions. You can see the Supported Regions and DB engines for Amazon RDS Blue/Green Deployments for more details. 

Amazon RDS Blue/Green Deployments allow you to make safer, simpler, and faster database changes. Blue/Green Deployments are ideal for use cases such as major or minor version database engine upgrades, operating system updates, schema changes on green environments that do not break logical replication, like adding a new column at the end of a table, or database parameter setting changes.

You can use Blue/Green Deployments to make multiple database updates at the same time using a single switchover. This allows you to stay current on security patches, improve database performance, and access newer database features with short, predictable downtime.

Amazon RDS Blue/Green Deployments allow you to make safer, simpler, and faster database changes, such as major or minor version upgrades, schema changes, instance scaling, engine parameter changes, and maintenance updates.

In Amazon RDS Blue/Green Deployments, the blue environment is your current production environment. The green environment is your staging environment that will become your new production environment after switchover.

When Amazon RDS Blue/Green Deployments initiate a switchover, they block writes to both the blue and green environments, until switchover is complete. During switchover, the staging environment, or green environment, catches up with the production system, ensuring data is consistent between the staging and production environment.

Once the production and staging environment are in complete sync, Blue/Green Deployments promote the staging environment as the production environment by redirecting traffic to the newly promoted production environment. Blue/Green Deployments are designed to enable writes on the green environment after switchover is complete, ensuring zero data loss during the switchover process.

If your blue environment is a self-managed logical replica, or subscriber, we will block switchover. We recommend that you first stop replication to the blue environment, proceed with the switchover, and then resume replication. In contrast, if your blue environment is a source for a self-managed logical replica, or publisher, you can continue to switchover. However, you will need to update the self-managed replica to replicate from the green environment post switchover.

Amazon RDS Blue/Green Deployments do not delete your old production environment. If needed, you can access it for additional validations and performance/regression testing. If you no longer need the old production environment, you can delete it. Standard billing charges apply on old production instances until you delete them.

Amazon RDS Blue/Green Deployments switchover guardrails block writes on your blue and green environments until your green environment catches up before switching over. Blue/Green Deployments also perform health checks of your primary and replicas in your blue and green environments. They also perform replication health checks, for example, to see if replication has stopped or if there are errors.

They detect long running transactions between your blue and green environments. You can specify your maximum tolerable downtime, as low as 30 seconds, and if you have an ongoing transaction that exceeds this your switchover will time out.

No, Amazon RDS Blue/Green Deployments do not support Amazon RDS Proxy, cross-Region read replicas, or cascaded read replicas.

No, at this time you cannot use Amazon RDS Blue/Green Deployments to rollback changes.

Amazon DevOps Guru for RDS is a new ML-powered capability for Amazon RDS for PostgreSQL (which includes Amazon Aurora) that is designed to automatically detect and diagnose database performance and operational issues, enabling you to resolve issues in minutes rather than days.

Amazon DevOps Guru for RDS is a feature of Amazon DevOps Guru, which is designed to detect operational and performance issues for all Amazon RDS engines and dozens of other resource types. DevOps Guru for RDS expands the capabilities of DevOps Guru to detect, diagnose, and remediate a wide variety of database-related issues in Amazon RDS for PostgreSQL (e.g. resource over-utilization, and misbehavior of certain SQL queries).

When an issue occurs, Amazon DevOps Guru for RDS is designed to immediately notify developers and DevOps engineers and provides diagnostic information, details on the extent of the problem, and intelligent remediation recommendations to help customers quickly resolve database-related performance bottlenecks and operational issues.

Amazon DevOps Guru for RDS is designed to remove manual effort and shorten time (from hours and days to minutes) to detect and resolve hard to find performance bottlenecks in your relational database workload.

You can enable DevOps Guru for RDS for every Amazon RDS for PostgreSQL database, and it will automatically detect performance issues for your workloads, send alerts to you on each issue, explain findings, and recommend actions to resolve.

DevOps Guru for RDS helps make database administration more accessible to non-experts and assists database experts so that they can manage even more databases.

Amazon DevOps Guru for RDS uses ML to analyze telemetry data collected by Amazon RDS Performance Insights (PI). DevOps Guru for RDS does not use any of your data stored in the database in its analysis. DevOps Guru for RDS looks for problematic patterns in PI telemetry using a combination of rules and ML-based techniques, and alarms customers when such patterns are detected.

To get started with DevOps Guru for RDS, ensure Performance Insights is enabled through the Amazon RDS Console, and simply enable DevOps Guru for your Amazon RDS for PostgreSQL databases. With DevOps Guru, you can choose your analysis coverage boundary to be your entire AWS account, prescribe the specific AWS CloudFormation stacks that you want DevOps Guru to analyze, or use AWS tags to create the resource grouping you want DevOps Guru to analyze.

Amazon DevOps Guru for RDS helps identify a wide range of performance issues that may affect application service quality, such as lock pile-ups, connection storms, SQL regressions, CPU and I/O contention, memory issues, or misconfigured parameters.

Amazon RDS Performance Insights is a database performance tuning and monitoring feature that collects and presents a visual representation of the Amazon RDS database performance metrics, helping you quickly assess the health of your database, and determine when and where to take action. Amazon DevOps Guru for RDS is designed to monitor those metrics, detect when your database is experiencing performance issues, analyze the metrics, and then tell you what’s wrong and what you can do about it.