> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tamery.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Connect to SQLite

> Open a SQLite database file, a Turso database or a Cloudflare D1 database in Tamery.

A SQLite connection points at a database file on your computer, a [Turso](#turso) database or a [Cloudflare D1](#cloudflare-d1) database. Pick the one you want under **Engine**: **SQLite**, **Turso** or **Cloudflare D1**. All three are SQLite to Tamery, so tables, rows, the SQL editor and the schema pages work the same way.

## Open a file

On the new-connection page, any of these works:

* **Paste its path**, for example `/Users/me/app.db` or `~/app.db`. A bare path counts when it ends in `.db`, `.db3`, `.sqlite` or `.sqlite3`. A `sqlite://`, `file:` or `jdbc:sqlite:` URL, or a `sqlite3 <file>` command, works with any extension; options after `?` in a URL (`?mode=ro`) are dropped.
* **Drop the file** onto the window (desktop app).
* Pick **SQLite** as the engine and type the path in **File**, or click the folder button beside it to choose the file (desktop app).

The path must be a full one. A path starting with `~/` opens from the home folder of whichever computer runs the query, so a synced connection finds the same file on each of your machines.

Tamery opens a file that already exists and never creates one, so a mistyped path fails the test instead of leaving an empty database behind.

The connection string is the file's absolute path:

```bash theme={null}
sqlite:///Users/me/app.db
```

## Turso

Turso gives each database a URL and a token. On the database's page in the Turso dashboard, copy the **Database URL** and click **Create Token**, or run `turso db show <name> --url` and `turso db tokens create <name>`. Then paste either of these anywhere on the new-connection page:

```bash theme={null}
libsql://my-db-my-org.aws-eu-west-1.turso.io?authToken=eyJhbGciOi…
```

```bash theme={null}
TURSO_DATABASE_URL=libsql://my-db-my-org.aws-eu-west-1.turso.io
TURSO_AUTH_TOKEN=eyJhbGciOi…
```

Tamery fills **Host** and **Auth token**, and keeps the token like a password, so the **No password** sync keeps it on this device. A self-hosted libSQL server works too: give its host and port, and add `tls=0` to the URL if it speaks plain HTTP.

## Cloudflare D1

D1 is reached through Cloudflare's API with three things: the account ID, the database ID and an API token.

* **The IDs**: open the database in the Cloudflare dashboard and paste its address (`https://dash.cloudflare.com/<account-id>/workers/d1/databases/<database-id>`). A `wrangler.toml` or `wrangler.jsonc` with `database_id`, or `CLOUDFLARE_ACCOUNT_ID` and `CLOUDFLARE_DATABASE_ID`, works as well.
* **The token**: in the Cloudflare dashboard, open **My Profile → API Tokens → Create Token → Create Custom Token**. Add the permission **Account · D1 · Edit** (or **Read** for a read-only connection), choose your account under **Account Resources**, then create the token and paste it into **API token**.

D1 runs no transaction across requests, so Tamery sends the statements of a transaction (a grid save, a schema change, a `BEGIN … COMMIT` block run with **Run all**) as one batch when it commits, and D1 runs them all or none. Statements inside such a block return no rows. Running `BEGIN` on its own to keep a transaction open is not available on D1 or Turso; run the whole block with **Run all** instead. Cloudflare's own `_cf_` tables are hidden. D1's API sends numbers as JSON, so an integer beyond 2^53 comes back rounded, and D1 refuses `sqlite_version()`, so its connection shows no version.

## From the web app

The web app cannot read files on your computer. Run [`tamery proxy`](/cli/commands) on the computer that holds the file, and Tamery opens the file there. The cloud proxy never opens SQLite files. Turso and D1 databases work from the web like any other cloud database.

## What works

SQLite changes a table mostly by rebuilding it, so Tamery offers only what it can run directly:

* **Columns**: add, rename and drop. A stored column's type and **Allow NULL** stay fixed, and SQLite has no column comments.
* **Indexes and triggers**: create, edit and drop. An edit drops and creates the object inside one transaction, so a failure leaves the old one in place.
* **Constraints** are listed: primary keys, unique keys and foreign keys. SQLite only defines them when a table is created, so they are read-only. Check constraints are not listed.
* **Schemas, functions, enums and policies** don't exist in SQLite, so those lists are hidden.

**Stop** cannot interrupt a SQLite statement that is already running; it finishes first.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.