It's possible most ubiquitous open source software ever (far more common than markdown) and your notes exist in fully readable text form inside it
Bear being proprietary is the real threat of lock in
sqlite3 data.db 'select text from notes'
I use sqlite3 to load and query random CSVs all the time. It feels a bit weird to hear data described as "locked" within a SQLite DB, because it's one of the simplest non-text formats for me to read data from. It would surprise me of it took more than five minutes to set up a one-way cron job to dump your notes into plain text files.This is just unbelievable! Fucking pitchforks are out literally!
I am dealing with plain text notes and you all want me to write sql queries and scripts to access those fucking text files?
Are you all (these few people who just jumped in the subthread) pulling some sort of prank of so?
I don't want you to do anything. Use whatever you want! But if you love your tool except for the fact it uses an open database format instead of text files, then lucky you, there's a solution, and it takes all of five minutes.
And as for sqlite being local first - it's not the same. It's the nature of the data a plain text note taking app deals with that neuters that very idea of those plain text notes by storing in a local sqlite db.
They're still a local-first note application. It's just slightly harder for you to edit your notes externally, and not even by that much - it's very easy to directly query (read and write) SQLite databases, and if you really cared you could have made a script to grab a note, export it to a temporary text file, allow you to edit it, then update the SQLite database.
> I can't version controlled backup and sync those files
You absolutely can - you can dump SQLite databases to text files that contain SQL queries that will restore the database that you can then backup and sync: https://stackoverflow.com/questions/75675/how-to-dump-the-da...
> then they moved to sqlite citing some sync and performance issues
Yes, that's because "plain text" files are bad for performance and harder to sync correctly. For people who (1) have over a hundred thousand notes they want to keep (like me) and (2) want maximum confidence that they're not going to lose years worth of work, that's incredibly important.
The devs made the right choice. You can always write scripts to interface with a SQLite database with an external editor. You can't take plain text files and magically make them as fast and durable as a database.
> It's just slightly harder for you to edit your notes externally
Yup, just slightly harder! Very slightly. A difference of 3.75 picoseconds. Couldn't agree more.
> it's very easy to directly query
Right!
> and if you really cared..have made a script
And designed a nuclear reactor while I was at it, isn't it?
> The devs made the right choice
Yessss!! Finally.
Ffs!!!
Claude can one shot this.
Also interesting to note that you couldn't actually muster a coherent response to any of my points and just had to make ad hominem attacks and emotional outbursts.
Bear devs advise against doing that: "Generally speaking, it is safe to access the database for reading only"
It's still worth pointing out that this design decision is orthogonal to the decision to use SQLite, though. The Bear devs could have designed it such that you could write to the database directly, or they could have kept the text-file-based design, but still told the user that they can't modify the files directly (as one of my personal projects does). The assignment of blame to SQLite specifically is misguided.
How would you design a system that uses SQLite as primary storage for notes (rather than just as a search index or metadata store) while still letting people edit those notes in any text editor, sync via any cloud and make them accessible to any AI or other third party software that knows how to use a file system?
Exporting and re-importing every single time you want to edit a note is impractical for tech folks and impossible for regular users.
I can imagine a partial solution using FUSE, FileProvider and whatever the respective file system abstractions are on other platforms. But that would be a huge amount of work.
What is sad is that they used to be local files first note app and then they moved to sqlite citing some sync and performance issues.