SQLite

SQLite is a file, not a server. In AddisDB you pick the file instead of filling in host, port and credentials — and from there you get the same workspace as any other SQL engine, including in-grid editing and throwaway test copies.

Who it is for

SQLite is the most widely deployed database in existence, because it is embedded in phones, browsers, and desktop applications rather than run as infrastructure. There is no server to operate, no port to secure, and no connection to pool — the database is a single file you can copy, email, or commit.

Its type system is the thing to know before you query one: SQLite uses type affinity rather than strict types, so a column declared INTEGER can hold the string "42" if something wrote it that way. Version 3.37 added STRICT tables for when you want the declaration enforced.

Use it for local application state, mobile and desktop app storage, test fixtures, small internal tools, and any analysis where "the data is one file" is a feature. It is also where you will find yourself when debugging an iOS or Android app’s local store.

Getting a database file

1. You usually already have one: an app’s local store, a .db / .sqlite / .sqlite3 file from a colleague, or a fixture in your repository.
2. To make one, sqlite3 mydata.db from the terminal creates it on first write.
3. Pulling one off a mobile device or a container? Copy it out first and work on the copy — AddisDB opens the file you point it at.
4. If the database was in use, make sure any -wal and -shm sidecar files come with it. A copy taken without the -wal file is missing every committed transaction that had not been checkpointed yet.

# Pull an app database out of a container, sidecars included
docker cp mycontainer:/data/app.db ./app.db
docker cp mycontainer:/data/app.db-wal ./app.db-wal

Connect from AddisDB

1. New Connection → SQLite under Relational / SQL.
2. There is no host, port or password — just choose the database file.
3. Give it a Display name and an Environment tag if it matters.
4. Test, then Save.

What AddisDB gives you

• The schema diagram of your tables and foreign keys, with saved per-project views.
• In-grid editing — change cells, add, duplicate and delete rows without writing SQL.
• Test clones — AddisDB copies the file to a temporary sandbox and runs your SQL there, so a risky migration never touches the original.
• Mock data generated from your real schema, tinted amber and removable in one click.
• Migrations and schema diff through Drizzle Kit or Prisma, plus AI querying and query repair.
• The Chart view, notebooks, and ⌘K search across every connection.

Rehearsing a migration on a copy

Test clones matter more here than anywhere else, because SQLite’s ALTER TABLE is narrow: it can rename, add and drop a column, and little else. Any other change is the twelve-step dance of building a new table, copying rows, dropping the old one and renaming. Running that against a disposable copy first turns a nerve-racking operation into a rehearsal.