Drizzle: Cannot destructure property 'resourceArn' fix

TL;DR#

drizzle-kit studio or drizzle-kit migrate with driver: 'aws-data-api' throws Cannot destructure property 'resourceArn' of 'connection' as it is undefined even when dbCredentials is correct. drizzle-kit builds its own RDSDataClient and hands it to drizzle-orm, and drizzle-orm 0.35.0 to 0.40.1 identifies a client with instanceof RDSDataClient. The client drizzle-kit creates comes from its own bundled copy of the AWS SDK, so the check fails and drizzle-orm looks for a connection key that was never passed. Upgrade drizzle-orm to 0.41.0 or later: the maintainer closed the issue with "should be fixed in drizzle-orm@0.41.0", and its release notes list it. In your own code on current drizzle-orm (0.45.4 in the reproduction), the same message means drizzle() got the three keys at the top level: put them inside connection.

The error, as drizzle-kit prints it before any request leaves for AWS:

TypeError: Cannot destructure property 'resourceArn' of 'connection' as it is undefined.

The report is drizzle-orm issue #3224, moved from the drizzle-kit mirror repository. The first reporter hit it running Drizzle Studio against PostgreSQL through the AWS Data API. The second hit it on npx drizzle-kit migrate with a config that set a non-empty value for each of database, resourceArn and secretArn. The stack trace points at aws-data-api/pg driver.ts, inside drizzle-orm, called from preparePostgresDB in drizzle-kit's bin.cjs.

Why drizzle-orm rejects the client drizzle-kit made#

drizzle-kit does not pass your dbCredentials to drizzle() as one object. In the drizzle-kit source (connections.ts), the aws-data-api branch creates a client, then calls the two-argument form:

const rdsClient = new RDSDataClient();
const db = drizzle(rdsClient, config);

drizzle() in drizzle-orm has to tell the two-argument form apart from the one-argument forms. This check, and the connection destructuring after it, first appear in the drizzle-orm 0.35.0 driver.ts; the 0.34.1 file has neither. In drizzle-orm 0.40.1 (driver.ts) it does that with one test, and everything that fails it falls through to the connection branch:

if (params[0] instanceof RDSDataClient) {
  return construct(params[0] as TClient, params[1] as DrizzleAwsDataApiPgConfig<TSchema>) as any;
}
 
if ((params[0] as { client?: TClient }).client) {
  // ...
}
 
const { connection, ...drizzleConfig } = params[0] as {
  connection: RDSDataClientConfig & Omit<DrizzleAwsDataApiPgConfig, keyof DrizzleConfig>;
} & DrizzleConfig<TSchema>;
const { resourceArn, database, secretArn, ...rdsConfig } = connection;

instanceof is true only if the object was built by that exact class. The RDSDataClient that drizzle-kit uses is not the one in your node_modules. drizzle-kit is shipped as a single bundled file, and the AWS SDK client is inside it. In the reproduction below, drizzle-kit 0.30.5 carried its own copy of @aws-sdk/client-rds-data at version 3.583.0, while drizzle-orm imported the 3.1156.0 copy installed next to it:

$ grep -o "client-rds-data@[0-9.]*" node_modules/drizzle-kit/bin.cjs | sort -u
client-rds-data@3.583.0
$ grep -n "if (params\[0\] instanceof RDSDataClient" node_modules/drizzle-orm/aws-data-api/pg/driver.js
76:  if (params[0] instanceof RDSDataClient) {

Two copies mean two distinct classes, so the check returns false. The client has no client property either, so drizzle-orm reads connection from the client object, gets undefined, and destructuring resourceArn out of it throws. In the drizzle-kit 0.30.5 bundle, Studio, migrate, push and pull all build their database through the same preparePostgresDB function, which is why the issue was first seen in Studio and then on migrate.

The fix is a looser test. Comparing the 0.40.1 and 0.41.0 sources, that line is the only change in the file: from 0.41.0 on, any first argument that is not a plain object also counts as a client. The 0.41.0 release notes list "Fixed drizzle-studio + AWS Data Api connection issue" with a link to #3224, and the fix landed through pull request #4293, which names #3224 among the issues it fixes.

Your dbCredentials are not the problem#

Because the message names resourceArn, the first instinct is to check the spelling in drizzle.config.ts. That is not what produces this TypeError. In the reproduction on drizzle-kit 0.31.11, a config with clusterArn in place of resourceArn never reaches drizzle-orm: drizzle-kit validates the config first and says so plainly.

$ npx drizzle-kit migrate --config=misnamed.config.ts
Error  Please provide required params for AWS Data API driver:
    [✓] database: 'appdb'
    [✓] secretArn: '*****'
    [x] resourceArn: undefined

If you see that list, fix the key it marks with [x]. If you see the TypeError, your keys passed validation and the failure is the version check described above.

Fix#

1. Check which drizzle-orm your project resolves. A lockfile can keep an old version even when package.json allows a newer one.

   bash

   npm ls drizzle-orm drizzle-kit @aws-sdk/client-rds-data

2. Upgrade drizzle-orm to 0.41.0 or later. drizzle-kit can stay where it is for this error: the check that throws is in drizzle-orm.

   bash

   npm install drizzle-orm@latest

3. If the error comes from your own code rather than from drizzle-kit, look at how you call drizzle(). With a single argument, the Drizzle AWS Data API Postgres docs put database, secretArn and resourceArn inside connection:

   ts

   import { drizzle } from 'drizzle-orm/aws-data-api/pg';
    
   const db = drizzle({
     connection: {
       database: process.env.DATABASE!,
       secretArn: process.env.SECRET_ARN!,
       resourceArn: process.env.RESOURCE_ARN!,
       region: 'eu-west-2',
     },
   });

   Or, if you already create an RDSDataClient, pass it as client with the three keys beside it, as the same docs page shows:

   ts

   import { drizzle } from 'drizzle-orm/aws-data-api/pg';
   import { RDSDataClient } from '@aws-sdk/client-rds-data';
    
   const rdsClient = new RDSDataClient({ region: 'eu-west-2' });
    
   const db = drizzle({
     client: rdsClient,
     database: process.env.DATABASE!,
     secretArn: process.env.SECRET_ARN!,
     resourceArn: process.env.RESOURCE_ARN!,
   });

   On current drizzle-orm, the flat form without either wrapper still throws the exact message from this page. In the reproduction, drizzle-orm 0.45.4 failed on drizzle({ database, secretArn, resourceArn }):

   text

     const { resourceArn, database, secretArn, ...rdsConfig } = connection;
             ^
   TypeError: Cannot destructure property 'resourceArn' of 'connection' as it is undefined.

   Moving the same three values into connection was the only change, and drizzle() returned a database object (created function in the log).

Verify the fix#

After the upgrade, the guard in the installed drizzle-orm should carry the second condition:

grep -n "if (params\[0\] instanceof RDSDataClient" node_modules/drizzle-orm/aws-data-api/pg/driver.js

76:  if (params[0] instanceof RDSDataClient || params[0].constructor.name !== "Object") {

Then run the command that failed. With drizzle-kit 0.30.5 and drizzle-orm 0.41.0, drizzle-kit migrate no longer stopped at drizzle(): it printed the applying migrations... spinner, which means it had built the database object and was sending its first statement. What happens next depends on the AWS SDK version in your project, and that is the next section.

After the upgrade: serializerMiddleware is not found#

With a recent @aws-sdk/client-rds-data installed, the first query can fail with a second error. This is how drizzle-kit 0.30.5 with drizzle-orm 0.41.0 printed it in the reproduction:

[⣷] applying migrations...Error: serializerMiddleware is not found when adding endpointV2Middleware middleware before serializerMiddleware

The same message is the subject of drizzle-orm issue #5050, reported on drizzle-orm 0.44.7 and drizzle-kit 0.31.7, where it appears as the cause of a DrizzleQueryError on the statement CREATE SCHEMA IF NOT EXISTS "drizzle".

It comes from the same bundle. drizzle-kit sends the query through its bundled client, but the command object is built by drizzle-orm from the SDK in your node_modules, and the two disagree on the middleware stack. A commenter on the issue traced it to drizzle-kit's build not treating @aws-sdk/client-rds-data as external. The reporter of #5050 downgraded the SDK to 3.873.0 to get migrations working again. It reproduced here on both lines: drizzle-kit 0.30.5 with drizzle-orm 0.41.0 printed the middleware error in full, and drizzle-kit 0.31.11 with drizzle-orm 0.45.4 and SDK 3.1156.0 failed on the same query. On 0.31.11 that cause was read from a copy of bin.cjs patched to print the error it catches, because the CLI itself does not show it.

On drizzle-kit 0.31.11 the failure is harder to see. With output captured, as in CI, the run printed the spinner and exited with code 1, with no error text:

[⣷] applying migrations...[⣷] applying migrations...
exit=1

That silent exit is the behaviour described in Fix drizzle-kit migrate Hanging After Using 'pg' Driver, where a failed migrate on recent 0.31 releases prints only the spinner line. Three ways out, each tested to the point where the SDK asked for AWS credentials:

1. Run the migrations from your own code. drizzle-kit generate writes the SQL files without connecting to the database. You can then apply them with drizzle-orm's Data API migrator. drizzle-orm creates the client from your node_modules, so there is only one SDK copy. One commenter on #3224 used this approach, with a different migrator import, while the bug was open. On drizzle-orm 0.45.4 with SDK 3.1156.0, this script reached the credentials step with no pin:

   ts

   // migrate.mjs
   import { drizzle } from 'drizzle-orm/aws-data-api/pg';
   import { migrate } from 'drizzle-orm/aws-data-api/pg/migrator';
    
   const db = drizzle({
     connection: {
       database: process.env.DB_NAME,
       secretArn: process.env.DB_SECRET_ARN,
       resourceArn: process.env.DB_CLUSTER_ARN,
       region: 'eu-west-2',
     },
   });
    
   try {
     await migrate(db, { migrationsFolder: './drizzle' });
     console.log('migrations applied');
   } catch (err) {
     console.error(err.message);
     console.error('cause:', err.cause?.name, err.cause?.message);
     process.exit(1);
   }

   It also prints the real cause of a failure, which drizzle-kit 0.31.11 hides.

2. Pin the SDK to the version drizzle-kit bundles. Find that version in your own install, since it differs between drizzle-kit releases (3.583.0 in 0.30.5, 3.817.0 in 0.31.11):

   bash

   grep -o "client-rds-data@[0-9.]*" node_modules/drizzle-kit/bin.cjs | sort -u

   Installing that exact version moved the failure in the reproduction from the middleware error to CredentialsProviderError, as read through the same patched copy: the unmodified 0.31.11 CLI printed the spinner and exit code 1 in both cases, so without real AWS credentials you will not see the difference from the CLI alone. The cost is that your application then runs on that older SDK too, and a commenter on #5050 points out that older releases pull in a fast-xml-parser with a known vulnerability. Treat the pin as temporary.

3. Move to the drizzle-kit release candidate. A Drizzle collaborator closed #5050 on 21 October 2026 with "Fixed in 1.0.0-rc.5. Use drizzle-kit@rc.", and the v1.0.0-rc.5 release notes list the issue. With drizzle-kit and drizzle-orm 1.0.0-rc.5 and SDK 3.1156.0, migrate reached the credentials step. It first refused the migrations folder written by drizzle-kit 0.30.5:

   text

   Your migrations folder format is outdated, please run drizzle-kit up

   drizzle-kit up rewrites that folder, so commit it before you run it. This is a pre-release with a new major version, so read the release notes before you move a production project onto it.

Where the reproduction stops#

The failing and fixed runs were reproduced on 22 October 2026 with Node.js 26.7.0 on Windows, one scratch project per version set. They used a placeholder cluster ARN in eu-west-2 and no AWS credentials on the machine, so every successful path ended at the AWS SDK:

CredentialsProviderError: Could not load credentials from any providers

That line is the boundary. Both TypeErrors in this article are thrown locally, before any request is signed, and the middleware error happens while the request is being built. What lies beyond is AWS configuration, which this reproduction could not exercise. AWS states that to use the Data API you must enable it for your Aurora DB cluster, and Authorizing access to the Amazon RDS Data API states that "Users can invoke Amazon RDS Data API (Data API) operations only if they are authorized to do so." An error at that stage comes from AWS, not from Drizzle.

If you upgraded drizzle-orm for this error, you also picked up the fix for db.query dropping the pgSchema name, which shipped in the same 0.41.0 release. If drizzle-kit generate itself stops with Cannot find module './users.js' in a nodenext project, that is a separate loader problem, covered in drizzle-kit generate: Cannot find module .js under nodenext. For the resourceArn TypeError, the order is: confirm drizzle-orm is at least 0.41.0, then make sure your own drizzle() call wraps its keys in connection. If migrate then goes quiet with exit code 1, check which SDK copy drizzle-kit bundles before you suspect the database.

Further reading: drizzle-seed reset() fails on drizzle-orm beta/rc: fix.