Mastering Case Sensitivity Across Snowflake, Databend, MySQL, and PostgreSQL

1. Database and Table Name Case Sensitivity

When a database is created with case‑sensitive settings, changing it later to case‑insensitive makes previously created objects inaccessible if their names do not match the new case rules.

Snowflake: case‑sensitive by default; identifiers must be wrapped in double quotes, backticks become part of the name.

Databend: case‑sensitive by default; compatible with both PostgreSQL and MySQL naming styles.

MySQL (Linux): case‑sensitive by default; identifiers should be wrapped in backticks.

PostgreSQL: case‑sensitive by default; identifiers must be wrapped in double quotes.

Using only lowercase letters, underscores, and digits for database, schema, table, and column names avoids most of these problems.

2. Column Name Case Sensitivity

Column identifiers can also be case‑sensitive. For example, the identifiers "Aa" and "AA" are distinct when quoted.

In Snowflake, Databend, and PostgreSQL the following statement works and treats the two columns as different: SELECT Aa, AA FROM my_table; Databend also supports this syntax. MySQL, however, treats column names as case‑insensitive, so "Aa" and "AA" refer to the same column; backticks can be used for identifiers but the case rule differs from tables.

3. Case Handling in Column Data

MySQL stores character data in a case‑insensitive manner unless the column collation explicitly enforces case sensitivity. This means that queries may ignore case differences in string values.

Snowflake, Databend, and PostgreSQL preserve the exact case of stored strings, allowing precise case‑sensitive queries.

4. Double‑Quote vs Single‑Quote in Strings

In MySQL, both single and double quotes produce string literals, and backticks are used for identifiers. There is no functional difference between single‑ and double‑quoted strings.

In Snowflake, Databend, and PostgreSQL, double quotes denote identifiers (tables, columns, etc.), while single quotes denote string literals. Using the wrong quoting style leads to syntax errors or unexpected behavior.

Conclusion

Enforce lowercase, underscore‑separated naming for databases, tables, and columns; limit total identifier length to ≤63 characters.

Avoid using reserved words and never start identifiers with digits.

Use only alphanumeric characters, underscores, and lowercase letters in query aliases.

If double quotes or backticks are required, keep them consistently in the definition and usage of the identifier.