SQL Database

[danieldaeschle]

Sorry for opening another issue xD

I really want to have the choice between an MySQL/PostgreSQL and SQLite.

[zadam]

This would introduce extra complexity while providing close to zero benefit for the user. SQLite is perfectly fine for the Trilium workload.

[danieldaeschle]

use an orm and you have no more complexitivity

[zadam]

There's still extra complexity in providing a way to configure the database access and documenting it.

ORM means you can use only lowest common denominator in SQL features - e.g. how do I use CTE (which are critical for Trilium performance) from an ORM? The end result is that performance suffers needlessly.

ORM abstractions are often leaky anyway and you need to implement special cases for individual databases anyway.

(I'm not an ORM hater and I know their place, but Trilium just doesn't need one).

[jakerr]

I agree that an ORM is probably overkill for Trilium. I also agree that SQLite is more than adequate for the workload - however adding an abstraction layer would make it easier deploy a Trilium server on a cloud provider that has ephemeral storage as many of them do. Heroku and App Engine for example both support hosted databases but don't give you direct filesystem access to persistent storage as sqlite requires.

Maybe a framework like the anydb-sql - npm or sql-client - npm could provide an abstraction to make using PostgreSQL or MySQL possible without adding to much complexity to the project.

[OJFord]

Another benefit would be that if you already have the pg (or whatever) DBMS then Trilium can just slide in to the existing backup policy etc. rather than also backing up the disk storage, or adding a job to dump from sqlite.

[YQGong]

Another benefit would be that if you already have the pg (or whatever) DBMS then Trilium can just slide in to the existing backup policy etc. rather than also backing up the disk storage, or adding a job to dump from sqlite.

agreed!