> Right now, all these plain text strings are stored in a SQLite database locally on your computer. But we have plans to remove the reliance on a custom database and to store all notes as simple .txt files inside a folder.
I'm curious why would you want to move away from SQLite?
Thanks! I'm not 100% sure about this, still hearing feedback from people on both ends. Some reasons for the switch would be:
1. File versioning
2. Easier self-hosted syncing
3. Better data portability (although we already support exporting to .txt)
I would love to hear counterpoints. Currently, SQLite works pretty well, and our custom database is pretty simple (plus, our database code is also open source[1]).
An encrypted DB will be a differentiator compared to every other offline editor (Joplin et al). It would also appeal to privacy-conscious enterprise users whose laptops may get automatically backed up.
You can support a timed export to text files for those other use-cases.
Indexing/search/relations/performance would be some counterpoints that SQlite already solved.
I have experience with flat file CMS systems (similar usecase) and at some point of complexity you end up rewriting your own database. Once every file has UUID an you have text file indexes of these than you realize you might have gone too far.
But not all projects need that and the argument for version control is big.
Thanks for the input! I'll definitely take this into consideration and research more before deciding. Currently staying with SQlite and pretty happy with it.
> Right now, all these plain text strings are stored in a SQLite database locally on your computer. But we have plans to remove the reliance on a custom database and to store all notes as simple .txt files inside a folder.
I'm curious why would you want to move away from SQLite?