Use Turso as alternative drop‑in database backend to implement encryption at rest

[cruntal]

Hello,

I think it would be nice let user to choose storage backend when setup TriliumNotes's database:

• Sqlite - the usual way without encryption‑at‑rest
• Turso - with optional encryption‑at‑rest https://docs.turso.tech/tursodb/encryption

---

Here is some information:

It’s technically possible to replace SQLite with Turso/libSQL in Trilium Notes to gain encryption‑at‑rest — but it is not a drop‑in swap today, and Trilium does not officially support Turso/libSQL as a backend.
Turso’s libSQL fork does provide fully open‑source encryption at rest for SQLite‑compatible databases, but integrating it into Trilium requires code changes and is not currently turnkey.

🔍 What Turso/libSQL Actually Provides
Turso is built on libSQL, an open‑contribution fork of SQLite that adds features SQLite doesn’t natively include, such as:

Encryption at rest (fully open source)

Replication and serverless access

Compatibility with most SQLite APIs

A local embedded mode and a remote HTTP-accessed mode

This means libSQL can act as a SQLite-compatible embedded database with encryption — something Trilium currently lacks.

🧩 Can Trilium Notes Use Turso/libSQL Instead of SQLite?
✔ Theoretically possible
Trilium uses SQLite through standard Node.js SQLite bindings. Since libSQL aims to be a drop‑in replacement for SQLite, it is theoretically possible to:

Replace the SQLite library with libSQL’s compatible client

Point Trilium to a libSQL database file (local encrypted mode)

Or connect Trilium to a remote Turso database (less ideal due to latency and sync semantics)

❌ Not supported out of the box
Trilium does not currently support libSQL/Turso as a backend.
You would need to modify:

The database initialization code

The Node.js SQLite driver (swap to libSQL’s driver)

Possibly SQL queries if any SQLite‑specific behavior differs

⚠ Practical issues to consider
Trilium expects a local embedded SQLite file, not a remote HTTP database.

Encryption at rest in libSQL requires using its own library — Trilium would need explicit integration.

Backups, WAL mode, and journaling may behave differently.

Community support for non‑SQLite backends is minimal.