What causes "Unsupported database type" in windmill-labs/windmill?

Verify the app's database resource type is one of postgresql, mysql, ms_sql_server, snowflake, bigquery, duckdb; change the resource if not

windmill-labs/windmill · error

Unsupported database type

Error message

Unsupported database type

What it means

makeUpdateQuery generates the UPDATE SQL used by legacy Database Studio (dbexplorercomponent) apps. It supports postgresql, mysql, ms_sql_server, snowflake, bigquery and duckdb; any other dbType reaches the default arm and throws 'Unsupported database type'. Note this is the LEGACY builder — new Database Manager apps never hit it.

Source

Thrown at frontend/src/lib/components/apps/components/display/dbtable/queries/update.ts:84

		case 'bigquery': {
			const conditions = columns
				.map(
					(c, i) =>
						`(CAST(@${c.field} AS STRING) = 'null' AND ${c.field} IS NULL OR ${c.field} = @${c.field})`
				)
				.join('\n    AND ')
			query += `\nUPDATE ${table} SET ${column.field} = @value_to_update \nWHERE ${conditions}`
			return query
		}
		case 'duckdb': {
			const conditions = columns
				.map((c) => `($${c.field} IS NULL AND ${c.field} IS NULL OR ${c.field} = $${c.field})`)
				.join('\n    AND ')
			query += `\nUPDATE ${table} SET ${column.field} = $value_to_update \nWHERE ${conditions}`
			return query
		}
		default:
			throw new Error('Unsupported database type')
	}
}

export function getUpdateInput(
	dbInput: DbInput,
	table: string,
	column: ColumnDef,
	columns: ColumnDef[]
): AppInput | undefined {
	if (
		(dbInput.type == 'ducklake' && !dbInput.ducklake) ||
		(dbInput.type == 'database' && !dbInput.resourcePath) ||
		!table
	) {
		return undefined
	}
	const dbType = dbInput.type === 'ducklake' ? 'duckdb' : dbInput.resourceType
	let query = makeUpdateQuery(table, column, columns, dbType)

View on GitHub (pinned to e474e8803c)

Solutions

Verify the app's database resource type is one of postgresql, mysql, ms_sql_server, snowflake, bigquery, duckdb; change the resource if not
Inspect the dbType argument at the call site (query in the dbtable component) — undefined indicates an unresolved DbInput, fix the input binding
For new apps, migrate to the Database Manager flow (dbOps.ts → dbTableOpsWithPreviewScripts with WM_INTERNAL_DB markers) instead of the legacy expanded-SQL builder
Add a missing case to the switch in update.ts if a supported backend DbType was added without frontend support, then redeploy the app

Example fix

// before
makeUpdateQuery(table, column, columns, dbType) // dbType: DbType | undefined
// after
if (!dbType || !SUPPORTED_DB_TYPES.includes(dbType)) {
  throw new Error(`Update not supported for database type: ${dbType}`)
}
makeUpdateQuery(table, column, columns, dbType)

Defensive patterns

Strategy: validation

Validate before calling

const SUPPORTED = ['postgresql','mysql','ms_sql_server','snowflake','bigquery','duckdb']
if (!dbType || !SUPPORTED.includes(dbType)) {
  throw new Error(`Inline update not supported for database type: ${dbType}`)
}

Type guard

function canBuildUpdateQuery(dbType: unknown): dbType is DbType {
  return typeof dbType === 'string' &&
    ['postgresql','mysql','ms_sql_server','snowflake','bigquery','duckdb'].includes(dbType)
}

Try / catch

try {
  const sql = makeUpdateQuery(table, column, columns, dbType)
} catch (e) {
  if (e.message === 'Unsupported database type') {
    showToast(`Inline editing is not supported for '${dbType}' databases`, true)
  } else throw e
}

Prevention

Use the legacy builder only for pre-existing dbexplorercomponent apps; new apps should use dbOps.ts (WM_INTERNAL_DB) which is type-agnostic server-side
Guard getUpdateInput/makeUpdateQuery call sites with the same supported-type check used elsewhere
Verify the database resource type before enabling inline cell editing in the UI
Track new DbType additions and update all legacy builders together

When it happens

Trigger: Calling makeUpdateQuery(table, column, columns, dbType) with a dbType outside the six-case switch, e.g. an unresolved DbInput (undefined), a ducklake input where dbInput.ducklake is set so the getUpdateInput guard doesn't bail out first, or a newly added DbType without an update-query case.

Common situations: Editing a cell in a Database Studio app backed by an unsupported/new database resource; dbType string from a resource that was renamed; mixed inputs where the type guard in getUpdateInput passes but the switch has no case (e.g. a snowflake_oauth-style alias); frontend/backendDbType divergence after an upgrade.

Related errors

AI-assisted analysis of windmill-labs/windmill@e474e8803c (2026-09-03). Data as JSON: /api/errors/f7240151e6d2efb1. Report an issue: GitHub.