Serverless applications with Aurora DSQL as a database of choice- AWS Community Day DACH 2025

Serverless applications with Aurora DSQL as a database of choice

Vadym Kazulkin
ip.labs GmbH Bonn, Germany
Co-Organizer of the Java User Group Bonn
v.kazulkin@gmail.com
@VKazulkin
https://dev.to/vkazulkin
https://github.com/Vadym79/
https://de.slideshare.net/VadymKazulkin/
https://www.linkedin.com/in/vadymkazulkin
https://www.iplabs.de/
Contact

Image: burst.shopify.com/photos/a-look-across-the-landscape-with-view-of-the-sea
About ip.labs

Agenda
▪ Why we need another (Serverless) database?
▪ Introducing Aurora DSQL
▪ Architecture of Aurora DSQL
▪ How to create single and multi-region clusters in Aurora DSQL
▪ Authentication and authorization in Aurora DSQL
▪ Code examples of how to connect Aurora DSQL from Lambda
▪ Performance measurements of CRUD operations in Aurora DSQL
▪ Pricing of Aurora DSQL
▪ Currently unsupported features and constraints in Aurora DSQL
▪ How to talk to Aurora DSQL MCP Server via Strands SDK

Why we need another (Serverless)
database?

Current AWS Database Offerings NoSQL And Relational For
The Serverless Workloads
DynamoDB RDS Aurora Aurora
Serverless v2

Strengths and weaknesses of these
Amazon databases when using in the
Serverless architectures (especially
connecting from AWS Lambda)

DynamoDB
Completely Serverless
▪ Doesn’t generally** require infrastructure management (VPC, security
groups, subnets)
▪ Scales down to zero (including pay as use go pricing)
NoSQL databases require investment in knowledge
Limited strong consistency and transaction support
Challenging to change the table design / query patterns
afterwards
** requires putting Lambda into VPC when using DAX for caching

RDS
Requires a lot of infrastructure management (VPC, security
groups, subnets)
No auto-scaling out of the box for compute and storage
No per pay use pricing
Issues with database connection management (requires RDS
Proxy)

Aurora (Provisioned)
Storage scales automatically
Requires a lot of infrastructure management (VPC, security
groups, subnets)
No auto-scaling out of the box for compute
No per pay use pricing
Issues with database connection management (requires
Amazon RDS Proxy service)

Aurora Serverless v2
Compute and storage scale automatically (also down to zero)
Doesn’t generally** require infrastructure management (VPC,
security groups, subnets)
When auto-scaling, it doubles the capacity (ACU)
Can scale down to zero but when it is slow to scale up
Issues with database connection management (requires
Amazon RDS Proxy service or Amazon RDS Data API)
** requires putting Lambda into VPC when using RDS Proxy

Can’t we have AWS database offering
which is as Serverless as DynamoDB but
provides the benefits (like ACID) of the
relational databases?

https://aws.amazon.com/rds/aurora/dsql/?nc1=h_ls
Introducing Aurora DSQL

https://docs.aws.amazon.com/aurora-dsql/latest/userguide/what-is-aurora-dsql.html
What Is Aurora DSQL?
▪ Aurora DSQL is a serverless, distributed relational database
service optimized for transactional workloads
▪ Aurora DSQL offers virtually unlimited scale and doesn't require
you to manage infrastructure
▪ The active-active highly available architecture provides 99.99%
single-Region and 99.999% multi-Region availability
▪ Strongly consistent at any scale and in multi-region configuration

https://docs.aws.amazon.com/aurora-dsql/latest/userguide/what-is-aurora-dsql.html
When To Use Aurora DSQL?
▪ Aurora DSQL is optimized for transactional workloads that benefit
from ACID transactions and a relational data model.
▪ Because it's serverless, Aurora DSQL is ideal for application
patterns of microservice, serverless, and event-driven
architectures.
▪ Aurora DSQL is PostgreSQL-compatible, so you can use familiar
drivers, object-relational mappings (ORMs), frameworks, SQL
features and tools (like PSQL and DBeaver).

https://brooker.co.za/blog/2024/12/05/inside-dsql-writes.html
Architecture of Aurora DSQL

https://aws.amazon.com/blogs/database/introducing-amazon-aurora-dsql/
Single-Region Aurora DSQL Cluster
Highly available architecture
provides 99.99% single-Region
availability.

Multi-Region Aurora DSQL Cluster
Active-active highly available
architecture provides 99.999%
multi-Region availability.

• Aurora DSQL creates another
cluster in a different Region and
links them together.
• Adding linked Regions makes sure
that all changes from committed
transactions are replicated to the
other linked Regions.
• Each linked cluster has a Regional
endpoint, and Aurora DSQL
synchronously replicates writes
across Regions, enabling strongly
consistent reads and writes from
any linked cluster.

• A third Region acts as the witness
Region.
• The witness Region receives the
data written to linked clusters but
doesn’t have a cluster or an
associated endpoint.
• It stores a limited window of
encrypted transaction logs (in
Journal), which Aurora DSQL uses
to provide multi-Region durability
and availability.

https://brooker.co.za/blog/2024/12/05/inside-dsql-writes.html
Aurora DSQL Optimistic Concurrency Control (OCC)
▪ OCC is a concurrency control method that assumes conflicts between
transactions are rare and avoids using locks to manage access to data.
▪ Instead, it allows transactions to proceed without locking, and checks for
conflicts only at the time of commit.
▪ Snapshot isolation used in Aurora DSQL (equivalent to PostgreSQL’s
REPEATABLE READ) is a form of OCC that provides each transaction with a
consistent snapshot of the database at the time the transaction started.
▪ If a conflict is detected the transaction is rolled back and retried.
▪ At snapshot isolation level, OCC aborts will only occur when two or more
concurrent transactions attempt to write the same keys.

https://brooker.co.za/blog/2024/12/04/inside-dsql.html https://marc-bowes.com/dsql-scales-to-zero.html
Query Processor
• Each DSQL query processor (QP)
is an independent unit, that never
communicates with other QPs.
• Each QP is a PostgreSQL process
running inside a Firecracker
microVM.
• When you connect to DSQL,
DSQL will assign a separate QP to
that connection.
• QPs are used multiple times (for
the same DSQL database), but
only handle one transaction at a
time.

https://brooker.co.za/blog/2024/12/04/inside-dsql.html https://marc-bowes.com/dsql-circle-of-life.html
Aurora DSQL Reads
• Reads in DSQL are done using a
multiversion concurrency control
(MVCC), allowing them to scale
out across many replicas of many
storage shards, and across a
scalable SQL layer, with no
contention or coordination
between other readers and
writers.
• Reads are always local.

Aurora DSQL Writes
• The writes proceed in a similar
way: executing the
INSERT/UPDATE/DELETE simply
writes down a planned change
locally inside the Query Processor
(QP) that’s running this
transaction.
• No replication, durability, or writes
to storage have occurred yet.

Aurora DSQL Writes
When executing COMMIT:
• Check whether our isolation rules
will allow it to be committed
• Make the results of the
transaction durable the D and
atomically the A in ACID.
• Replicate the transaction to all
AZs and regions where it needs to
be visible to future transactions.

https://aws.amazon.com/blogs/compute/its-about-time-microsecond-accurate-clocks-on-amazon-ec2-instances/
Aurora DSQL Writes
• We pick a start time for our
transaction at begin transaction.
• We pick a commit time for our
transaction at commit transaction.
• Time comes from EC2 Time Sync.
• We need to know if, for every key
this transaction wants to write,
any other transaction wrote the
same key between start and
commit time.
• Task of looking for conflicts is
implemented in a service called
Adjudicator.

Aurora DSQL Writes
• Once the Adjudicator confirms a
transaction, it gets written on the
Journal for replication.
• Journal is an internal AWS
component optimized for ordered
data replication across hosts, AZs,
and regions. Journal provides an
ordered stream of time and data.
• At this point, the transaction is
committed: it’s durable, it’s put in
order, all consistency and
isolation checks have passed, and
it can no longer be rejected.

Aurora DSQL Writes
• Journal (replicated transaction
log) starts applying the results of
the transaction to all the relevant
storage replicas (making new
versions of rows as they come in).
• As Journal provides an ordered
stream of time and data, the
storage knows whether all journal
data has been replicated yet.
• Storage follows the journal and
keeps (by checking the state each
millisecond) itself up to date.

https://brooker.co.za/blog/2024/12/04/inside-dsql.html
Aurora DSQL Components Scalability
• Query Processor, Adjudicator,
Journal and Storage are
independently horizontally
scalable, most of them are
shared-nothing components.
• This approach is enabled by the
extremely fast and reliable
networking available in modern
data centers.

https://brooker.co.za/blog/2024/12/04/inside-dsql.html
Aurora DSQL Components
• AWS built their own connection
and transaction handling and
storage.
• AWS re-used the SQL engine,
query planner and optimizer from
PostgreSQL.

hhttps://brooker.co.za/blog/2024/12/04/inside-dsql.html
Aurora DSQL What About the Cache?
• Due to the changed interface
between the SQL executor and
storage, there is no need for a
large local cache right next to the
SQL engine.
• This cache is crucial for instance-
based databases (RDS, Aurora).
• AWS built a new scalable SQL
execution layer which can
dynamically scale to meet the
needs of nearly any workload.

hhttps://brooker.co.za/blog/2024/12/04/inside-dsql.html
Aurora DSQL What About the Cache?
• The QP doesn’t ask for pages, it
asks for rows.
• Knowing the logical structure of
the data it holds allows DSQL’s
storage to offer quite a high-level
interface to the QP: the QP can
ask storage to do work like
filtering, aggregation, projection,
and other common tasks on its
behalf.

• Independent clusters (Query
Processor, Adjudicator, Storage)
are completely separated.
• Only journal (replicated
transaction log) is shared
between the clusters and the
witness region.

https://docs.aws.amazon.com/aurora-dsql/latest/userguide/disaster-recovery-resiliency.html
Aurora DSQL Resilience Aspects
▪ Backup and restore
▪ Supports backup and restore with AWS Backup console. You can perform a
full backup and restore for your single-Region and multi-Region clusters.
▪ AWS Fault Injection Service (FIS) supports the following Aurora DSQL
action:
▪ aws:dsql:cluster-connection-failure
▪ Creates controlled connection failures in an Aurora DSQL cluster for a
specified duration to test application resilience.

How to create single and multi-region
clusters in Aurora DSQL

Clusters | Aurora DSQL | us-east-1
How To Create A Single-Region Aurora DSQL Cluster

Authentication and authorization in
Aurora DSQL

https://marc-bowes.com/dsql-auth.html
Authentication In Aurora DSQL
▪ In DSQL, there are no passwords
▪ Tokens are used to authenticate who is trying to connect instead
▪ Authentication tokens are generated by the AWS SDK using fast, local
cryptography and sent over the wire to DSQL (similar to S3 and DynamoDB
requests)
▪ AWS Signature v.4 algorithm is a set of operations that involve Hash-based
Message Authentication Code (HMAC)
▪ There are 2 APIs for the tokens which are named:
▪ DbConnectAdmin
▪ DbConnect

AWS CLI request:
aws dsql generate-db-connect-admin-auth-token --hostname cluster-endpoint --
expires-in 10
AWS CLI response:
cluster-endpoint/?Action=DbConnectAdmin&X-Amz-Algorithm=AWS4-HMAC-
SHA256&X-Amz-Credential=xxxx&X-Amz-Date=20250516T003940Z&X-Amz-
Expires=60&X-Amz-SignedHeaders=host&X-Amz-Signature=xxxx

export PGPASSWORD=$(aws dsql generate-db-connect-admin-auth-token --
hostname $cluster_endpoint)
psql –quiet --username admin --dbname postgres --host $cluster_endpoint

Authorization In Aurora DSQL
▪ After verifying a token, DSQL will evaluate the calling identity’s
attached IAM Policies to ensure they have access to the cluster
and that the database administrator has authorized that identity
to login

https://github.com/Vadym79/AWSLambdaJavaWithAmazonDSQL/tree/main/sample-app-with-pgjdbc
Code examples of how to connect Aurora
DSQL from Lambda

https://github.com/Vadym79/AWSLambdaJavaWithAmazonDSQL/blob/main/sample-app-with-pgjdbc
CREATE TABLE orders (id int PRIMARY KEY, user_id int
NOT NULL, total_value int NOT NULL, status varchar
(255) NOT NULL, created timestamp );
CREATE TABLE order_items (id int PRIMARY KEY,
product_id int NOT NULL, order_id int NOT NULL,
value int NOT NULL, quantity int NOT NULL);
CREATE INDEX ASYNC order_created_idx ON orders
(created);
CREATE INDEX ASYNC order_items_order_id_idx ON
order_items (order_id);
Sample Application

https://github.com/Vadym79/AWSLambdaJavaWithAmazonDSQL/blob/main/sample-app-with-pgjdbc
Data model is oversimplified:
• we have only orders and order_items tables
• orders table has user_id column, but no
users table is present
• order_items table has product_id column,
but no product table is present
Sample Application

https://github.com/Vadym79/AWSLambdaJavaWithAmazonDSQL/blob/main/sample-app-with-pgjdbc/template.yaml
Infrastructure As Code With AWS SAM

https://github.com/Vadym79/AWSLambdaJavaWithAmazonDSQL/blob/main/sample-app-with-pgjdbc/pom.xml
Required Dependencies (DSQL, Hikari Pool, PostgreSQL Driver)

https://github.com/Vadym79/AWSLambdaJavaWithAmazonDSQL/blob/main/sample-app-with-pgjdbc/src/main/java/software/amazonaws/example/order/dao/DsqlDataSourceConfig.java
Configuration Of The Hikari Data Source Pool In Java

https://github.com/awslabs/aurora-dsql-jdbc-connector
Aurora DSQL JDBC Connector
▪ Automatic Token Generation
▪ IAM tokens are generated automatically using AWS credentials
▪ Seamless Integration
▪ Works with existing JDBC connection patterns and with connection pooling
libraries such as HikariCP
▪ The connector handles IAM token generation during connection establishment,
allowing connection pools to operate normally
▪ AWS Credentials Support
▪ Supports various AWS credential providers (default, profile-based, etc.)

https://github.com/Vadym79/AWSLambdaJavaWithAmazonDSQL/blob/main/sample-app-with-aurora-dsql-jdbc-connector/pom.xml
Required Dependencies for Aurora DSQL JDBC Connector

https://github.com/Vadym79/AWSLambdaJavaWithAmazonDSQL/blob/main/sample-app-with-aurora-dsql-jdbc-connector/src/main/java/software/amazonaws/example/order/dao/DsqlDataSourceConfig.java
Configuration Of The Hikari Data Source Pool In Java with
Aurora DSQL JDBC Connector

https://github.com/Vadym79/AWSLambdaJavaWithAmazonDSQL/blob/main/sample-app-with-pgjdbc/src/main/java/software/amazonaws/example/order/dao/OrderDao.java
Implementation Of The Order DAO

https://docs.aws.amazon.com/aurora-dsql/latest/userguide/aws-sdks.html
ORM-Framework (Object-Relational Mapping) Support
▪ Hibernate
▪ SQLAlchemy
▪ Django

Performance measurements of CRUD
operations in Aurora DSQL

https://www.postgresql.org/docs/current/pgbench.html https://wiki.postgresql.org/wiki/TPC-H https://marc-bowes.com/dsql-tpcb.html
▪ Measure the Lambda function performance of each concrete
scenario
▪ Lambda functions written in Java with managed Java 21 runtime connecting
to Aurora DSQL clusters (latency)
▪ Focus only on the measuring Lambda warm start times
▪ Up to 99% percentile, ignoring highly programming language (Java)
dependent 99,9% and max values
▪ Perform the measurements for single-region and multi-region DSQL cluster
Goals Of The Aurora DSQL Performance Measurements

Goals Of The Aurora DSQL Performance Measurements
▪ Different scenarios include:
▪ CREATE an order with multiple (2) order items (in one transaction)
▪ SELECT one order by primary key (id) and then SELECT order items for this order
using the index
▪ SELECT multiple orders created in the specific date range using the index and
then SELECT order items for each of this order using the index
▪ Take into the account the overhead of the programming language (Java),
database driver (JDBC) and database connection pooling framework (Hikari)

▪ Compare the performance of Aurora DSQL database with other
Amazon databases
▪ Aurora DSQL vs RDS vs Aurora vs Aurora Serverless v2
▪ Measure the Aurora DSQL database performance itself using:
▪ pgbench (TPC-B)
▪ TPC-C/H benchmarks
Not Goals Of The Aurora DSQL Performance Measurements

Not Goals Of The Aurora DSQL Performance Measurements
▪ Measure performance with stress test
▪ Performance at scale
▪ Performance when scaling (adding more storage, QPs, adjudicators)
▪ Measure and optimize Lambda cold and warm start times with
Java
▪ AWS Lambda SnapStart usage with priming techniques

70
▪ Use Managed Amazon Corretto Java 21
Lambda runtime
▪ Use pure JDBC and no ORM framework
(for example Hibernate) on top
▪ Lambda has 1024 MB memory setting
▪ Lambda uses x86 architecture
▪ No Lambda SnapStart enabled
▪ Info about the experiments:
▪ Approx. 1 hour duration
▪ Approx. first > 5.000 warm starts
Sample Application Settings

0,00
10,00
20,00
30,00
40,00
50,00
60,00
single-region cluster multi-region cluster
p50 p75 p90 p99
Create 1 order with 2 order items (3 inserts in total) in the
same transaction
ms

0,00
2,00
4,00
6,00
8,00
10,00
12,00
14,00
16,00
18,00
20,00
cluster
p50 p75 p90 p99
Get order by id and then get its 2 items (2 selects)
ms

0,00
50,00
100,00
150,00
200,00
250,00
300,00
350,00
cluster
p50 p75 p90 p99
Get orders by created date range (limited by 100 orders)
and then get 2 items for each order (101 selects)
ms

163,00
164,00
165,00
166,00
167,00
168,00
169,00
170,00
single-region cluster multi-region cluster
value
Average cold start of the database after 3 days of inactivity
ms

https://aws.amazon.com/rds/aurora/dsql/?nc1=h_ls https://marc-bowes.com/dsql-how-to-spend-a-dollar.html
Pricing of Aurora DSQL

https://aws.amazon.com/rds/aurora/dsql/pricing/
Pricing Of Aurora DSQL
Dimension Description Pricin
DPU DPU as a measure of how much work the system does
to run your SQL workload. This includes compute
resources used to execute query logic (e.g., joins,
functions, aggregations) as well as the input/output (I/O)
required to read from and write to storage
From $8.00 per
1M Units
Storage Storage is billed based on the total size of your
database, measured in GB-month.
From $0.33 per
GB-month
Others • Data transfer cost
• Backup and restore costs
• Free tier first 100.000 DPUs and 1 GB of
storage are free
See
https://aws.amaz
on.com/rds/auror
a/dsql/pricing/

Pricing CloudWatch Metrics For Aurora DSQL

https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-postgresql-compatibility.html https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-postgresql-compatibility-unsupported-features.html
Currently unsupported features and
constraints in Aurora DSQL

Quota Description Value Adjustable
Maximum
connections
Maximum number of connections
per cluster
10.000
Maximum transaction
time
Maximum duration of the
transaction
5 minutes
Maximum connection
duration
Maximum duration after which the
connection will be closed
60 minutes
Maximum number of
rows changed in
transaction
Maximum number of table and
index rows that can be mutated in a
transaction block
3.000
Maximum size
modified in a
transaction
Maximum size of all data modified
in a write transaction
10 MiB
Aurora DSQL Important Service Quotas
https://docs.aws.amazon.com/aurora-dsql/latest/userguide/CHAP_quotas.html

https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-postgresql-compatibility-supported-data-types.html
Unsupported Data Types In Aurora DSQL
▪ JSON
▪ JSONB

https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-postgresql-compatibility-unsupported-features.html https://marc-bowes.com/dsql-avoid-hot-keys.html
Unsupported Objects In Aurora DSQL
▪ Columns with default values
▪ Temporary Tables
▪ Triggers
▪ Sequences
▪ You can use time-based UUIDv7 instead
▪ Partitions
▪ Functions written in languages other than SQL

https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-postgresql-compatibility-unsupported-features.html
Unsupported Constraints and Commands In Aurora DSQL
▪ Commands
▪ Foreign keys
▪ Constraints
▪ TRUNCATE
▪ VACUUM
▪ Aurora DSQL doesn't require vacuuming. The system maintains statistics
and manages storage optimization automatically without manual vacuum
commands.

https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-postgresql-compatibility-unsupported-features.html
Unsupported Extensions In Aurora DSQL
▪ PGVector
▪ PGAudit
▪ pg_stat_statements

Final thoughts and wrap up

AWS Innovations powering Aurora DSQL
EC2 Time Sync
▪ Microsecond precision
Firecracker microVM
▪ Supports snapshot and restore, where it writes down all the VM memory,
registers, and device state into a file
▪ Boot microVM with QP, start the (PostgreSQL) database, start the
management and observability agents, load all the metadata and then take a
snapshot
▪ Need a new QP? Create a new VM from the snapshot which is very fast
https://brooker.co.za/blog/2025/09/18/firecracker.html

Progamming Language Used In Aurora DSQL
https://www.allthingsdistributed.com/2025/05/just-make-it-scale-an-aurora-dsql-story.html
DSQL is written in Rust:
• Ideal for performance-critical systems
• Memory safety
• No Garbage Collector and no GC
pauses
• Less security bugs possible -> aligns
with Amazon goals with security as a
top priority
• Plays well together with Firecracker
also written in Rust

Aurora DSQL Architectural Decisions and Trade-Offs
Using QP in Firecracker microVM and not having a larga-scale
cache right next to the SQL engine enable:
▪ Very fast start up times
▪ No database cold start time
▪ Ability to grow and shrink the CPU and memory use of VMs in place
▪ Easy to clean up resource (VMs terminates after a fixed period of
time of 60 minutes)

Aurora DSQL Architectural Decisions and Trade-Offs
▪ Maximum transaction time no longer than 5 minutes enables:
▪ Less work for Adjudicator to look for conflicts during commit and
therefore stable query performance for multi-Region writes
▪ Easier MVCC garbage collection by discarding older references
▪ Maximum number of rows changed in transaction equal to 3000
enables:
▪ Stable query performance with only one flush of memory buffer

General Advices How To Achive Best DSQL Performance
Create many connections (QPs)
Prefer small rows and small transactions
Consider using separate DSQL cluster for each microservice
Use Explain Analyze as a profiling tool
Use client-side database connection pooling
Avoid hot keys (read-modify-writes)
Avoid large rows and columns
Avoid big Selects/Deletes

Aurora DSQL Wrap Up
Easy to setup and get started
No infrastructure management
Multi-region setup right from be beginning
ACID support, especially no eventually consistency at any scale for
single and multi-region cluster
High availability

Topic DynamoDB RDS Aurora Aurora Serverless v2 Aurora DSQL
Setup experience
(Auto-)scaling
experience
ACID support
No need for server-
side connection
pooling solutions
Familiar database
drivers and ORM
frameworks support for RDS Data API
DynamoDB vs RDS vs Aurora vs Aurora Serverless v2 vs Aurora DSQL

DynamoDB vs RDS vs Aurora vs Aurora Serverless v2
vs Aurora DSQL
Other comparison criteria:
▪ Performance
▪ I haven‘t done such comparison which isn‘t easy between relational and
NoSQL databases
▪ Total cost or better Total Cost of Ownership
▪ Units (RCU/WCU, ACU, DCU) and their meaning are totally different for all
these databases
▪ Consider all environments (live, testing, staging, individual) to calculate cost
▪ Consider amount of manual work (maintain IaC scripts, setup) to be done

DynamoDB vs RDS vs Aurora vs Aurora Serverless v2
vs Aurora DSQL
Other comparison criteria:
▪ Multi-Region support

Aurora DSQL Challenges
Feature gap to be (100%) PostgreSQL compatible is currently quite big
▪ Could be a challenge to start with DSQL right now
▪ Could be a much bigger challenge to migrate to DSQL
Service Quotas (a bit) restrictive for the relational database users
▪ Max transaction time, max number of rows changed in one transaction
Price estimation is challenging
▪ DPU not easy to predict
▪ ComputeDPU is not very compatible with the Serverless pricing

https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-postgresql-compatibility.html https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-postgresql-compatibility-unsupported-features.html
How to talk to Aurora DSQL MCP Server
via Strands SDK

https://awslabs.github.io/mcp/servers/aurora-dsql-mcp-server/
Aurora DSQL MCP Server
Features overview:
▪ Converting human-readable questions and commands into
structured Postgres-compatible SQL queries and executing them
against the configured Aurora DSQL database.
▪ Read-only by default, transactions enabled with --allow-writes
▪ Connection reuse between requests for improved performance

https://strandsagents.com/latest/#
Strands Agents SDK
Strands Agents is a Python SDK that takes a model-driven approach to
building and running AI agents.
Features overview:
▪ Lightweight & Flexible: Simple agent loop that just works and is fully
customizable
▪ Model Agnostic: Support for Amazon Bedrock, Anthropic, LiteLLM,
Llama, Ollama, OpenAI, Writer, and custom providers
▪ Advanced Capabilities: Multi-agent systems, autonomous agents, and
streaming support
▪ Built-in MCP: Native support for Model Context Protocol (MCP) servers,
enabling access to thousands of pre-built tools

https://github.com/strands-agents/samples/tree/main/03-integrations/aurora-DSQL
Strands Agents With Aurora DSQL

Strands Agent With Aurora DSQL

Strands Agents With Aurora DSQL- Get Order By ID

Strands Agents with Aurora DSQL- Get Order By ID

Strands Agent With Aurora DSQL- Single Order Users

Strands Agents With Aurora DSQL- Single Order Users

Ask Me Anything Please leave your feedback
108 Serverless applications with Aurora DSQL as a database of choice

Serverless applications with Aurora DSQL as a database of choice- AWS Community Day DACH 2025

More Related Content

Similar to Serverless applications with Aurora DSQL as a database of choice- AWS Community Day DACH 2025

More from Vadym Kazulkin

Recently uploaded

Serverless applications with Aurora DSQL as a database of choice- AWS Community Day DACH 2025