Category: Best Practices

In this post, we show you how to use EXPLAIN plans to diagnose and improve query performance in Amazon Aurora DSQL. We introduce a three-layer filter model as a practical framework for understanding where your predicates are evaluated, and walk through the architecture differences that make Aurora DSQL plans unique, the anatomy of an EXPLAIN output, access method selection, and a step-by-step query improvement workflow.

In this post, you learn three pagination techniques for Aurora DSQL: OFFSET/LIMIT, cursor-based (keyset), and temporal. You implement keyset pagination in SQL and Python, build it into an API layer, optimize with composite indexes, handle batch processing within the 3,000-row transaction limit, and avoid five common anti-patterns. By the end, you can choose the right pagination method for your workload and implement it with confidence.

In Part 1, Part 2, and Part 3 of this series, we explored PostgreSQL’s native indexes (B-tree, GIN, GiST, HASH, BRIN) and specialized extension-based index types (SP-GiST, btree_gin, btree_gist). In this post, we dive into three additional extensions: Bloom (for space-efficient multi-column equality filtering), pg_trgm (for fuzzy text matching and similarity searches), and pg_bigm (for full-text search optimized for Asian languages)

In this post, the third in the series, we dive into three extension-based index types: SP-GiST, btree_gin, and btree_gist. These are available in Amazon Aurora PostgreSQL-Compatible Edition and Amazon Relational Database Service (Amazon RDS) for PostgreSQL. PostgreSQL’s index infrastructure is extensible. Operator classes define how indexes behave for specific data types and operations. The SP-GiST, btree_gin, and btree_gist extensions take advantage of this extensibility to give you additional indexing strategies beyond the native options. We walk through when to use each extension, the data types they support, and practical examples that demonstrate their performance benefits.

By implementing modern optimization techniques for Aurora, you can achieve additional cost reduction beyond traditional methods alone. This isn’t only about spending less—it’s about building a more efficient, scalable, and resilient database environment. In this post, we show you a structured approach to optimizing Amazon Aurora database costs. It outlines specific strategies, implementation steps, and best practices across different optimization areas.

In this post, we help you plan your upgrade from PostgreSQL version 13 before standard support ends on February 28, 2026. We discuss the key benefits of upgrading, breaking changes to consider, and multiple upgrade strategies to choose from.

Efficient storage management is crucial for maintaining the performance, reliability, and cost-effectiveness of your Oracle databases running on Amazon RDS. As your data grows and your workloads evolve, it’s essential to proactively monitor and optimize your storage utilization. In this post, we explore various techniques and best practices for effectively managing storage in RDS for Oracle Databases.

In this post, we show you how to use additional storage volumes to expand your RDS for Oracle storage capacity beyond 64 TiB. In addition, we walk through use cases for additional storage volume and best practices while working with additional volumes.

Part 1 of this series showed how to rate-limit calls to Amazon DynamoDB by using Python Boto3 event hooks. In this post, I expand on the concept and show how to rate-limit calls in a distributed environment, where you want a maximum allowed rate across the full set of clients but can’t use direct client-to-client communication.

In this post, I present a technique where a Python script making calls to Amazon DynamoDB can rate limit its consumption of read and write capacity units. The technique uses Boto3 event hooks to apply the rate limiting without having to modify the client code performing the read and write calls.