Category: PostgreSQL compatible

In this post, we discuss integer sequence overflow, its causes, and—most importantly—how to efficiently set up alerts using Amazon SNS and use AWS Lambda to resolve such issues in Amazon Aurora PostgreSQL-Compatible Edition and Amazon RDS for PostgreSQL.

In this post, we focus on working with the features of mysql_fdw PostgreSQL extension on Amazon RDS for PostgreSQL to help manage a large set of data that on an external database scenarios. It enables you to interact with your MySQL database for importing individual/large/selectively number of objects at the schema level and simplifying how we get information about the MySQL/MariaDB schema, to make it easier to ultimately read/write data. We will also provide an introduction to understand query performance on foreign tables.

There are a variety of different techniques available to support data masking in databases, each with their trade-offs. In this post, we explore dynamic data masking, a technique that returns anonymized data from a query without modifying the underlying data. In this post, we discuss a dynamic data masking technique based on dynamic masking views. These views mask personally identifiable information (PII) columns for unauthorized users. This post discusses how to implement this technique in Amazon RDS for PostgreSQL and Amazon Aurora PostgreSQL including Babelfish for Aurora PostgreSQL.

In this post, we provide details on two PostgreSQL plugins available for use by AWS DMS. We compare these plugin options and share test results to help database administrators understand the best practices and benefits of each plugin when working on migrations.

In How the Amazon Timehub team built a data replication framework using AWS DMS: Part 1, we covered how we built a low-latency replication solution to replicate data from an Oracle database using AWS DMS to Amazon Aurora PostgreSQL-Compatible Edition. In this post, we elaborate on our approach to address resilience of the ongoing replication between source and target databases.

In this post, we look at two capabilities in Amazon Bedrock Knowledge Bases that make it easier to build RAG workflows with Amazon Aurora Serverless v2 as the vector store. The first capability helps you easily create an Aurora Serverless v2 knowledge base to use with Amazon Bedrock and the second capability enables you to automate deploying your RAG workflow across environments.

In this post, we demonstrate how to set up an event-driven workflow to run stored procedures for Amazon RDS for PostgreSQL with AWS Lambda to bridge this gap by securely connecting to an Aurora PostgreSQL database using AWS Secrets Manager, making sure that stored procedures can be managed in the cloud. We explore the step-by-step process, discuss the advantages of this approach, and address the limitations of invoking stored procedures from Lambda functions.

In Part 1 of this two-part blog post series, we focused on understanding how certain Amazon Aurora Serverless v2 database parameters influence the scaling of Aurora capacity units (ACUs) to its minimum and maximum amounts. This post is Part 2, and it focuses on understanding how the minimum and maximum configuration of ACUs impacts scaling behavior in Aurora Serverless v2 and how fast scaling occurs after it starts.

The unit of measure for Aurora Serverless v2 is the Aurora capacity unit (ACU). Each workload has unique minimum and maximum ACU requirements. Finding the right ACU configuration and understanding factors influencing Aurora Serverless v2 scaling is essential. This post is Part 1 of a two-part blog post series and focuses on understanding how certain database parameters impact Aurora Serverless v2 scaling behavior for PostgreSQL-compatible DB instances. This post considers minimum ACU to be 0.5 or higher and does not include the new automatic pause feature.

August 2025: This post was reviewed and updated for accuracy. PostgreSQL’s ability to handle concurrent access while maintaining data consistency relies heavily on its locking mechanisms, particularly at the row level. When multiple transactions attempt to lock the same row simultaneously, PostgreSQL turns to a specialized structure called MultiXact IDs. While MultiXacts provide an efficient […]