Between Our Application and Aurora DSQL
In my previous article, Going Passwordless with Aurora DSQL, I explored how Aurora DSQL authenticates applications without a stored database password.
But authentication is only part of the connection story.
When looking at how our application would connect, several familiar names came up: JDBC, connection pools, PgBouncer, RDS Proxy and the Data API.
They all relate to database access. But they solve different problems.
Start with a familiar application
Consider a Spring Boot or Node.js application connecting to PostgreSQL.
Before introducing DSQL, it helps to understand the components between our application code and the database.
The driver
A driver is a library inside the application that communicates using the database protocol. It opens connections, sends SQL statements and receives results.
For Java, that could be the PostgreSQL JDBC driver. For Node.js, it could be pg, also known as node-postgres.
The application pool
Opening a connection takes work. Instead of opening a new one for every query, an application can maintain a pool of reusable connections.
A Spring Boot application commonly uses HikariCP. A Node.js application using pg can use pg.Pool.
The pool manages connections; the driver handles database communication. Both operate inside the application process. Spring Boot SQL documentation, node-postgres pooling
What can sit outside the application?
PgBouncer
PgBouncer is a separate PostgreSQL connection pooler.
The application still needs a driver. That driver connects to PgBouncer, which manages connections to PostgreSQL.
PgBouncer supports different pooling modes, including session and transaction pooling. The selected mode matters because some session features do not work the same way with transaction pooling. It is also another component to configure and operate. PgBouncer documentation
RDS Proxy
RDS Proxy provides AWS-managed connection pooling and proxying for supported RDS and Aurora databases.
The application connects through its driver to the proxy. The proxy manages the underlying database connections and can help applications handle connection surges and database failovers. RDS Proxy documentation
Get Anuradha Ranasinghe’s stories in your inbox
Join Medium for free to get updates from this writer.
Aurora DSQL is not listed among its supported database targets. PostgreSQL compatibility alone does not make a database a supported RDS Proxy target. RDS Proxy engine support
RDS Data API
The RDS Data API takes a different approach.
The application sends SQL through an HTTP endpoint, using an AWS SDK or API calls. It does not need to manage a persistent PostgreSQL connection itself. Data API documentation
Its documented database support covers Aurora PostgreSQL and Aurora MySQL, rather than Aurora DSQL. Data API supported databases
These are conceptual paths. An application-side pool can also be used with an external pooler or proxy; the diagrams separate their responsibilities.
The approach we are choosing for DSQL
For our Node.js application, we are choosing application-side pooling with the Aurora DSQL connector for node-postgres.
The responsibilities are:
- The pool manages reusable connections.
- The
pgdriver communicates using PostgreSQL’s protocol. - The DSQL connector handles IAM token generation when establishing connections.
The connector builds on familiar node-postgres client and pool interfaces. It is an application library, rather than an external proxy service. DSQL Node.js connector
Java applications have a similar option: the DSQL JDBC connector works with the PostgreSQL JDBC driver and connection pools such as HikariCP. DSQL JDBC connector
This gives us a starting point without adding an external pooler to our initial design.
What changes when it runs in Lambda?
Connection reuse still matters.
AWS recommends initializing database connections outside the handler so subsequent invocations in the same execution environment can reuse them. Connections can still become stale or close, so the application needs to handle that lifecycle. Lambda best practices
Each execution environment has its own pool.
A pool maximum of three therefore does not limit the entire application to three connections. As Lambda scales across environments, the potential connection count grows too.
We need to size and test the pool against our actual workload.
DSQL also supports a public connection endpoint, so Lambda does not need attachment to our VPC solely to reach it. Where private connectivity is required, AWS PrivateLink provides an interface endpoint inside our VPC. DSQL PrivateLink documentation
Our chosen direction is a PostgreSQL driver, the DSQL connector and application-side pooling. Connection reuse, pool sizing and failure handling are the next things to validate.
This article reflects documentation reviewed on 1 November 2026. Refer to the linked sources for current support and behaviour.
What makes you introduce an external pooler or proxy instead of starting with an application-side pool?
