Linux

Counter-proposal: Perhaps use Obsidian instead?

Is there a reason you're not looking at tools explicitly built for this like orgmode, obsidian, task-warrior, etc? There's a plethora of these tools and my experience with this is you really don't want to over-engineer your productivity suite.

That said, if you go the SQL route, sqlite is the way to go. Other SQL databases must be run as a daemon whereas sqlite operates on a local file directly.

However any SQL database isnt going to have the CLI youre asking for. Its interface is... SQL, so you're scripts are going to have a bunch of SQL code embedded that isnt easily reusable. A non-sql database will probably be better. I'm not familiar with them but I think there's some that store their data as text files in a folder which is organized a certain way. But that starts looking like the tools I mentioned before.

@matcha_addict Anything beyond SQLite is too heavy, but if it were me I would use a lightweight wiki like dokuwiki. Having to run SQL to do all these sorts of things sounds like it would just get in the way of both getting and consuming your thoughts.

Definitely sounds like sqlite.

If you want something a bit more powerful than SQLite, MySQL and PostgreSQL both support CLI interactions and scripting too.

Are you an emacs user?

Try org-roam. It's a similar system to obsidian, but fully open source. You have all the note taking techniques of org-mode, and all the scripting power of emacs.

I can't imagine this flow working with any DB without an UI to manage it.
How are you going to store all that in an easy yet flexible way to handle all with SQL?

A table for notes?
What fields would it have? Probably just a text field.
Creating it is simple: insert "initial note"... How are you going to update it? A simple update to the ID won't work since you'll be replacing all the content, you'd need to query the note, copy it to a text editor and then copy it back to a query (don't forget to escape it).
Then probably you want to know which is your oldest note, so you need to include created_at and updated_at fields.
Maybe a title per note is a nice addition, so a new field to add title.

What about the todo lists? Will they be stored in the same notes table?
If so, then the same problem, how are you going to update them? Include new items, mark items as done, remove them, reorder them.
Maybe a dedicated table, well, two tables, list metadata and list items.
In metadata almost the same fields as notes, but description instead of text. The list items will have status and text.

Maybe you can reuse the todo tables for your book list and links/articles to read.

so that I can script its commands to create simpler abstractions, rather than writing out the full queries every time.

This already exists, several note taking apps which wrap around either the filesystem or a DB so you only have to worry about writing your ideas into them.
I'd suggest to not reinvent the wheel unless nothing satisfies you.

What are the pros of using a DB directly for your use case?
What are the cons of using a note taking app which will provide a text editor?

If you really really want to use a DB maybe look into https://github.com/zadam/trilium
It uses sqlite to store the notes, so maybe you can check the code and get an idea if it's complicated or not for you to manually replicate all of that.
If not, I'd also recommend obsidian, it stores the notes in md files, so you can open them with any software you want and they'll have a standard syntax.

Check out https://www.giuspen.net/cherrytree/, lightweight note-taking app with interesting scripting function built in.

Even if that's not your cup of tea, it has the option to save your notebook to a single sqlite file, so I take that as good enough proof it'll work for your similar purposes as well.

I wouldn't recommend a DB for note taking purpose. You can use Markdown with vim.

Duckdb has pretty good cli support https://duckdb.org/docs/api/cli/overview.html#non-interactive-usage

Using a database for notes is like going 2km in a plane.

You can use any relational database for this though but why would you subject yourself to this?