SQLite

SQLite is the simplest engine to connect to: there is no server and no network. You point QoreDB at a file on disk (or an in-memory database) and you are connected.

Quick connect

Open New Connection, choose SQLite, and either browse to a file or paste a path.

SQLite takes a bare file path (absolute or relative) or :memory: — there is no sqlite:// URL scheme.

Connection fields

There is no host, port, user or password for SQLite. The "vault" of QoreDB still applies if you save the connection (for naming, environment, SSH, etc.), but no secrets are stored for SQLite itself.

File creation and extensions

QoreDB creates the file automatically if it does not exist. You can point at a path that has not been used yet, click Connect, and the file will be created on disk on first write.

The driver validates the file extension. Supported extensions are:

• .db
• .sqlite
• .sqlite3
• .db3
• .s3db
• .sl3

If you want a different extension, rename the file or use the :memory: form.

In-memory databases

Use :memory: to create a database that lives only in RAM and disappears when the connection closes. Great for quick experiments, throwaway tests and scratch pads.

sqlite::memory:

You can also write sqlite::memory: directly in the path field. There is no persistence; quitting the app or closing the connection drops everything.

WAL mode

QoreDB opens SQLite databases in Write-Ahead Logging (WAL) journal mode by default. WAL is the recommended journal mode for most modern uses: better concurrency (readers don't block writers and vice versa), faster commits, and no extra steps from your side.

A side effect of WAL is that two extra files appear next to your database file: myapp.db-wal and myapp.db-shm. They are part of normal operation; do not delete them while the database is in use.

If your database needs to be opened by an older tool that doesn't support WAL, you can switch back to rollback journal mode in that tool by running PRAGMA journal_mode=DELETE;.

Concurrency notes

SQLite allows many concurrent readers but only one writer at a time. With WAL, readers don't block the writer and vice versa, which makes the experience feel concurrent for most desktop and embedded use cases. But:

• Long write transactions can starve other writers.
• Two QoreDB connections (or QoreDB plus another tool) opening the same file simultaneously is fine for reads, fine for one writer at a time, and not fine if both try to write at the same instant; the second one will get SQLITE_BUSY.

If you are using SQLite as a backing store for a multi-user application, that's likely the wrong tool. For desktop, embedded and single-user development workflows, it is excellent.

Common issues

Where to go next

• Querying: editor and autocomplete for the SQL editor
• Reference: connection URLs for the full URI grammar