> ## Documentation Index > Fetch the complete documentation index at: https://private-7c7dfe99-parallel-read-in-order-multi-part.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. > Allows to perform queries on data stored in a SQLite database. # sqlite Allows to perform queries on data stored in a [SQLite](/reference/engines/database-engines/sqlite) database.

Syntax

```sql theme={null} sqlite('db_path', 'table_name') ```

Arguments

* `db_path` — Path to a file with an SQLite database. [String](/reference/data-types/string). * `table_name` — Name of a table in the SQLite database, or a query passed to SQLite as is (see [Passing a query instead of a table name](#passing-a-query)). [String](/reference/data-types/string).

Returned value

* A table object with the same columns as in the original `SQLite` table.

Passing a query instead of a table name

Instead of a table name, the second argument can be a `SELECT` query that is passed to SQLite as is. The structure of the resulting table is inferred from the query result. SQLite reports a declared type only for a result column that is a direct column of a table; for an expression, a literal or an aggregate it reports nothing. A declared type that maps to `String` (see the [type mapping](/reference/engines/database-engines/sqlite#data_types-support)) is used as is. A column without a declared type is typed from the storage class of its value in the first row of the query result: an `INTEGER` value gives `Int64`, a `REAL` value gives `Float64`, and any other value (`TEXT`, `BLOB`, `NULL`), as well as an empty result, gives `String`. A numeric declared type is checked against that first row as well, because SQLite reports a declared type for a compound `SELECT` too, taken from one of its arms while the rows come from all of them. It is kept when the storage class of the value agrees with it (`INTEGER` for an integer type, `INTEGER` or `REAL` for a floating-point type), and also when the value is `NULL` or the result is empty, since neither carries any type information that could contradict it; otherwise the column is typed from the storage class, like an undeclared one. The inferred type is therefore only ever widened, never narrowed. Inferring such a column starts the query in SQLite. The first row does not speak for the rest: SQLite is free to return a different storage class in every row (for example, `CASE WHEN id = 1 THEN 1 ELSE 1.5 END`), so a query-backed read is fail-closed for every column read through a numeric type - not only for the ones without a declared type. A value whose storage class does not match that type, or which is not exactly representable in it (an `INTEGER` cell of `300` in a `UInt8` column, a `REAL` cell of `16777217` in a `Float32` column), fails the read instead of being silently coerced. To read a column with values of mixed storage classes, declare it as `String` or cast it to text in the SQLite query. Every inferred column is `Nullable`. The query can be written either as a subquery, or wrapped into the `query` function: ```sql theme={null} SELECT * FROM sqlite('sqlite.db', (SELECT col1, col2 FROM table1 WHERE col2 > 1)); SELECT * FROM sqlite('sqlite.db', query('SELECT col1, col2 FROM table1 WHERE col2 > 1')); ``` Passing a query is supported starting from version 26.7. ClickHouse wraps the query into `SELECT ... FROM ()` before sending it to SQLite, so it must not end with a semicolon. Such a table is read-only: `INSERT` into it is not allowed. The same syntax is supported by the [`SQLite`](/reference/engines/table-engines/integrations/sqlite) table engine. The subquery form `(SELECT ...)` is parsed by ClickHouse and re-serialized before being sent to SQLite. It must therefore be valid ClickHouse SQL. To pass SQLite-specific syntax that ClickHouse does not parse, use the `query('...')` form, whose text is sent to SQLite verbatim. Any outer `WHERE`, `LIMIT`, aggregation, etc. of the surrounding ClickHouse query is **not** pushed down into the passed query — it is applied in ClickHouse after the full query result is fetched. To restrict the data read from SQLite, put the filter inside the passed query. With [`external_table_strict_query = 1`](/reference/settings/session-settings/external-table#external_table_strict_query) an outer filter on the columns of the table function is rejected with an exception instead of being applied locally, because it cannot be pushed into the passed query. The check covers the top-level `WHERE` predicate and each conjunct of a top-level `AND`. A `PREWHERE` on the columns of this table is not a case for this setting: this table engine do not support `PREWHERE`, and such a query is rejected with `ILLEGAL_PREWHERE` regardless of the setting. The check runs only where a filter could be pushed down at all: when this table is the only table of the query, on either side of an `INNER JOIN`, or on the preserving side of an outer join (the left side of a `LEFT JOIN`, the right side of a `RIGHT JOIN`). On the non-preserving side of a `LEFT`/`RIGHT JOIN` and on either side of a `FULL JOIN` nothing is pushed down and nothing is checked, so a filter on the columns of this table is applied locally after the join even in strict mode. Where the check runs, a predicate that references other tables joined in the surrounding query is not pushed down and is excluded from the check, whether it references only the joined side or mixes it with this table inside one non-`AND` expression (for example an `OR`); such a predicate keeps its usual ClickHouse evaluation point (`WHERE` after the join, `PREWHERE` before it) and is not rejected.

Example

```sql title="Query" theme={null} SELECT * FROM sqlite('sqlite.db', 'table1') ORDER BY col2; ``` ```text title="Response" theme={null} ┌─col1──┬─col2─┐ │ line1 │ 1 │ │ line2 │ 2 │ │ line3 │ 3 │ └───────┴──────┘ ``` * [SQLite](/reference/engines/table-engines/integrations/sqlite) table engine * [SQLite database engine](/reference/engines/database-engines/sqlite) — Data types support section