# Amazon Aurora Amazon Aurora is a serverless relational database service compatible with PostgreSQL and MySQL. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Resolve Amazon Aurora PostgreSQL lock contention with Database Insights: Part 2 DevFeed: [Resolve Amazon Aurora PostgreSQL lock contention with Database Insights: Part 2]() Original publisher: [Read original article]() Author: Sameer Kumar Published: 2026-09-14T16:02:16Z Content type: tutorial Language: en Sources: [AWS Database Blog]() Topics: [Amazon Aurora](), [Amazon CloudWatch](), [PostgreSQL](), [Concurrency](), [Monitoring](), [Database](), [Amazon EC2](), [Architecture & Design](), [Amazon Web Services](), [AWS CloudFormation]() Tags: [advanced-300](), [amazon-aurora](), [amazon-cloudwatch](), [amazon-ec2](), [aws](), [aws-cloudformation](), [concurrency](), [monitoring](), [performance](), [postgresql](), [rds-for-postgresql](), [simulation](), [technical-how-to]() ### AI overview This tutorial explains how to diagnose and resolve lock contention in Amazon Aurora PostgreSQL using Amazon CloudWatch Database Insights. It demonstrates Lock Analysis and the Lock Tree visualization for identifying blocking sessions, then covers immediate fixes, configuration changes, optimistic concurrency control, asynchronous processing, SKIP LOCKED, and row splitting. ### Source excerpt Part 1 showed how row lock contention degrades Amazon Aurora PostgreSQL throughput. In Part 2, use Amazon CloudWatch Database Insights and its Lock Tree to pinpoint blocking sessions, then resolve contention with query termination, timeout parameters, and architectural patterns such as SKIP LOCKED and row splitting that restore throughput. ## Troubleshooting row lock contention in Amazon Aurora PostgreSQL: Part 1 - Understanding row lock contention in PostgreSQL DevFeed: [Troubleshooting row lock contention in Amazon Aurora PostgreSQL: Part 1 - Understanding row lock contention in PostgreSQL]() Original publisher: [Read original article]() Author: Sameer Kumar Published: 2026-09-14T16:02:08Z Content type: tutorial Language: en Sources: [AWS Database Blog]() Topics: [Amazon Aurora](), [PostgreSQL](), [Concurrency](), [Monitoring](), [Transactions](), [Amazon CloudWatch](), [Amazon RDS](), [Architecture & Design](), [Extension]() Tags: [advanced-300](), [amazon-aurora](), [amazon-cloudwatch](), [amazon-rds](), [architecture](), [availability](), [concurrency](), [database](), [database-performance](), [extension](), [locks](), [monitoring](), [postgresql](), [production](), [rds-for-postgresql](), [technical-how-to](), [transactions](), [troubleshooting]() ### AI overview This first part of a two-part series explains row lock contention in PostgreSQL and Amazon Aurora PostgreSQL. It covers how concurrent transactions competing for the same rows can reduce throughput and cause timeouts despite healthy CPU and I/O, then introduces PostgreSQL locking internals and monitoring techniques using system views, functions, the pgrowlocks extension, and log_lock_waits. The article notes that the same behavior and investigation approach apply to Amazon RDS for PostgreSQL. ### Source excerpt Row lock contention can collapse database throughput during a flash sale even when CPU and I/O look healthy. In Part 1 of this series, learn how PostgreSQL row locking works and how to monitor lock contention in Amazon Aurora PostgreSQL and Amazon RDS for PostgreSQL using system views, the pgrowlocks extension, and the log_lock_waits parameter. ## Fix circular role dependencies before upgrading Amazon RDS and Amazon Aurora PostgreSQL DevFeed: [Fix circular role dependencies before upgrading Amazon RDS and Amazon Aurora PostgreSQL]() Original publisher: [Read original article]() Author: Ravi Teja Adabala Published: 2026-08-31T23:42:55Z Content type: article Language: en Sources: [AWS Database Blog]() Topics: [PostgreSQL](), [RDS for PostgreSQL](), [Amazon Aurora](), [Amazon RDS](), [SQL](), [postgresql clusters](), [Graphs]() Tags: [amazon-aurora](), [amazon-rds](), [database](), [how-to](), [intermediate-200](), [postgresql](), [rds-for-postgresql](), [sql](), [technical-how-to]() ### AI overview This article explains how circular PostgreSQL role dependencies can cause major version upgrades of Amazon RDS for PostgreSQL and Amazon Aurora PostgreSQL to stall or roll back when upgrading from PostgreSQL 14 or earlier to PostgreSQL 15 or later. It describes a diagnostic query and steps to resolve the dependencies before the upgrade. ### Source excerpt Circular role dependencies can stall or roll back a major version upgrade of Amazon RDS for PostgreSQL or Amazon Aurora PostgreSQL when you move from PostgreSQL 14 or earlier to 15 or later. Learn why this happens, how to detect it with a single pre-upgrade query, and how to clear it before you upgrade. ## Migrate multilingual full-text search from SQL Server to PostgreSQL DevFeed: [Migrate multilingual full-text search from SQL Server to PostgreSQL]() Original publisher: [Read original article]() Author: Ken Zhang Published: 2026-08-20T20:34:44Z Content type: tutorial Language: en Sources: [AWS Database Blog]() Topics: [PostgreSQL](), [sql-server](), [SQL](), [Amazon Aurora](), [Amazon RDS](), [tokenization]() Tags: [advanced-300](), [amazon](), [amazon-aurora](), [amazon-rds](), [aws](), [blog](), [how-to](), [postgresql](), [postgresql-compatible](), [rds-for-postgresql](), [sql](), [technical-how-to](), [tokenization]() ### AI overview This tutorial explains how to migrate multilingual full-text search from SQL Server to PostgreSQL while preserving comparable behavior. It covers collations, text search configurations, language-specific tokenization, accent-insensitive search, synonym expansion, and validation testing on Amazon Aurora PostgreSQL and Amazon RDS for PostgreSQL. ### Source excerpt Migrating full-text search from SQL Server to PostgreSQL can silently change results because the engines handle text, linguistics, and accents differently. This post shows how to reproduce SQL Server full-text search on Amazon Aurora PostgreSQL and Amazon RDS for PostgreSQL, covering collation, tokenization, accent-insensitive search, and synonyms. ## Scale pgvector with binary quantization on Amazon Aurora PostgreSQL DevFeed: [Scale pgvector with binary quantization on Amazon Aurora PostgreSQL]() Original publisher: [Read original article]() Author: Steve Dille Published: 2026-08-18T16:37:22Z Content type: tutorial Language: en Sources: [AWS Database Blog]() Topics: [Amazon Aurora](), [PostgreSQL](), [quantization](), [AI search](), [Compression](), [Embeddings](), [Cache](), [Latency](), [datasets](), [configuration](), [postgresql clusters](), [Database]() Tags: [advanced-300](), [ai](), [amazon-aurora](), [cache](), [compression](), [datasets](), [embeddings](), [latency](), [postgresql](), [postgresql-compatible](), [quantization](), [rds-for-postgresql](), [search](), [technical-how-to](), [validation](), [vector]() ### AI overview This practical guide explains how to use binary quantization with reranking in pgvector to scale HNSW vector search on Amazon Aurora PostgreSQL. It covers index-size reduction, performance and recall tradeoffs, sizing, validation, and suitable operating conditions for datasets ranging from 5 million to 100 million vectors. ### Source excerpt Learn how to use binary quantization with reranking (HNSW+BQ) in pgvector to scale vector search to hundreds of millions or billions of vectors on Amazon Aurora PostgreSQL, with practical guidance on index sizing, recall validation, and the scenarios where the approach works best. ## From Batch Snapshots to Near-Real-Time Data DevFeed: [From Batch Snapshots to Near-Real-Time Data]() Original publisher: [Read original article]() Author: Doximity Published: 2026-08-04T16:29:00Z Content type: article Language: en Sources: [Doximity]() Topics: [data](), [Kafka](), [Streaming](), [MySQL](), [Amazon Aurora]() Tags: [amazon-aurora](), [architecture](), [data](), [kafka](), [mysql](), [pipelines](), [streaming]() ### AI overview Doximity describes combining batch database snapshots with Change Data Capture to make data available in minutes while retaining batch-based consistency and recovery guarantees. The design uses Kafka and includes a trusted snapshot, metadata-preserving routing, a base-plus-delta view, and synthetic cascade deletes. In a 12-day measurement window, 95% of sampled events reached the queryable intermediate layer within eight minutes of publication to Kafka. ### Source excerpt Change Data Capture (CDC) is often presented as a straightforward pipeline: read a database transaction log, publish each change, and apply those changes to another system. That description is accurate, but it leaves out many of the decisions that determine whether the resulting data can be trusted. At Doximity, we already had a batch pipeline that periodically copied snapshots of application databases into our data warehouse. Those snapshots were reliable, but their freshness was measured in hours. We introduced CDC to make changes available in minutes so downstream transformations and operational analytics would not have to wait for the next batch snapshot. We continued using the batch pipeline for the consistency and recovery guarantees it already provided. Over a 12-day measurement window, 95% of events from a stratified sample of active tables reached the queryable intermediate layer within eight minutes of being published to Kafka. The most interesting parts of the project were not the connections from a source database to Kafka or from Kafka to Snowflake, but four questions we had to answer around them: How could we reuse our existing, transactionally consistent batch snapshots as an on-demand starting point for CDC, without reprocessing every existing row? How could we onboard new tables and absorb schema changes from many source databases across our products without growing operational overhead for each one? How could new changes become queryable without waiting for the warehouse to merge them into place? How could we handle cascading child deletes that MySQL performs but never emits as individual binary-log events? Our answers are the four design decisions in this article: a trusted batch snapshot, metadata-preserving routing, a base-plus-delta view, and synthetic cascade deletes. Together, they turned a stream of row changes into a system we could bootstrap, scale, validate, and recover. The sections that follow explain the tradeoffs and guardrails so rea ## Why Oracle and Amazon Aurora May Strain Under Cloud-Scale Workloads DevFeed: [Why Oracle and Amazon Aurora May Strain Under Cloud-Scale Workloads]() Original publisher: [Read original article]() Author: David Weiss Published: 2026-01-16T00:00:00Z Content type: article Language: en Sources: [Cockroach Labs]() Topics: [Oracle Database](), [Amazon Aurora](), [Cloud](), [Databases](), [Availability](), [consistency](), [systems](), [Deployment]() Tags: [alternatives](), [amazon-aurora](), [architecture](), [availability](), [cloud](), [consistency](), [deployment](), [distributed](), [oracle](), [performance]() ### AI overview The article argues that Oracle and Amazon Aurora were designed around architectural assumptions that can constrain modern cloud-scale workloads. It outlines requirements including global availability, horizontal scaling for reads and writes, strong cross-region consistency, zero-downtime operations, and flexible deployment. ### Source excerpt Oracle and Amazon Aurora continue to power many mission-critical applications. As cloud-scale workloads evolve, however, the definition of "enterprise-ready" has fundamentally shifted. ## DSQL Vignette: Reads and Compute DevFeed: [DSQL Vignette: Reads and Compute]() Original publisher: [Read original article]() Author: Marc Brooker Published: 2024-12-04T00:00:00Z Content type: article Language: en Sources: [Marc Brooker's Blog](), [Marc Brooker's Blog]() Topics: [DSQL](), [Databases](), [Scalability](), [Architecture & Design](), [SQL](), [Amazon Web Services](), [Amazon Aurora](), [AWS Lambda](), [Firecracker]() Tags: [architecture](), [aws](), [aws-lambda](), [cloud-native](), [database](), [dsql](), [firecracker](), [scalability](), [sql]() ### AI overview This article examines the architecture behind Aurora DSQL, focusing on SQL execution and transactional reads. It explains how DSQL independently scales compute, read throughput, write throughput, and storage by disaggregating storage from compute, and describes its dynamically scalable SQL execution layer. The article also discusses lessons from AWS Lambda and the use of Firecracker MicroVMs running customized Postgres engines for transactions. ### Source excerpt DSQL Vignette: Reads and Compute The easy half of a database system? In today's post, I'm going to look at half of what's under the covers of Aurora DSQL, our new scalable, active-active, SQL database. If you'd like to learn more about the product first, check out the official documentation, which is always a great place to go for the latest information on Aurora DSQL, and how to fit it into your architecture. Today, we're going to focus on running SQL and doing transactional reads. But first, let's talk scalability. One of the most interesting things in DSQL's architecture is that we can scale compute (SQL execution), read throughput, write throughput, and storage space independently. At a fundamental level, scaling compute in a database system requires disaggregation of storage and compute. If you stick storage and compute together, you end up needing to scale one to scale the other, which is either impossible or uneconomical. That's why, when we launched Aurora 10 years ago (nearly to the day!) we chose an architecture which separated compute and storage (from Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases, SIGMOD'17): As the paper says: We use a novel service-oriented architecture (see Figure 1) with a multi-tenant scale-out storage service that abstracts a virtualized segmented redo log and is loosely coupled to a fleet of database instances. In DSQL, we took this pattern one step further: we changed the interface between the SQL executor and storage to remove the need for a large local cache1 right next to the SQL engine. With that out of the way, we could build a new scalable SQL execution layer which can dynamically scale to meet the needs of nearly any workload. Compute Scale: Lessons from Lambda Aurora wasn't the only big launch at re:Invent 2014. Another big one was AWS Lambda2. AWS Lambda brought a new compute scalability model: the ability to scale up efficiently in small units, each with a single well-defined ## Let Your AWS Lambdas Survive Thousands of Connections DevFeed: [Let Your AWS Lambdas Survive Thousands of Connections]() Original publisher: [Read original article]() Author: Andrew Tate Published: 2024-12-02T18:13:48Z Content type: article Language: en Sources: [Blog -- Neon Docs]() Topics: [AWS Lambda](), [Amazon Aurora](), [autoscaling](), [Database](), [Latency](), [Amazon Web Services]() Tags: [amazon-aurora](), [autoscaling](), [aws](), [aws-lambda](), [database](), [latency](), [node-js](), [postgres](), [product]() ### AI overview The article explains how AWS Lambda's rapid autoscaling can overwhelm database connections, especially with Amazon Aurora Serverless v2. It describes connection pool exhaustion, lingering zombie connections, and cold-start latency, then introduces pooled connections and Amazon RDS Proxy as mitigation approaches. ### Source excerpt AWS Lambda is pretty awesome. Serverless "Functions as a Service" where you can deploy code without worrying about servers, scaling, or infra. Well, that's the dream. The reality can be a bit nearer earth, especially when Lambda bumps up against other services, say databases. Thi... ## Resource Management in Aurora Serverless DevFeed: [Resource Management in Aurora Serverless]() Original publisher: [Read original article]() Author: Marc Brooker Published: 2024-07-29T00:00:00Z Content type: article Language: en Sources: [Marc Brooker's Blog](), [Marc Brooker's Blog]() Topics: [Amazon Aurora](), [Serverless](), [distributed-systems](), [Databases](), [Cache](), [Latency]() Tags: [amazon-aurora](), [cache](), [cost](), [databases](), [distributed-systems](), [latency](), [linux](), [memory-management](), [mysql](), [performance](), [serverless](), [transactions]() ### AI overview The article explains how Amazon Aurora Serverless manages database resources as workloads change. It focuses on in-place scaling, cost and performance effects, uninterrupted connections and transactions, and the memory-management challenges of preserving database working sets and cache performance. ### Source excerpt Resource Management in Aurora Serverless Systems, big and small. My favorite thing about distributed systems is how they allow us to solve problems at multiple levels: single process problems, single machine problems, multi-machine problems, and large-scale cluster problems. Our new paper Resource management in Aurora Serverless1 describes what this looks like in context of a large-scale running system: Amazon Aurora Serverless. What is Aurora Serverless? Aurora Serverless (or, rather, Aurora Serverless V2 for reasons the paper explains) allows Amazon Aurora databases to scale in place as their workload changes, reducing costs, simplifying operations, and improving performance for customers with cyclical, seasonal, or organically growing workloads. Here's one example of what that looks like: Notice how the size of the database (ACU allocation) grows and shrinks with the workload. It does that without disrupting connections, while transactions are running, and while keeping all session state. In this example there is some latency impact, but its small compared to what would have been achievable with manual scaling (and even smaller than the impact of having an under-sized database for the peaks). Managing memory is what makes this a truly interesting systems problem. Traditional relational database engines are highly dependent on high local cache hit rates for performance. Aurora is slightly less so, but having the core working set3 in cache is still important for good OLTP performance. Working sets grow and shrink, and change, with changing access patterns. Scaling a database while offering good performance requires a careful and deep understanding of the size and occupancy of working sets, and careful management to ensure that the optimal amount of memory is available to store them. Lowest Level: Hypervisor, Kernel, and DB Engine By default, both Linux and database engines like Postgres and MySQL have a hungry hungry hippo approach to memory management: they assume ## Introducing New Heroku Postgres Essential Plans Built On Amazon Aurora DevFeed: [Introducing New Heroku Postgres Essential Plans Built On Amazon Aurora]() Original publisher: [Read original article]() Author: Jonathan Brown Published: 2024-05-21T22:05:00Z Content type: release Language: en Sources: [Heroku]() Topics: [Heroku](), [PostgreSQL](), [Amazon Aurora](), [Databases](), [migration](), [Scalability]() Tags: [amazon-aurora](), [database](), [developer-tools](), [heroku](), [heroku-postgres](), [launch](), [migration](), [news](), [performance](), [pgvector](), [postgres](), [product-features](), [scalability](), [sql](), [vector]() ### AI overview Heroku announces new Postgres Essential plans built on Amazon Aurora. The plans include pgvector support, no row-count limits, a 32 GB option, PostgreSQL compatibility, and fully managed database service starting at $5 per month. Existing Mini and Basic plans are scheduled for automatic migration. ### Source excerpt We're thrilled to launch our new Heroku Postgres Essential database plans. These plans have pgvector support, no row count limits, and come with a 32 GB option. We deliver exceptional transactional query performance with Amazon Aurora as the backing infrastructure. One of our beta customers said: "The difference was noticeable right from the start. Heroku [...] The post Introducing New Heroku Postgres Essential Plans Built On Amazon Aurora appeared first on Heroku.