Dialects Reference

SQLFluff is designed to be flexible in supporting a variety of dialects. Not all potential dialects are supported so far, but several have been implemented by the community. Below are a list of the currently available dialects. Each inherits from another, up to the root ansi dialect.

For a canonical list of supported dialects, run the sqlfluff dialects command, which will output a list of the current dialects available on your installation of SQLFluff.

Note

For technical users looking to add new dialects or add new features to existing ones, the dependent nature of how dialects have been implemented is to try and reduce the amount of repetition in how different elements are defined. As an example, when we say that the Redshift dialect inherits from the PostgreSQL dialect this is not because there is an agreement between those projects which means that features in one must end up in the other, but that the design of the Redshift dialect was heavily inspired by the postgres dialect and therefore when defining the dialect within sqlfuff it makes sense to use PostgreSQL as a starting point rather than starting from scratch.

Consider when adding new features to a dialect:

  • Should I be adding it just to this dialect, or adding it to a parent dialect?

  • If I’m creating a new dialect, which dialect would be best to inherit from?

  • Will the feature I’m adding break any downstream dependencies within dialects which inherit from this one?

ANSI

This is the base dialect which holds most of the definitions of common SQL commands and structures. If the dialect which you’re actually using isn’t specifically implemented by SQLFluff, using this dialect is a good place to start.

This dialect doesn’t intend to be brutal in adhering to (and only to) the ANSI SQL spec (mostly because ANSI charges for access to that spec). It aims to be a representation of vanilla SQL before any other project adds their spin to it, and so may contain a slightly wider set of functions than actually available in true ANSI SQL.

Athena

The dialect for Amazon Athena.

BigQuery

The dialect for Google BigQuery.

ClickHouse

The dialect for ClickHouse.

Databricks

The dialect Databricks.

Db2

The dialect for Db2.

DuckDB

The dialect for DuckDB.

Exasol

The dialect for Exasol.

Greenplum

The dialect for Greenplum.

Hive

The dialect for Hive.

Materialize

The dialect for Materialize.

MariaDB

The dialect for MariaDB.

MySQL

The dialect for MySQL.

Oracle

The dialect for Oracle SQL. Note: this does not include PL/SQL.

PostgreSQL

This is based around the PostgreSQL spec. Many other SQL instances are often based on PostreSQL syntax. If you’re running an unsupported dialect, then this is often the dialect to use (until someone makes a specific dialect).

Redshift

The dialect for Amazon Redshift.

Snowflake

The dialect for Snowflake, which has much of its syntax inherited from PostgreSQL.

SOQL

The dialect for SOQL (Salesforce Object Query Language).

SparkSQL

The dialect for Apache Spark SQL. It inherits from ANSI and includes relevant syntax from Greenplum for commands that permit Hive Format. Spark SQL extensions provided by the Delta Lake project are also implemented in this dialect.

This implementation focuses on the Ansi Compliant Mode introduced in Spark3, instead of being Hive Compliant. The introduction of ANSI Compliance provides better data quality and easier migration from traditional DBMS.

Versions of Spark prior to 3.x will only support the Hive dialect.

SQLite

The dialect for SQLite.

T-SQL

The dialect for T-SQL (aka Transact-SQL).

Teradata

The dialect for Teradata.

Trino

The dialect for Trino.

Vertica

The dialect for Vertica.