# Amazon Aurora Published articles for Amazon Aurora. 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. ## Validating multi-Region DR for Terraform Enterprise with AWS FIS DevFeed: [Validating multi-Region DR for Terraform Enterprise with AWS FIS]() Original publisher: [Read original article]() Author: Frenil Randeria Published: 2026-09-09T21:05:02Z Content type: article Language: en Sources: [AWS Architecture Blog]() Topics: [Terraform](), [AWS Fault Injection Service (FIS)](), [Chaos Engineering](), [Amazon S3](), [Amazon EC2](), [Databases]() Tags: [advanced-300](), [amazon-aurora](), [amazon-ec2](), [amazon-s3](), [aws](), [aws-fault-injection-service-fis](), [disaster-recovery](), [postgresql](), [technical-how-to](), [terraform](), [validation]() ### AI overview This article explains how to validate customer-operated multi-Region disaster recovery for Terraform Enterprise on AWS using three-phase AWS FIS experiments. It covers failover and failback testing, hidden dependency discovery, and reported recovery times of 12-14 minutes. ### Source excerpt Learn how AWS, HashiCorp, and Athenahealth designed and chaos-tested a multi-Region disaster recovery strategy for Terraform Enterprise on AWS. This post walks through three-phase AWS Fault Injection Service experiments across Amazon EC2, Aurora, and Amazon S3, the 12-14 minute recovery times achieved, and the state file dependency pitfall to avoid. ## Building async Python applications with Tortoise ORM and Amazon Aurora DSQL DevFeed: [Building async Python applications with Tortoise ORM and Amazon Aurora DSQL]() Original publisher: [Read original article]() Author: Lasita Bhattacharya Published: 2026-09-09T15:27:43Z Content type: tutorial Language: en Sources: [AWS Database Blog]() Topics: [DSQL](), [Concurrency](), [AWS IAM](), [Database](), [CRUD]() Tags: [advanced-300](), [amazon-aurora](), [concurrency](), [database](), [dsql](), [how-to](), [iam](), [orm](), [postgresql](), [python](), [rideshare](), [serverless](), [technical-how-to]() ### AI overview A tutorial for building a high-concurrency asynchronous Python rideshare application with Tortoise ORM and Amazon Aurora DSQL. It covers UUID-based models, IAM-authenticated asyncpg connections, OCC retry handling, and asynchronous CRUD operations. ### Source excerpt Build a high-concurrency async Python rideshare application with Tortoise ORM and Amazon Aurora DSQL. This post walks through the key adaptations: UUID primary keys, IAM-authenticated asyncpg connections with a connection-pool patch, individual DDL execution, and optimistic concurrency control (OCC) retry logic. ## Monitor self-managed databases with Amazon CloudWatch Database Insights DevFeed: [Monitor self-managed databases with Amazon CloudWatch Database Insights]() Original publisher: [Read original article]() Author: Nirupam Datta Published: 2026-09-03T18:10:43Z Content type: article Language: en Sources: [AWS Database Blog]() Topics: [Databases](), [Amazon EC2](), [dashboards]() Tags: [amazon-aurora](), [amazon-cloudwatch](), [amazon-ec2](), [amazon-rds](), [announcements](), [dashboards](), [database](), [intermediate-200](), [monitoring](), [postgresql](), [sql]() ### AI overview Amazon CloudWatch Database Insights now monitors self-managed PostgreSQL on Amazon EC2 alongside Aurora and Amazon RDS databases from one console. ### Source excerpt Amazon CloudWatch Database Insights now extends to self-managed databases. Monitor self-managed PostgreSQL on Amazon EC2 alongside your Amazon Aurora and Amazon RDS fleet from a single console, with the same DB Load, Top SQL, and wait event analysis you use for managed databases. ## Troubleshoot AWS Advanced JDBC Wrapper configuration for Aurora Global Database write forwarding DevFeed: [Troubleshoot AWS Advanced JDBC Wrapper configuration for Aurora Global Database write forwarding]() Original publisher: [Read original article]() Author: Hema Saminathan Published: 2026-09-03T16:26:20Z Content type: tutorial Language: en Sources: [AWS Database Blog]() Topics: [configuration](), [Database](), [MySQL](), [Latency]() Tags: [advanced-300](), [amazon-aurora](), [aws](), [drivers](), [global](), [latency](), [mysql](), [postgresql](), [technical-how-to]() ### AI overview A configuration troubleshooting guide for the AWS Advanced JDBC Wrapper with Aurora Global Database write forwarding. It explains Region-specific settings for primary and secondary Regions, including MySQL-specific write-forwarding behavior. ### Source excerpt Configuring the AWS Advanced JDBC Wrapper for Amazon Aurora Global Database with write forwarding requires Region-specific settings, and misconfiguration causes latency spikes and connection failures. This post walks through the correct dialect, plugins, host patterns, and write forwarding settings for the primary and secondary Regions. ## SQL Server to Aurora PostgreSQL conversion with AI agents for AWS DMS DevFeed: [SQL Server to Aurora PostgreSQL conversion with AI agents for AWS DMS]() Original publisher: [Read original article]() Author: Mayur Aggarwal Published: 2026-09-01T15:19:13Z Content type: tutorial Language: en Sources: [AWS Database Blog]() Topics: [AWS Database Migration Service](), [sql-server](), [Database Migration](), [Model Context Protocol](), [Databases]() Tags: [advanced-300](), [ai-agents](), [amazon-aurora](), [aws-database-migration-service](), [database-migration](), [how-to](), [mcp](), [postgresql](), [technical-how-to]() ### AI overview Tutorial on using AI agents with AWS DMS Schema Conversion to convert SQL Server schemas to Aurora PostgreSQL through natural-language workflows. ### Source excerpt Learn how to use AI agents with AWS DMS Schema Conversion to orchestrate SQL Server to Amazon Aurora PostgreSQL schema conversion through natural language. See how the conversion engine processes T-SQL, how the agent drives the workflow, and how to interpret and resolve CRITICAL action items using decision frameworks for common incompatibilities. ## 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. ## CORTO's billion-scale legal semantic search with Aurora PostgreSQL pgvector DevFeed: [CORTO's billion-scale legal semantic search with Aurora PostgreSQL pgvector]() Original publisher: [Read original article]() Author: Anisa Dean Published: 2026-08-26T16:40:00Z Content type: article Language: en Sources: [AWS Database Blog]() Topics: [AI search](), [tenant data protection]() Tags: [advanced-300](), [ai](), [amazon-aurora](), [architecture](), [compliance](), [customer-solutions](), [embedding](), [postgresql](), [postgresql-compatible](), [production](), [scale](), [search]() ### AI overview CORTO describes scaling legal semantic search on Amazon Aurora PostgreSQL with pgvector for billions of documents and vectors. The article focuses on embedding choices, multi-tenant isolation, cost efficiency, and sub-second query performance. ### Source excerpt How CORTO scaled Amazon Aurora PostgreSQL with pgvector to 7.6 billion vectors and 2.5 billion documents in production, delivering sub-second legal search for 10,000+ law firms at 75% lower storage cost. ## 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. ## Understand memory management in Amazon RDS for PostgreSQL to avoid out of memory DevFeed: [Understand memory management in Amazon RDS for PostgreSQL to avoid out of memory]() Original publisher: [Read original article]() Author: Ankita Singh Published: 2026-08-19T22:21:10Z Content type: tutorial Language: en Sources: [AWS Database Blog]() Topics: [PostgreSQL](), [Memory Leaks](), [Processes](), [Linux](), [Monitoring](), [Amazon Web Services](), [Availability]() Tags: [advanced-300](), [amazon-aurora](), [amazon-cloudwatch](), [amazon-rds](), [availability](), [aws](), [memory](), [monitoring](), [postgresql](), [postgresql-compatible](), [processes](), [production](), [rds-for-postgresql](), [technical-how-to]() ### AI overview A practical guide to PostgreSQL memory management on Amazon RDS for PostgreSQL and Amazon Aurora PostgreSQL. It explains how memory is allocated, how memory-intensive queries and diagnostic signals can be identified, and how to diagnose, prevent, and recover from out-of-memory events and excessive disk spilling. ### Source excerpt PostgreSQL out-of-memory (OOM) events and excessive disk spilling are among the most common production incidents on Amazon RDS for PostgreSQL and Amazon Aurora PostgreSQL. Learn how PostgreSQL allocates and consumes memory, how to identify memory-intensive queries, and how to diagnose, prevent, and recover from OOM events on both engines. ## 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. ## Consistency is the new latency: AI at the data layer DevFeed: [Consistency is the new latency: AI at the data layer]() Original publisher: [Read original article]() Author: Suman Chatterjee Published: 2026-08-18T11:13:20Z Content type: article Language: en Sources: [AWS Architecture Blog]() Topics: [AI Bots](), [Language models](), [web applications]() Tags: [advanced-300](), [agents](), [ai](), [amazon-aurora](), [amazon-dynamodb](), [best-practices](), [data](), [latency](), [rag](), [replication]() ### AI overview The article argues that autonomous AI agents need consistent, current data to make reliable decisions. It explains how replication lag can cause stale reads in RAG-based agent systems and points to selecting replication models that match each workload's consistency needs. ### Source excerpt As AI agents move from chatbots to taking action, their reliability depends on the consistency of the data layer beneath them. This post examines how replication lag poisons an agent's context and shows how to match Amazon Aurora, Amazon DynamoDB, and Amazon Keyspaces replication models to each task's consistency requirements. ## Amazon Aurora DSQL observability concepts and usage with Amazon CloudWatch DevFeed: [Amazon Aurora DSQL observability concepts and usage with Amazon CloudWatch]() Original publisher: [Read original article]() Author: James Morle Published: 2026-08-17T23:37:48Z Content type: article Language: en Sources: [AWS Database Blog]() Topics: [DSQL](), [telemetry]() Tags: [amazon](), [amazon-aurora](), [amazon-cloudwatch](), [cost](), [dash](), [database](), [diagnostics](), [dsql](), [insights](), [intermediate-200](), [metrics](), [monitoring](), [mysql](), [observability](), [performance](), [postgresql](), [sql](), [technical-how-to]() ### AI overview This article explains Amazon Aurora DSQL's time-based observability model and its link to performance and DPU-based cost. It introduces DASH session sampling and using Amazon CloudWatch Database Insights, PromQL, and system diagnostics to identify bottlenecks. ### Source excerpt Amazon Aurora DSQL offers time-based observability through Amazon CloudWatch Database Insights. Learn how the DSQL observability model, DASH, Database Insights, PromQL, and the system diagnostics AI skill help you find performance bottlenecks and connect session time directly to cost. ## 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 ## Amazon is investing in the Lean Focused Research Organization DevFeed: [Amazon is investing in the Lean Focused Research Organization]() Original publisher: [Read original article]() Author: Byron Cook; Shawn Bice Published: 2026-07-26T08:00:00Z Content type: news Language: en Sources: [Amazon Science homepage]() Topics: [AI Bots](), [AI Chat]() Tags: [agents](), [ai-agents](), [amazon](), [amazon-aurora](), [amazon-bedrock](), [amazon-bedrock-agentcore](), [amazon-web-services-aws](), [automated-reasoning](), [aws](), [developer](), [formal-verification](), [generative-ai](), [large-language-models-llms](), [llm](), [programming](), [programming-language](), [research](), [responsible-ai](), [safety](), [software-testing](), [testing](), [trustworthy-ai]() ### AI overview Amazon is making a long-term investment in the Lean Focused Research Organization to advance Lean, a programming language for mathematical correctness proofs. The article highlights Lean-based verification for safer AI agents and AWS systems. ### Source excerpt As AI agents take on higher-stakes decisions, Lean programming language makes it possible to mathematically prove they will behave safely. ## AWS Weekly Roundup: AWS Builder Center at 1 year, Network Scanning in Security Hub, Loom for AWS, and more (July 13, 2026) DevFeed: [AWS Weekly Roundup: AWS Builder Center at 1 year, Network Scanning in Security Hub, Loom for AWS, and more (July 13, 2026)]() Original publisher: [Read original article]() Author: Esra Kayabali Published: 2026-07-13T16:18:20Z Content type: news Language: en Sources: [AWS News Blog]() Topics: [Amazon Web Services](), [Security]() Tags: [agents](), [amazon-aurora](), [amazon-elastic-container-service](), [amazon-elastic-kubernetes-service](), [amazon-sagemaker](), [announcements](), [aws](), [aws-security-hub](), [community](), [ecosystem](), [github](), [hub](), [launch](), [linux](), [mcp](), [news](), [platform](), [sandbox](), [security](), [spaces](), [week-in-review](), [workshops]() ### AI overview AWS Weekly Roundup highlights the first anniversary of AWS Builder Center, including its expansion into sandbox environments, workshops, Spaces, community features, and the Builders' Library. It also covers the launch of Network Scanning in AWS Security Hub, which probes resources from the public internet to identify actual reachability, alongside other weekly AWS announcements. ### Source excerpt AWS Builder Center turned one year old last week. Launched on July 9, 2025, the platform has grown from a community hub with Wishlist voting, community profiles, and a toolbox into a full ecosystem with sandbox environments, workshops, Spaces, and a Builders' Library. To mark the anniversary, Rick Suttles published a full feature timeline covering [...] ## 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. ## Keycloak Performance Benchmarks: A Deep Dive into Scaling and Sizing (26.4) DevFeed: [Keycloak Performance Benchmarks: A Deep Dive into Scaling and Sizing (26.4)]() Original publisher: [Read original article]() Author: Pedro Ruivo Published: 2025-10-01T00:00:00Z Content type: article Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [Benchmark](), [Availability](), [Databases](), [PostgreSQL](), [Amazon Web Services]() Tags: [amazon-aurora](), [availability](), [aws](), [benchmarks](), [idm](), [kerberos](), [keycloak](), [ldap](), [openid-connect](), [openshift](), [performance](), [postgresql](), [saml](), [sso]() ### AI overview This article presents Keycloak 26.4 benchmark results covering scaling under increasing login and refresh-token load, resource sizing, high availability, artificial network latency, and caching for database usage. In the tested range, Keycloak scaled almost linearly when scaled vertically. ### Source excerpt When deploying a mission-critical component like Keycloak, performance is a top concern. Questions about resource requirements, high availability, and network latency are crucial for a successful and stable production environment. To provide a clear, data-driven perspective on these topics, we conducted a series of benchmarks on the latest Keycloak version 26.4. In this post, we'll share our findings on how Keycloak scales with increasing load, performs under artificial network latency, and leverages caching to optimize database usage. Share your feedback about this blog post in our forum! Environment OpenShift 4.17 deployed across three availability zones in eu-west-1. Provisioned using Red Hat OpenShift Service on AWS (ROSA), with ROSA HCP. At least one worker node in each availability zone. Amazon Aurora PostgreSQL 17.5 database. Configured for high availability, with a primary DB instance in one availability zone and synchronously replicated readers in the other availability zones. Database populated with 100,000 users. Keycloak Benchmark as the load generator. The benchmark ran on 20 to 50 t4g.small AWS instances in the same region. Scaling Keycloak One of the most common questions when deploying Keycloak is: how many resources do I need? The answer, as you may have guessed, is that it depends on your specific use case. For this test, we scaled only the login and refresh token requests. Based on Keycloak's Concepts for sizing CPU and memory resources documentation, we determined that you need 1 vCPU to handle 15 logins per second and an additional 1 vCPU to handle 120 refresh token requests per second. After computing the total number of vCPUs required, we divided the value by the desired number of Pods, which was three in this case (one for each availability zone). We allocated slightly more vCPU to each Pod than the calculated value to account for JVM background tasks like compilations and garbage collection. Because our test used a constant load, we did not ## How We Migrated Millions of UGC Records to Aurora MySQL DevFeed: [How We Migrated Millions of UGC Records to Aurora MySQL]() Original publisher: [Read original article]() Author: Kovi Published: 2025-08-25T10:42:12Z Content type: article Language: en Sources: [Bazaarvoice]() Topics: [MySQL](), [DSQL](), [migration](), [Amazon RDS](), [Amazon Web Services](), [Scalability](), [Architecture & Design](), [reliability](), [resiliency]() Tags: [amazon-aurora](), [amazon-rds](), [aws](), [cost](), [database](), [devops](), [efficiency](), [migration](), [mysql](), [mysql-5-7](), [performance](), [reliability]() ### AI overview Bazaarvoice describes migrating millions of user-generated content records from Amazon RDS for MySQL to Amazon Aurora MySQL. The article explains the operational limits, performance and scaling challenges, and a two-phase modernization that first standardized on MySQL 8.0 before the Aurora migration. ### Source excerpt Discover how Bazaarvoice migrated millions of UGC records from RDS MySQL to AWS Aurora - at scale and with minimal user impact. Learn about the technical challenges, strategies, and outcomes that enabled this ambitious transformation in reliability, performance, and cost efficiency Bazaarvoice ingests and serves millions of user-generated content (UGC) items--reviews, ratings, questions, answers, and [...] ## How Zap.xyz Built a Serverless CDC Pipeline with Neon and Inngest DevFeed: [How Zap.xyz Built a Serverless CDC Pipeline with Neon and Inngest]() Original publisher: [Read original article]() Author: Carlota Soto Published: 2025-02-12T13:39:09Z Content type: article Language: en Sources: [Blog -- Neon Docs]() Topics: [data]() Tags: [amazon-aurora](), [amazon-rds](), [architecture](), [aws](), [case-studies](), [data](), [database](), [developer-experience](), [events](), [infra](), [postgres](), [real-time](), [scale](), [serverless](), [streams](), [vercel](), [workflows]() ### AI overview Zap.xyz describes replacing an AWS-based change data capture approach with Neon and Inngest for a serverless pipeline that processes incoming community-channel messages and triggers follow-up workflows. ### Source excerpt "Inngest + Neon handle the entire change data capture process for us. Setting it up took a fraction of the time compared to AWS" (Jacob Devore, Co-Founder at Zap) Zap.xyz is a new crypto aggregation platform that processes millions of messages from community channels like Telegra... ## 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. [Next page]()