How One Developer Cut Aurora DSQL Costs by 8x — Without a DBA

Self-service query optimization for the serverless era

The Old Way

You’re a developer. Your app is slow. The database is the bottleneck. What happens next?

1. File a ticket with the DBA team
2. Wait for someone to analyze your queries
3. Wait for index changes to be scheduled
4. Wait for the maintenance window
5. Hope it works

This cycle can take days or weeks. And when traffic grows, you do it all over again.

The DSQL Way

Aurora DSQL changes this. Here’s a real story from our community. A developer had an async metrics query that was expensive. They ran one command:

EXPLAIN ANALYZE VERBOSE SELECT metric_name, value FROM metrics 
WHERE app_id = 'xyz';

The output showed the query was reading entire rows — including wide columns they didn’t need — just to return two fields.

The fix? A covering index:

CREATE INDEX ASYNC idx_metrics_covering ON metrics (app_id) 
INCLUDE (metric_name, value);

Result: 8x reduction in DPU costs. No ticket. No DBA. No waiting.

Why This Works on DSQL

You Pay for What You Read

DSQL charges based on Database Processing Units (DPUs). When your query reads data, you pay for the bytes scanned.

Wide rows with large columns? You pay for all of it — even if you only SELECT one field.

Covering indexes store the columns you need right in the index. The query never touches the main table.

EXPLAIN ANALYZE VERBOSE Shows You Everything

This isn’t a black box. DSQL gives you detailed query plans:

EXPLAIN ANALYZE VERBOSE SELECT …

You’ll see:

• Which indexes are used (or not)
• How many rows are scanned
• Where time is spent
• DPU cost breakdown

This is the same information a DBA would use — now in your hands.

No Infrastructure to Tune

Traditional databases have dozens of knobs: buffer pools, connection limits, replica lag, vacuum settings. Tuning them requires specialized knowledge.

DSQL eliminates this. As the AWS blog series “Everything you don’t need to know about Amazon Aurora DSQL” explains, the architecture is “fully abstracted from the user.” You interact with a single endpoint — DSQL handles everything else.

What you don’t need to manage:

• Buffer pools or memory allocation
• Read replicas or failover
• Vacuum or maintenance windows
• Connection poolers or proxies
• Sharding or partitioning

Each connection gets its own dedicated Query Processor (QP) running in an isolated Firecracker microVM. Slow queries from one user don’t affect others. The compute, storage, and transaction layers scale independently — all behind the scenes.

You focus on your queries. DSQL handles the rest.

Step-by-Step: Optimize Your Own Queries

Step 1: Find Your Slow Queries

Start with queries that run frequently or process lots of data.

EXPLAIN ANALYZE VERBOSE
SELECT order_id, status FROM orders WHERE customer_id = 'abc123';

Step 2: Read the Plan

Look for:

• Seq Scan — scanning the whole table (usually bad for large tables)
• Index Scan — using an index (good)
• Index Only Scan — using a covering index (best)

Step 3: Add Covering Indexes

If you see Index Scan but not Index Only Scan, you can often improve performance:

-- Before: Index on customer_id, but still reads from table
CREATE INDEX ASYNC idx_orders_customer ON orders (customer_id);

-- After: Covering index includes the columns you SELECT
CREATE INDEX ASYNC idx_orders_customer_covering 
ON orders (customer_id) INCLUDE (order_id, status);

Step 4: Verify the Improvement

Run EXPLAIN ANALYZE VERBOSE again. You should see:

• “Index Only Scan” instead of “Index Scan”
• Lower execution time
• Reduced DPU usage

Common Patterns

Pattern 1: Lookup by ID, Return Few Columns

-- Query
SELECT name, email FROM users WHERE user_id = ?;

-- Covering index
CREATE INDEX ASYNC idx_users_lookup ON users (user_id) INCLUDE (name, email);

Pattern 2: Filter and Aggregate

-- Query
SELECT COUNT(*), status FROM orders WHERE created_at > '2025-01-01' GROUP BY status;

-- Covering index
CREATE INDEX ASYNC idx_orders_status ON orders (created_at) INCLUDE (status);

Pattern 3: Join Optimization

-- Query
SELECT o.order_id, c.name 
FROM orders o 
JOIN customers c ON o.customer_id = c.customer_id 
WHERE o.status = 'pending';

-- Covering indexes on both sides
CREATE INDEX ASYNC idx_orders_pending ON orders (status) INCLUDE (order_id, customer_id);
CREATE INDEX ASYNC idx_customers_lookup ON customers (customer_id) INCLUDE (name);

Mental Model: Think Like DynamoDB GSIs

If you’ve used DynamoDB, covering indexes work like Global Secondary Indexes (GSIs):

• DynamoDB GSI partition key → PostgreSQL index column
• DynamoDB projected attributes → PostgreSQL INCLUDE columns
• Query without table fetch → Index Only Scan

The concept is the same: store the data you need where you query it.

What About ORMs?

ORMs generate SQL. That SQL runs on DSQL. The optimization process is identical:

1. Find slow queries in your ORM logs

2. Run EXPLAIN ANALYZE VERBOSE on the generated SQL

3. Add covering indexes for frequently-run queries

4. Your ORM benefits automatically

The Bigger Picture

DSQL is designed for developers who want to move fast without waiting on specialists.

Traditional Database:

• DBA tunes queries
• DBA manages replicas
• DBA configures connections
• Maintenance windows required
• Capacity planning needed

Aurora DSQL:

• You tune queries
• Automatic scaling
• Built-in connection handling
• Zero-downtime maintenance
• Pay for what you use

This isn’t about eliminating DBAs — it’s about removing bottlenecks. When you can optimize your own queries in minutes instead of days, everyone ships faster.

Try It Yourself

1. Pick a query that runs often
2. Run EXPLAIN ANALYZE VERBOSE on it
3. Look for opportunities to add covering indexes
4. Measure the before and after

You might be surprised how much you can improve — without filing a single ticket.

Resources

Aurora DSQL Documentation: https://docs.aws.amazon.com/aurora-dsql/latest/userguide/

“Everything you don’t need to know about Aurora DSQL” blog series:

• Part 1 — Setting the scene: https://aws.amazon.com/blogs/database/everything-you-dont-need-to-know-about-amazon-aurora-dsql-part-1-setting-the-scene/
• Part 2 — Shallow view (architecture): https://aws.amazon.com/blogs/database/everything-you-dont-need-to-know-about-amazon-aurora-dsql-part-2-shallow-view/

ORM Adapters: https://github.com/awslabs/aurora-dsql-orms

DSQL Starter Kit: https://github.com/awslabs/aurora-dsql-starter-kit

Have a query optimization win to share? Join the Aurora DSQL Discord community.