Category: PostgreSQL compatible

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 […]

When clients start running queries on new Amazon Aurora replicas, they will notice a longer runtime for the first few times that queries are run; this is due to the cold cache of the replica. As the database runs more queries, the cache gets populated and the clients notice faster runtimes. In this post, we focus on how to address the cold cache so clients that are connecting through a load-balanced endpoint get a consistent experience regardless of whether the replicas are automatically or manually scaled. In addition, we also look at other caching solutions such as Amazon ElastiCache, a fully managed Memcached, Redis, and Valkey compatible service, that can further improve the overall experience for latency-sensitive applications and, in some situations (such as higher cache hits), lead to less frequent auto-scaling events of the Aurora read replicas.

pgvector is the open source PostgreSQL extension for vector similarity search that powers generative artificial intelligence (AI) applications using techniques such as semantic search and retrieval-augmented generation (RAG). Amazon Aurora PostgreSQL-Compatible Edition has supported pgvector 0.5.1 since 2023. Amazon Aurora now supports pgvector version 0.7.0, which adds parallelism to improve the performance of building Hierarchical Navigable Small Worlds […]

Claroty is a leading provider of industrial cybersecurity solutions, protecting cyber-physical systems (CPS), such as industrial control systems, operational technology networks, and healthcare networks from cyber threats. Claroty’s business is rooted in its need to efficiently manage large volumes of data and run complex queries to ensure a great user experience for its customers who are reducing security risks to cyber-physical systems. One key workload involves an API that provides users with an interface to extract device, alert, and vulnerability data from the Claroty xDome dashboard, enabling seamless integration into their own data stores. In this post, we share how Claroty improved database performance and scaled Claroty xDome using the advanced features of Aurora.

In this post, we show how you can visualize vector embeddings and explore semantic similarities. We use PCA for dimensionality reduction. PCA is a well-known dimensionality reduction technique that transforms high-dimensional data into a lower-dimensional space while preserving as much of the original variance as possible. By projecting data onto orthogonal axes called principal components, PCA enables you to visualize the underlying structure of the data in a more manageable form