Skip to main content
A SQLite connection points at a database file on your computer, a Turso database or a 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:

​
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:
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 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.