packages/core/test/integration/json.test.ts-21-23 (1)

21-23: Reconsider adding DuckDB to dialectSupportsJsonEquality.

According to DuckDB's official documentation, JSON equality comparisons have inconsistent behavior—they sometimes compare raw text (whitespace/formatting matters) and sometimes compare logical JSON content. The docs explicitly warn about this caveat with examples showing differing behavior.

This inconsistency contradicts the assumption made by the dialectSupportsJsonEquality constant, which gates tests that rely on consistent JSON-to-JSON comparison. The test at line 122 (should be able to compare JSON to JSON directly) assumes reliable equality semantics, which DuckDB does not guarantee.

Either:

1. Verify with the DuckDB dialect maintainers that this behavior is acceptable/resolved, or
2. Remove DuckDB from this list and gate the test on a more specific check, or
3. Document the known limitations if DuckDB's inconsistency is acceptable for Sequelize's use case.

packages/duckdb/src/_internal/data-types-overrides.ts-86-99 (1)

86-99: Fix parseDatabaseValue typing—parameter should be unknown, not BigInt.

The current signature value: BigInt is incorrect (BigInt is a constructor). More importantly, @duckdb/node-api may return different types for BIGINT columns—string, number, or bigint—as evidenced by the comment in query.js: "BigInt binds as null in duckdb-node, convert to string". The parameter should accept unknown and handle all possible driver return types defensively, matching the pattern used in Postgres BIGINT and the JSON class in this same file.

 export class BIGINT extends BaseTypes.BIGINT {
   protected _checkOptionSupport(dialect: AbstractDialect) {
     super._checkOptionSupport(dialect);
   }

   toSql(): string {
     return 'BIGINT';
   }

   parseDatabaseValue(value: unknown): unknown {
     // Sequelize expects bigint to be represented as string
+    if (typeof value === 'bigint') {
+      return value.toString();
+    }
+
+    if (typeof value === 'number') {
+      return String(value);
+    }
+
+    if (typeof value === 'string') {
+      return value;
+    }
+
+    // fallback (covers boxed BigInt or other driver-specific representations)
+    return (value as { toString?: () => string } | null)?.toString?.() ?? value;
   }
 }

packages/core/test/integration/index.test.ts-180-185 (1)

180-185: Fix overly-permissive error regexes (\s|^...$ matches almost anything).
As written, any message containing whitespace will satisfy the assertion.

-            expect(error.message).to.match(
-              /\s|^Cannot use duplicate column names in index. Column name 'username' listed more than once.$/,
-            );
+            expect(error.message).to.match(
+              /^\s*Cannot use duplicate column names in index\. Column name 'username' listed more than once\.\s*$/,
+            );

-            expect(error.message).to.match(
-              /\s|^Column name 'email' does not exist in the target table or view.$/,
-            );
+            expect(error.message).to.match(
+              /^\s*Column name 'email' does not exist in the target table or view\.\s*$/,
+            );

-            expect(error.message).to.match(
-              /\s|^Column 'username' in table 'users' is of a type that is invalid for use as a key column in an index.$/,
-            );
+            expect(error.message).to.match(
+              /^\s*Column 'username' in table 'users' is of a type that is invalid for use as a key column in an index\.\s*$/,
+            );

Also applies to: 211-216, 242-247

packages/core/test/integration/index.test.ts-219-237 (1)

219-237: “invalid column type” test also references missing email include column (may fail for the wrong reason).
If the intent is to test key-column type validation, make the include list valid (or add email to the model) so the failure is attributable to username being TEXT.

         sequelize.define(
           'user',
           {
             username: DataTypes.TEXT,
             first_name: DataTypes.STRING,
             last_name: DataTypes.STRING,
+            email: DataTypes.STRING,
           },
           {
             indexes: [
               {
                 name: 'user_username',
                 fields: ['username'],
-                include: ['first_name', 'last_name', 'email'],
+                include: ['first_name', 'last_name', 'email'],
                 unique: true,
               },
             ],
           },
         );

packages/core/test/integration/model/bulk-create.test.js-499-520 (1)

499-520: “Should throw” ignoreDuplicates test can pass without asserting (missing failure on success).
If bulkCreate doesn’t throw, the test currently succeeds.

       } else {
         it('should throw an error when the ignoreDuplicates option is passed', async function () {
           const data = [
             { uniqueName: 'Peter', secretValue: '42' },
             { uniqueName: 'Paul', secretValue: '23' },
           ];

           await this.User.bulkCreate(data, { fields: ['uniqueName', 'secretValue'] });
           data.push({ uniqueName: 'Michael', secretValue: '26' });

-          try {
-            await this.User.bulkCreate(data, {
-              fields: ['uniqueName', 'secretValue'],
-              ignoreDuplicates: true,
-            });
-          } catch (error) {
-            expect(error.message).to.equal(
-              `${dialectName} does not support the ignoreDuplicates option.`,
-            );
-          }
+          await expect(
+            this.User.bulkCreate(data, {
+              fields: ['uniqueName', 'secretValue'],
+              ignoreDuplicates: true,
+            }),
+          ).to.be.rejectedWith(`${dialectName} does not support the ignoreDuplicates option.`);
         });
       }

packages/core/test/integration/model/bulk-create.test.js-523-555 (1)

523-555: Gate primary key upsert tests by dialect.supports.constraints.primaryKey.

Three tests using primary keys for conflict detection are not gated by any constraint check:

• "when the primary key column names and model field names are the same" (lines 558–586)
• "when the primary key column names and model field names are different" (lines 587–614)
• "when the composite primary key column names and model field names are different" (lines 616–660)

DuckDB is a concrete example: it supports inserts.updateOnDuplicate but disables constraints.primaryKey due to over-eager constraint checking. These tests will run and fail on such dialects. Wrap them with if (dialect.supports.constraints.primaryKey) to match the gating pattern used for unique constraint tests.

packages/duckdb/src/connection-manager.ts-7-10 (1)

7-10: Remove unused mode parameter and add database validation.

The mode option is defined in the interface but never used in the connect() method. Since @duckdb/node-api's fromCache() doesn't support a mode parameter, either implement full mode support or remove it from the interface. Additionally, validate that config.database is provided before passing it to fromCache().

   async connect(config: ConnectionOptions<DuckDbDialect>): Promise<DuckDbConnection> {
+    if (!config.database) {
+      throw new Error('DuckDB connection requires a non-empty "database" path.');
+    }
+
     const instance = await DuckDBInstanceClass.fromCache(config.database, {
       custom_user_agent: 'sequelize',
     });

Committable suggestion skipped: line range outside the PR's diff.

packages/duckdb/src/query-generator.js-100-109 (1)

100-109: addIndexQuery: escape the comment payload + beware overwriting existing comments.
actualIndexQuery is inserted into a single-quoted string without escaping; a single quote in the generated SQL would break the statement. Also, each index attempt overwrites the table comment (losing previous “no-op index” notes).

Safer quoting:

-    return `COMMENT ON TABLE ${table} IS '${actualIndexQuery}'`;
+    return `COMMENT ON TABLE ${table} IS ${this.escape(actualIndexQuery)}`;

packages/duckdb/src/dialect.ts-28-118 (1)

28-118: PRIMARY KEY flag contradicts actual constraint generation; RETURNING disabled for UPDATE despite "returning" support flag.

The supports flag sets constraints.primaryKey: false but query-generator.js (lines 43-55, 86-88) actively emits PRIMARY KEY (...) table constraints. Either the flag should be true or the constraint generation should be prevented.

Additionally, returnValues: 'returning' doesn't reflect that DuckDB can only use RETURNING with INSERT statements—updateQuery() (lines 111-115) and arithmeticQuery() (lines 137-138) explicitly strip or disable it due to constraint violation issues. The code works correctly as a runtime workaround, but the supports flag should communicate this limitation.

packages/duckdb/src/query-generator.js-11-60 (1)

11-60: createTableQuery: sequence handling has a critical bug with multiple AUTOINCREMENT columns.

• sequence_sql is reassigned on each loop iteration (line 38), so only the last AUTOINCREMENT column's sequence is created. Earlier sequences are discarded, causing the second and subsequent columns' nextval() calls to fail at runtime.
• Line 87 comment says "will be replaced with a PRIMARY KEY comment in createTableQuery," but line 54 emits an actual PRIMARY KEY (...) table constraint, not a comment. The terminology is misleading—update the comment to say "table constraint" instead of "comment."

Fix the sequence accumulation issue:

-    let sequence_sql = '';
+    const sequenceSql: string[] = [];
@@
-        if (dataType.includes('AUTOINCREMENT')) {
-          sequence_sql = `CREATE SEQUENCE IF NOT EXISTS ${this.quoteIdentifier(sequence_name)} START 1; `;
+        if (dataType.includes('AUTOINCREMENT')) {
+          sequenceSql.push(
+            `CREATE SEQUENCE IF NOT EXISTS ${this.quoteIdentifier(sequence_name)} START 1; `,
+          );
           // this could be done in attributesToSQL but better keep it with sequence_name generation in case it changes
           dataType = dataType.replace('AUTOINCREMENT', `DEFAULT nextval('${sequence_name}')`);
         }
@@
-    const sql = `${sequence_sql}CREATE TABLE IF NOT EXISTS ${table} (${attrStr});`;
+    const sql = `${sequenceSql.join('')}CREATE TABLE IF NOT EXISTS ${table} (${attrStr});`;

Also verify that @duckdb/node-api supports multiple SQL statements concatenated in a single string via runAndReadAll().

Also applies to: 62-98

packages/core/test/unit/query-generator/rollback-savepoint-query.test.ts-10-15 (1)

10-15: Misleading test name (“committing” vs rollback)
This test calls rollbackSavepointQuery and expects ROLLBACK...; the it(...) title should reflect rollback to avoid confusion when reading failures.

packages/core/test/unit/query-generator/get-constraint-snippet.test.ts-468-468 (1)

468-468: Fix inconsistent error message.

The error message uses "Unique key constraints" while all other unique constraint tests in this file use "Unique constraints" (lines 341, 357, 371, 381, 393, 407, 421, 435, 449). This inconsistency should be corrected for uniformity.

Apply this diff:

-          duckdb: new Error('Unique key constraints are not supported by duckdb dialect'),
+          duckdb: new Error('Unique constraints are not supported by duckdb dialect'),

packages/core/test/unit/transaction.test.ts-69-69 (1)

69-69: Remove DuckDB from isolation level test expectations.

DuckDB's dialect declares isolationLevels: false at packages/duckdb/src/dialect.ts:100. This means the test transaction at line 73 will throw an error for DuckDB, caught at line 78, and the expectation at line 74 (referencing line 69) will never be evaluated. The expectation at line 69 should be removed to align with the test's error-handling logic and coding guidelines for skipping unsupported behavior.

packages/core/test/unit/query-generator/remove-constraint-query.test.ts-120-120 (1)

120-120: Fix inconsistent dialect ordering.

This line uses 'sqlite3 duckdb' while all other occurrences in this file use 'duckdb sqlite3'. Maintain consistent ordering to avoid potential matching issues and improve readability.

Apply this diff to fix the ordering:

-      'sqlite3 duckdb': notSupportedError,
+      'duckdb sqlite3': notSupportedError,

packages/core/test/integration/error.test.ts-694-695 (1)

694-695: Typo in test description.

"assocated" should be "associated".

-      it('should throw a foreign key constraint error when deleting a parent row that has assocated child rows', async () => {
+      it('should throw a foreign key constraint error when deleting a parent row that has associated child rows', async () => {

packages/core/test/integration/error.test.ts-849-850 (1)

849-850: Typo in test description.

"constranit" should be "constraint".

-        it('should throw an unknown constranit error for duplicate constraint names', async () => {
+        it('should throw an unknown constraint error for duplicate constraint names', async () => {

packages/core/test/unit/data-types/temporal-types.test.ts-29-29 (1)

29-29: Add precision option validation to DuckDB's DATE type.

DuckDB's DATE implementation silently ignores the precision parameter without warning, unlike other unsupported options in the dialect which either implement _checkOptionSupport with a warning (e.g., TEXT) or declare the limitation in dialect.ts (e.g., TIME.precision: false).

Add a _checkOptionSupport method to the DATE class in packages/duckdb/src/_internal/data-types-overrides.ts to warn when precision is provided, or add DATE: { precision: false } to the supports.dataTypes section in packages/duckdb/src/dialect.ts to explicitly declare that DuckDB does not support DATE precision.

packages/core/test/integration/query-interface/remove-column.test.ts-168-236 (1)

168-236: Test name/setup mismatch: “retain ON UPDATE” but the constraint isn’t created with onUpdate.
Either add onUpdate: 'CASCADE' to the constraint creation, or rename the test to only mention ON DELETE / default update behavior.

         await queryInterface.addConstraint('actors', {
           name: 'actors_level_id_fkey',
           type: 'FOREIGN KEY',
           fields: ['level_id'],
           references: { field: 'id', table: 'level' },
           onDelete: 'CASCADE',
+          onUpdate: 'CASCADE',
         });

packages/duckdb/src/_internal/data-types-overrides.ts-171-196 (1)

171-196: Keep the JSON override, but silence the “shadow global JSON” lint locally.
The export name is likely intentional for Sequelize’s datatype override map; suppressing is cleaner than renaming.

-export class JSON extends BaseTypes.JSON {
+// biome-ignore lint/suspicious/noShadowRestrictedNames: Sequelize override type name; use globalThis.JSON explicitly below.
+export class JSON extends BaseTypes.JSON {
   toSql(): string {
     return 'JSON';
   }
@@
 }

packages/core/test/integration/utils.test.ts-12-14 (1)

12-14: Use recursive: true to make directory creation idempotent.

fs.mkdirSync(DUCKDB_DATABASES_DIR) will throw an EEXIST error if the directory already exists (e.g., on test re-runs or if cleanup didn't occur). This could cause spurious test failures.

   if (dialectName === 'duckdb') {
-    fs.mkdirSync(DUCKDB_DATABASES_DIR);
+    fs.mkdirSync(DUCKDB_DATABASES_DIR, { recursive: true });
   }

packages/duckdb/src/dialect.ts-12-20 (1)

12-20: Prefer a type alias over an empty interface (Biome lint).

-export interface DuckDbDialectOptions {}
+export type DuckDbDialectOptions = Record<string, never>;

packages/duckdb/src/query-interface.ts-123-153 (1)

123-153: bulkInsert: typo + replacements handling looks fine, but keep option names consistent with upsert.

• Variable name typo: attrubutesWithCoercedType.
• You delete options.replacements here (plural), but upsert deletes replacement (singular). After fixing upsert, this section is consistent.

-    const attrubutesWithCoercedType = attributes as {
+    const attributesWithCoercedType = attributes as {
       [columnName: string]: NormalizedAttributeOptions;
     };
@@
-      attrubutesWithCoercedType,
+      attributesWithCoercedType,

packages/duckdb/src/query-generator.js-110-139 (1)

110-139: RETURNING removal is brittle—handle multiple clause formats.
The arithmeticQuery method removes only the exact substring RETURNING *. If the base query generator emits RETURNING "id", RETURNING id, or similar variations, this replacement will fail and the problematic RETURNING clause will remain.

Consider using a more flexible pattern:

-    return query.replace('RETURNING *', '');
+    return query.replace(/\s+RETURNING\s+.*$/i, '');

This handles any RETURNING format at the end of the query (case-insensitive). Verify this aligns with how the base arithmeticQuery constructs its output.

packages/core/test/unit/sql/group.test.js (2)

39-45: Confirm combined fixture key 'postgres duckdb' is the intended expectsql convention.

If DuckDB is expected to match Postgres here, this is fine; just be aware that if DuckDB diverges later you’ll likely want a dedicated duckdb entry to avoid coupling expectations. Based on learnings, tests should cleanly express dialect differences.

---

58-64: Same note for empty GROUP BY case: consider separate duckdb fixture if behavior may diverge.

If the goal is “DuckDB matches Postgres” for now, the combined key is OK; otherwise, a dedicated duckdb expectation keeps future edits localized.

packages/core/test/unit/query-generator/rollback-savepoint-query.test.ts (2)

6-18: Potentially lost coverage for “unsupported” dialects due to outer if gate
Gating by dialect.supports.savepoints matches the general pattern, but it also means dialects that should raise notSupportedError (e.g., the explicit snowflake case) won’t execute this test if they report supports.savepoints === false. Consider keeping the suite always-defined and conditionally skipping/asserting inside the test so “unsupported” behavior is still covered. As per coding guidelines / learnings, feature-gating is correct, but ensure it doesn’t hide expected failures.

-if (dialect.supports.savepoints) {
-  describe('QueryGenerator#rollbackSavepointQuery', () => {
+describe('QueryGenerator#rollbackSavepointQuery', () => {
     const queryGenerator = sequelize.queryGenerator;
 
-    it('should generate a query for committing a transaction', () => {
+    it('should generate a query for rolling back to a savepoint', () => {
+      if (!dialect.supports.savepoints) {
+        return;
+      }
       expectsql(() => queryGenerator.rollbackSavepointQuery('mySavepoint'), {
         default: 'ROLLBACK TO SAVEPOINT [mySavepoint]',
         mssql: 'ROLLBACK TRANSACTION [mySavepoint]',
         snowflake: notSupportedError,
       });
     });
-  });
-}
+});

(If you prefer explicit reporting over silent return, use this.skip() with a message.)

---

7-7: Consider using Support.getTestDialectTeaser() in descriptions (if this suite follows that convention)
Coding guidelines mention using Support.getTestDialectTeaser() for dialect-specific test descriptions; even though this test isn’t dialect-specific in name, it’s feature-specific and may benefit from the standardized teaser format used elsewhere in tests.

Also applies to: 10-10

packages/core/test/unit/query-generator/describe-table-query.test.ts (1)

78-83: DuckDB describe query: qualify inner columns + consider deterministic ordering (and verify array_contains)

The correlated subquery reads clearer/safer if duckdb_constraints is aliased and its columns are qualified (today database_oid/schema_oid/table_oid are unqualified). Also consider adding an ORDER BY on a stable column from duckdb_columns() (if available) to avoid any nondeterminism in describeTable output, and please double-check that array_contains is the intended DuckDB function name for the supported version(s).

Example shape (illustrative):

- (select count(*) from duckdb_constraints where col.database_oid = database_oid
-     and col.schema_oid = schema_oid and col.table_oid = table_oid
-     and array_contains(constraint_column_names, col.column_name)
-     and constraint_type='PRIMARY KEY') > 0 as is_primary_key
+ exists (
+   select 1
+   from duckdb_constraints con
+   where col.database_oid = con.database_oid
+     and col.schema_oid = con.schema_oid
+     and col.table_oid = con.table_oid
+     and array_contains(con.constraint_column_names, col.column_name)
+     and con.constraint_type = 'PRIMARY KEY'
+ ) as is_primary_key
+ -- optionally: order by col.<stable_position_column>

Also applies to: 159-165, 241-246, 320-325, 405-410, 488-493

packages/core/test/unit/query-generator/arithmetic-query.test.ts (1)

65-78: Consider adding a duckdb expectation for completeness.

While DuckDB naturally omits RETURNING for UPDATE operations, this test explicitly sets returning: false. For consistency with other tests in this file and to validate DuckDB's identifier quoting (double quotes vs. square brackets in default), consider adding a duckdb entry.

   expectsql(sql, {
     default: `UPDATE [myTable] SET [foo]=[foo]+ 3`,
+    duckdb: `UPDATE "myTable" SET "foo"="foo"+ 3`,
   });

packages/core/test/integration/query-interface/changeColumn.test.js (2)

229-232: Consider removing redundant variable assignment.

The intermediate assignment const firstForeignKeys = keys can be simplified by using keys directly in the assertions below, or by renaming in the destructuring.

-        const keys = await this.queryInterface.showConstraints('users', {
+        const firstForeignKeys = await this.queryInterface.showConstraints('users', {
           constraintType: 'FOREIGN KEY',
         });
-        const firstForeignKeys = keys;

---

255-271: Consider relocating this test outside the FK describe block.

This test verifies column comment functionality rather than foreign key behavior. While it works correctly here (using tables from beforeEach), placing it inside the describe('should support foreign keys', ...) block is semantically misleading.

If relocating would require duplicating table setup, the current placement is acceptable.

packages/core/test/integration/model/sync.test.js (2)

167-168: Consider using a feature flag instead of hardcoded dialect name check.

The guard uses sequelize.dialect.name !== 'duckdb' which is inconsistent with the recommended pattern used elsewhere in this file (e.g., sequelize.dialect.supports.constraints.foreignKey at lines 581 and 653). As per coding guidelines, tests should skip unsupported behavior with dialect.supports.featureName checks.

Consider adding a supports.indexes feature flag in the DuckDB dialect configuration and using it here:

-  // DuckDB dialect does not support indexes
-  if (sequelize.dialect.name !== 'duckdb') {
+  if (sequelize.dialect.supports.indexes) {

This makes the code more maintainable if other dialects also lack index support in the future.

Based on learnings, the pattern should be dialect.supports.featureName checks.

---

439-440: Duplicate dialect name check pattern.

Same concern as the earlier guard at line 168 - this uses a hardcoded dialect name check rather than a feature flag. If a supports.indexes feature flag is added, this guard should also be updated.

Additionally, consider whether these two separate guard blocks (lines 168-434 and 440-547) could be consolidated into a single block to reduce code duplication and improve readability.

packages/core/test/integration/instance.validations.test.js (2)

95-100: Consider using the dialect variable for consistency.

The error message branching logic is correct. However, for consistency with the feature gating at line 80, consider using the dialect variable defined at line 9 rather than calling Support.getTestDialect() directly.

Optional refactor:

-        if (Support.getTestDialect() === 'ibmi') {
+        if (dialect.name === 'ibmi') {
           expect(err.errors[0].message).to.include('Duplicate key value specified');
         } else {
           expect(err.errors[0].path).to.include('uniqueName');
           expect(err.errors[0].message).to.include('must be unique');
         }

---

103-156: LGTM! Well-structured tests for custom unique constraint messages.

The nested gating correctly handles:

1. First-level check: dialect supports unique constraints at all
2. Second-level check: dialect supports custom error messages (excluding ibmi)

Test coverage for both single and multiple unique constraints with custom messages is thorough.

Optional: For consistency with line 80, consider using dialect.name !== 'ibmi' instead of Support.getTestDialect() !== 'ibmi' at lines 103 and within the nested structure.

packages/core/test/integration/associations/multiple-level-filters.test.js (2)

62-71: Make order unambiguous + explicit (ASC) to avoid dialect-specific parsing/SQL ambiguity

With joins in play, order: ['title'] can be (a) parsed differently than expected and/or (b) produce an ambiguous ORDER BY title on some dialects. Safer to qualify the column and be explicit about direction.

     const tasks = await Task.findAll({
       include: [
         {
           model: Project,
           include: [{ model: User, where: { username: 'leia' } }],
           required: true,
         },
       ],
-      order: ['title'],
+      order: [[Task, 'title', 'ASC']],
     });

---

130-147: Same here: qualify the ordered column to avoid ambiguous ORDER BY title

     const tasks = await Task.findAll({
       include: [
         {
           model: Project,
           include: [
             {
               model: User,
               where: {
                 username: 'leia',
                 id: 1,
               },
             },
           ],
           required: true,
         },
       ],
-      order: ['title'],
+      order: [[Task, 'title', 'ASC']],
     });

packages/core/test/unit/data-types/temporal-types.test.ts (1)

144-144: Consider matching the error message format for consistency.

The error message for DuckDB's unsupported TIME(precision) is shorter than the equivalent db2 error (lines 141-142) and lacks the documentation URL. For consistency and better user guidance, consider using the same format.

Apply this diff to align the error message format:

-      duckdb: new Error('duckdb does not support the TIME(precision) data type.'),
+      duckdb: new Error(`duckdb does not support the TIME(precision) data type.
+See https://sequelize.org/docs/v7/models/data-types/ for a list of supported data types.`),

packages/core/test/unit/sql/insert.test.js (1)

44-44: Consider adding feature flag checks for DuckDB-specific limitations.

Multiple test expectations now combine 'postgres duckdb' assuming identical SQL generation. While this is efficient, consider whether any of these scenarios should be gated by dialect.supports checks given the documented limitations (no constraints, no savepoints, limited RETURNING support). This would make the test suite more resilient and explicit about feature support.

As per coding guidelines: "In tests, skip unsupported behavior with dialect.supports.featureName checks."

Also applies to: 70-70, 211-211, 255-255, 295-295, 352-352, 381-381

packages/core/test/integration/query-interface/add-show-remove-constraint.test.ts (2)

10-12: Consider switching the suite title to the dialect teaser helper for consistency with other integration tests.
E.g. use the existing test helpers (getTestDialectTeaser / Support.getTestDialectTeaser) if already standard in this area. As per coding guidelines, tests should use the dialect teaser.

---

8-10: Refactor to use sequelize.dialect.supports.constraints flags instead of if (dialect !== 'duckdb') check.
DuckDB explicitly declares supports.constraints.add: false and supports.constraints.remove: false. Use feature-flag gating to align with project patterns and avoid hard-coding dialect names. This applies to both the top-level suite wrapper (line 8) and any similar patterns elsewhere (lines 703-704).

packages/core/src/abstract-dialect/query-interface.js (1)

78-85: Update the nearby TODO/comment to mention DuckDB too (since it’s now excluded alongside sqlite3).
The behavior is fine, but the comment is now misleading.

-    // TODO: the sqlite implementation of createTableQuery should be improved so it also generates a CREATE UNIQUE INDEX query
+    // TODO: sqlite3 & duckdb: createTableQuery handling around uniqueKeys is special-cased.
+    // - sqlite3: does not respect index names when created through CREATE TABLE
+    // - duckdb: unique constraints are intentionally not created (see dialect limitations)

packages/core/test/integration/query-interface/remove-column.test.ts (1)

91-102: DuckDB skip for “remove PK column” looks consistent with dialect limitations.

packages/core/test/unit/query-interface/create-table.test.ts (2)

73-99: Same concern for sql.uuidV1: DuckDB output omits the default.
If intentional, consider documenting it in the dialect limitations.

---

13-44: DuckDB expectation drops DEFAULT for sql.uuidV4—confirm this is an intentional limitation (vs missing feature).
If DuckDB can support UUID defaults, it may be worth adding a dialect implementation rather than silently omitting the default.

DuckDB SQL: what built-in functions exist for generating UUIDs (v4/v1), and can they be used in DEFAULT clauses?

packages/core/test/unit/sql/index.test.js (1)

20-169: DuckDB deliberately converts index queries to COMMENT ON TABLE ... IS 'CREATE INDEX ...' because indexes make columns impossible to update (a DuckDB limitation). While this is an intentional workaround with documented rationale (lines 101-108 in packages/duckdb/src/query-generator.js), the approach has a real drawback: it will overwrite legitimate user table comments.

Consider using a truly inert statement instead—such as a PRAGMA, SELECT 1, or raising an informative error—that doesn't risk corrupting user metadata. The current implementation works functionally but sacrifices user table comments as collateral damage.

packages/duckdb/package.json (1)

1-44: Consider adding engines field for consistency.

The core package specifies "engines": { "node": ">=18.20.8" }. For consistency across the monorepo and to ensure users are aware of Node.js version requirements, consider adding the same engines constraint to this package.

   "type": "commonjs",
   "version": "7.0.0-alpha.41",
+  "engines": {
+    "node": ">=18.20.8"
+  },
   "publishConfig": {

packages/duckdb/src/query-generator.internal.ts (1)

5-12: Return type should be readonly to match the frozen constant.
Small polish: declare return type as readonly string[] (or readonly (typeof TECHNICAL_SCHEMAS)[number][]) to reflect immutability.

packages/duckdb/src/_internal/data-types-overrides.ts (1)

38-85: DuckDB type names are correct. UTINYINT, USMALLINT, UINTEGER, and TIMESTAMPTZ are all official DuckDB type names and match the correct mappings for their respective Sequelize types.

However, consider mapping DATEONLY to DuckDB's native DATE type instead of VARCHAR. DuckDB's DATE type provides proper date semantics (comparison, date arithmetic, special values), whereas VARCHAR loses these semantics and requires explicit casting for date operations.

packages/duckdb/src/query-generator-typescript.internal.ts (1)

105-107: Remove this redundant override method. The parent class startTransactionQuery already validates readOnly and transactionType options against dialect.supports.startTransaction, which DuckDB correctly sets to false for both. Calling super.startTransactionQuery(options) provides no additional logic or safety.

packages/core/test/support.ts (1)

614-618: Clarify or remove the "TBD: clean up later" comment.

The comment on line 616 is unclear. What aspect needs to be cleaned up later? If this refers to a known follow-up task, consider creating an issue and referencing it here, or remove the comment if the implementation is complete.

     return Promise.all([
       fs.promises.rm(SQLITE_DATABASES_DIR, { recursive: true, force: true }),
-      // TBD: clean up later
       fs.promises.rm(DUCKDB_DATABASES_DIR, { recursive: true, force: true }),
     ]);

packages/core/test/integration/associations/has-one.test.js (1)

177-301: FK-dependent tests correctly gated
Gating the FK-constraint error expectations behind current.dialect.supports.constraints.foreignKey is the right way to keep the suite meaningful across dialects. Based on learnings, this is the preferred approach for unsupported constraint behavior.
Minor: describe('foreign key') becomes empty when unsupported; consider wrapping the whole describe in the if to avoid empty suites.

packages/core/test/integration/model/upsert.test.js (1)

86-108: Good capability gate for unique-constraint/index-based upsert tests
Wrapping composite-key upsert behind supports.constraints.unique and skipping unique-index-specific tests for duckdb matches the stated dialect limitations and keeps test intent accurate. Based on learnings, capability-gating is preferred over dialect-name checks; if DuckDB’s support flags already encode this, consider switching the dialectName !== 'duckdb' block to a supports check in the future.

Also applies to: 395-539

packages/core/test/config/config.ts (1)

4-23: Config helpers look fine; ensure DuckDB databases dir is created during tests
Exporting DUCKDB_DATABASES_DIR + getDuckDbDatabasePath is a good parallel to sqlite. Just ensure the test harness creates/cleans that directory (otherwise first-run can fail on some environments).

packages/duckdb/src/connection-manager.ts (1)

34-38: Prefer camelCase for added connection fields (db_path → dbPath).
Minor, but this leaks into typings and any downstream usage.

Also applies to: 56-58

packages/core/test/integration/index.test.ts (1)

9-12: Consider adding a top-level supports.indexes flag to the dialect support matrix.

The current code gates the entire indexes test suite with dialect !== 'duckdb', which hard-codes dialect names. While this is a common pattern in the test suite, the learnings emphasize using dialect.supports.* checks instead. DuckDB has all granular index features disabled (supports.index.include, supports.index.type, etc. are all false), making it suitable for a feature-level flag. Add indexes: false to DuckDB's supports configuration and update the test to use if (sequelize.dialect.supports.indexes) { describe(...) } for consistency with the testing guidelines.

packages/duckdb/src/dialect.ts (1)

160-176: escapeBuffer: consider building via array join to avoid quadratic concatenation.
Not a blocker, but this is an easy micro-optimization for large buffers:

-    let escaped = '';
+    const parts: string[] = [];
     for (const element of buffer) {
@@
-      escaped += element ? `\\x${hex}` : '\\x00';
+      parts.push(element ? `\\x${hex}` : '\\x00');
     }
-
-    return `'${escaped}'::BLOB`;
+    return `'${parts.join('')}'::BLOB`;