Vercel’s AWS Databases marketplace listing is a procurement and IAM shortcut, not a topology guarantee. The 64ms benchmark Vercel quotes for 50 sequential round trips holds only on the greenfield path, where a Fluid function and an Aurora instance sit in the same AWS region under a Vercel-managed account. The link-existing-account flow that most production teams will reach for can place the database in a separate account and region, reintroducing the cross-cloud hop the benchmark is meant to erase.
What does the Vercel Marketplace AWS integration actually provision?
The listing provisions an AWS-managed database and wires IAM-based authentication into your Vercel project, but it relocates nothing and colocates nothing. Per the Jun 4, 2026 AWS announcement, the marketplace now offers Aurora PostgreSQL, Aurora DSQL, and DynamoDB across 17 AWS regions (16 for DSQL), with new AWS accounts created through Vercel receiving $100 in credits valid for six months. The marketplace page also lists OpenSearch Serverless, and all four databases carry Free and Paid plans with 1,000+ installs reported.
The auth model is the part worth pausing on. The integration uses Vercel OIDC to assume an AWS role and mint IAM auth tokens on each connection, so there are no stored database passwords, and credentials are auto-injected as environment variables when a resource is connected to a project. That is a real operational improvement over secret rotation. What the listing does not do is move the database closer to your function, change the region it lives in, or pool connections across function instances. It is a procurement and credential surface, layered on whatever topology you already have.
When does Vercel’s 64ms “same data center” benchmark actually hold?
Vercel’s headline number, 50 sequential round trips averaging 64ms on Aurora, is vendor framing rather than a benchmark under burst, and it only holds on the create-new-account path. The launch post reports 50 sequential round trips averaging 64ms on AWS RDS (Aurora), roughly 1ms per trip, against 109ms for an unnamed Provider B (~2ms) and 150ms for Provider C (~3ms). The explanation offered is that “Vercel runs on AWS infrastructure” and “your functions and your database are in the same data centers.” That framing is doing two things, and both deserve scrutiny.
First, the workload is sequential round trips, which measures per-trip network latency and tells you nothing about concurrent connection establishment. It does not model what happens when three hundred cold-started functions all open a connection in the same second. Second, the “same data centers” claim is true on only one of the two provisioning paths.
The marketplace exposes two paths: “Create new (Vercel-managed account)” for greenfield teams, and “Link an existing AWS account” using AWS IAM temporary delegation. On the first path the function and database can both land in a Vercel-managed AWS account in the same region, and the benchmark’s premise holds. On the second path, which is where any team with an existing RDS footprint lands, you attach a database that already lives in a customer-owned AWS account. Nothing in that flow forces the database’s region to match your Fluid function’s region, and nothing prevents it from sitting in a different AWS account entirely.
How does Fluid Compute change the connection-pool story?
Fluid Compute lets multiple invocations share a single function instance with persistent global state, so a connection pool initialized at global scope survives across requests, which is the lifecycle fix Vercel ships as attachDatabasePool. Under classic serverless, each invocation tends to open its own connection, and a function that suspends loses the pool it built. Fluid Compute inverts that, and Vercel’s attachDatabasePool helper from @vercel/functions wraps the lifecycle with a waitUntil that closes idle connections before the instance suspends. That is the fix for the “phantom” connection leaks that have plagued serverless database access for years.
Vercel’s pooling guidance is specific: set a low idle timeout around 5 seconds, keep the minimum pool size at 1, and avoid a max pool size of 1, because it “does not reduce total connections and harms concurrency in Fluid Compute,” with rolling releases recommended to avoid a stampede of new instances connecting at once.
The helper is narrower than it sounds. It manages pooling for a fixed client set, PostgreSQL (pg), MySQL2, MariaDB, MongoDB, Redis via ioredis, and Cassandra, and it does not multiplex connections across function instances. The reuse is within a single instance, full stop.
Why does burst traffic still exhaust RDS connections under Fluid?
Fluid pooling reuses connections within one instance but not across instances, so a burst of cold-started functions still opens one connection per instance and lands on RDS’s max_connections ceiling. The arithmetic is the same one that has made serverless-to-RDS a known footgun for years. Establishing a database connection costs 50-100ms in TCP handshake, auth, and resource allocation, and each fresh function instance pays it. Relational databases impose hard ceilings: PostgreSQL max_connections runs around 170 on a db.t3.medium and roughly 1,200 on a db.r6g.xlarge, while AWS Lambda can burst from zero to 3,000 concurrent executions. The per-connection setup overhead, TLS handshake plus auth plus session setup, runs 20-50ms per connection.
Fluid helps on the steady-state side, because a warm instance reuses its pool across many invocations instead of reconnecting each time. Fluid does not help on the burst side, because every instance that cold-starts during a traffic spike opens its own connection before its pool warms. Three hundred concurrent instances opening one connection each is three hundred connections, and on a small RDS instance that is already past the ceiling. Procurement got easier; the max_connections ceiling did not move.
What does RDS Proxy do that Fluid pooling does not?
RDS Proxy multiplexes many client connections onto a small warm backend pool, roughly 1,000 Lambda clients onto 50 database connections, which is cross-client consolidation that Fluid’s per-instance pooling cannot provide. AWS RDS Proxy sits between the application and the database and pools client connections onto a shared warm backend set; in practice around 1,000 Lambda clients can share roughly 50 backend connections, a 20:1 ratio. Terraform defaults commonly used for it include max_connections_percent=90, connection_borrow_timeout=120, and session_pinning_filters=['EXCLUDE_VARIABLE_SETS'].
The distinction that matters: Fluid’s attachDatabasePool reuses connections inside one function instance, while RDS Proxy multiplexes connections across all clients of the database. They are not substitutes. Fluid reduces how often a given instance reconnects; RDS Proxy reduces how many backend connections the sum of all instances demands. For bursty serverless traffic against a relational database, the second property is the one that protects the max_connections ceiling.
| Property | Fluid attachDatabasePool | AWS RDS Proxy |
|---|---|---|
| Where it sits | Inside the function instance | Between app and database |
| Scope of reuse | Per-instance, across invocations | Cross-client, across all instances |
| Consolidation ratio | 1:1 within the instance | ~20:1 (1,000 clients onto ~50 backends) |
| What it absorbs | Reconnection cost on warm instances | Burst-driven total connection count |
| What it does not absorb | Cross-instance burst onto the DB | Nothing in the pool tier |
What should you check before clicking “Connect resource”?
Before attaching a database, confirm which provisioning path you are on and verify the database region matches your Fluid function region, because the marketplace UI surfaces neither. The checks that actually change your runtime profile:
- Which path are you on? “Create new (Vercel-managed account)” lets the function and database share a region, and the 64ms benchmark’s premise is in play. “Link an existing AWS account” attaches topology you already own, and Vercel’s latency claims do not transfer.
- Do the regions match? A Fluid function in one AWS region talking to an RDS instance in another pays a cross-region round trip on every query, and the marketplace does not warn about the mismatch.
- Is the database in a different AWS account? Cross-account traffic crosses an additional boundary. The IAM delegation makes auth work but does not collapse the network path.
- What is your client type?
attachDatabasePoolcoverspg, MySQL2, MariaDB, MongoDB, Redis viaioredis, and Cassandra. Aurora DSQL, the serverless HTTP-API variant of PostgreSQL, has a different pooling profile than Aurora PostgreSQL overpgand may not be covered the same way. - Do you need RDS Proxy in front? If the workload bursts, Fluid pooling alone will not hold the
max_connectionsceiling. Put RDS Proxy between the functions and the database, and let Fluid handle per-instance reuse. - Are you eligible for the $100 credit? It is new-AWS-account only, created via Vercel, valid for six months. Existing accounts get the integration, not the credit.
Procurement convenience is now decoupled from runtime topology
The marketplace listing makes the IAM, credential, and billing surface trivial and leaves the latency and pooling topology entirely on the buyer. Before this integration, the fact that your database lived in a different account or region from your functions was a procurement problem you solved consciously: you stood up the database, you wired IAM, you managed credentials. Now that friction is gone, and with it the prompt to think about topology. A team can click “Connect resource,” see credentials auto-injected, read the greenfield benchmark in the launch post, and ship, without noticing their linked RDS instance is two regions away from the Fluid functions hitting it.
The convenience is real, and the OIDC auth model is a genuine improvement over stored passwords. The greenfield benchmark is fair for what it measures. The cross-cloud latency tax and the per-instance pooling gap are still the buyer’s to discover, usually under load.
Frequently Asked Questions
How does Aurora DSQL differ from Aurora PostgreSQL for connection pooling?
Aurora DSQL is the serverless, HTTP-API variant in the listing, and the attachDatabasePool helper’s supported client list (pg, MySQL2, MariaDB, MongoDB, Redis via ioredis, Cassandra) does not include DSQL’s HTTP client. Teams adopting DSQL through the marketplace do not get the per-instance pool lifecycle Vercel ships for pg.
Was the link-existing-account flow available at the original December 2025 launch?
The original December 2025 changelog listed ‘provision into existing AWS account’ as ‘coming soon.’ The June 4, 2026 update is what moved the integration toward the link-existing-account path that production teams with existing RDS footprints now use, alongside the region expansion to 17 for Aurora PostgreSQL and DynamoDB and 16 for DSQL.
What does the EXCLUDE_VARIABLE_SETS pinning filter actually do in RDS Proxy?
This filter tells RDS Proxy it can reuse a backend connection for a different client even after the current client issued SET statements, which is what lets the 20:1 multiplexing ratio hold. Without it, any app that sets session variables pins its backend connection and collapses the ratio toward 1:1.
What carries the network traffic when RDS sits in a different AWS account?
Cross-account database access in AWS typically requires VPC peering, a Transit Gateway, or AWS PrivateLink to expose the database’s network to the function’s account. The IAM temporary delegation that the marketplace sets up handles authentication but does not provision the network path, so teams still need to stand up the VPC connectivity themselves or connection attempts time out at the network boundary.
What does connection_borrow_timeout=120 mean under Lambda burst traffic?
The two-minute borrow timeout means a Lambda function waiting on a pooled connection will almost always hit its own execution ceiling first, since Lambda defaults to a three-second timeout and most serverless functions run shorter than 120 seconds. Under burst pressure, the proxy queues rather than rejects, but the caller has typically already timed out.
