sequelize/sequelize · error · Error

${dialect.name} does not support the ${typeName} data type.

Error message

${dialect.name} does not support the ${typeName} data type.
See https://sequelize.org/docs/v7/models/data-types/ for a list of supported data types.

What it means

throwUnsupportedDataType is called by a DataType's `_checkOptionSupport` (or option checks) when the active dialect's `supports.dataTypes.*` table indicates the type — or a particular option of it — is not available. It produces a dialect-specific message and links to the data-types docs. This is the canonical 'this dialect does not have that type' failure.

Source

Thrown at packages/core/src/abstract-dialect/data-types-utils.ts:121

  throw new Error(
    'attributeTypeToSql received a type that is neither a string or an instance of AbstractDataType',
  );
}

export function getDataTypeParser(
  dialect: AbstractDialect,
  dataType: DataTypeClassOrInstance,
): (value: unknown) => unknown {
  const type = normalizeDataType(dataType, dialect);

  return (value: unknown) => {
    return type.parseDatabaseValue(value);
  };
}

export function throwUnsupportedDataType(dialect: AbstractDialect, typeName: string): never {
  throw new Error(`${dialect.name} does not support the ${typeName} data type.
See https://sequelize.org/docs/v7/models/data-types/ for a list of supported data types.`);
}

View on GitHub (pinned to 7e1deec499)

Solutions

Use a type the target dialect supports (e.g. replace JSONB with JSON, CITEXT with STRING + a case-insensitive collation).
Drop the unsupported option (e.g. remove `.UNSIGNED`, `.BINARY`, or precision).
Keep dialect-specific types behind a dialect check and provide an alternative per dialect.

Example fix

// before (on MySQL)
sequelize.define('User', { meta: { type: DataTypes.JSONB } });
// after
sequelize.define('User', { meta: { type: DataTypes.JSON } });

Defensive patterns

Strategy: validation

Validate before calling

function assertTypeSupported(dialect: any, typeId: string) {
  if (!dialect.supports?.dataTypes?.[typeId]) {
    throw new Error(`${dialect.name} does not support ${typeId}; choose a dialect-appropriate type.`);
  }
}

Type guard

function isTypeSupportedByDialect(dialect: any, typeId: string): boolean {
  return Boolean(dialect?.supports?.dataTypes?.[typeId]);
}

Prevention

Keep model definitions dialect-portable; avoid dialect-only types (JSONB, CITEXT, HSTORE) unless you target that dialect exclusively.
When supporting multiple dialects, branch on `sequelize.dialect.name` and select an appropriate type per dialect.
Run model-sync tests against every supported dialect in CI to catch unsupported types.

When it happens

Trigger: Declaring a model with a type the dialect lacks: e.g. `DataTypes.CITEXT` on MySQL/SQL Server, `DataTypes.JSONB` on non-Postgres, `DataTypes.BIGINT.UNSIGNED` on a dialect without unsigned bigints, `DataTypes.HSTORE` outside Postgres, or an option like `STRING.BINARY` where `COLLATE_BINARY` is unsupported.

Common situations: Switching dialects (e.g. developing on Postgres with JSONB then deploying to MySQL); using a type only supported by one DB; turning on an unsupported option (zerofill, unsigned, precision on TIME).

Related errors

AI-assisted analysis of sequelize/sequelize@7e1deec499 (2026-08-03). Data as JSON: /data/errors/4130ec304bd5ea61.json. Report an issue: GitHub.