emacs-everywhere VS Udb

No. I do not have any single arrow combo in my workflow. For complex text editing I use this that gives me an emacs window on any text field. And if something, maybe like moving windows left/right up/down I remap the shortcuts to remove the arrows part and add the vim like keys hjkl

Not exactly the same but there is eMacs everywhere: https://github.com/tecosaur/emacs-everywhere

emacs-everywhere

Alternatively you might want to try Emacs everywhere[1].

[1]: https://github.com/tecosaur/emacs-everywhere

If anyone is curious, I'd use the command in conjunction with emacs-anywhere to paste the contents on an Emacs window, and then paste it again on the text field with my edits. And yes, I am aware that atomic-chrome can do that, but it doesn't work with every website and I'd like a solution that does not depend on how any particular browser and website is coded.

What about those of us who'd like to use Emacs as an input method

Better solution: https://github.com/cknadler/vim-anywhere, for neovim users (and probably vim users) you can utilize some apple script as well: https://blog.schembri.me/post/neovim-everywhere-on-macos/. For those of you who want to try org-mode and evil, https://github.com/tecosaur/emacs-everywhere is awesome. And if you don't want to use an editor, a similar project (using Hammerspoon) is available here: https://github.com/dbalatero/VimMode.spoon

This article is from 2021.

They indeed use an SQL database and SQL queries to implement a key-value store. The data is stored in a regular table (CREATE TABLE example (key BLOB PRIMARY KEY, value BLOB NOT NULL). It's very unlikely that this really achieves high-performance, given that the SQLite backend is actually a key-value store and the SQL interpreter runs on top of it as an intermediate layer. To avoid some performance-drawbacks caused by this architecture they added caching.

They have even considered RocksDB and LMDB, but have rejected them with reasons that I can not relate.

I have implemented a transactional key-value store myself for my project and information management tools fifteen years ago (before the other mentioned stores became available) based on the aforementioned SQLite backend (see https://github.com/rochus-keller/Udb and https://github.com/rochus-keller/Sdb) which supports both robust integrity and high performance. Doing the same with the full SQLite just adds complexity and lowers performance with no added value.

I implemented my own NoSql database for Crossline which supports an efficient storage and traversal of outline items (see https://github.com/rochus-keller/Udb). Even if there was a dedicated API in Emacs/Org-mode it's still file based text buffer interpretation and management behind the scenes.

SQLite has a backend which is well suited as a key-value store.

Here is a NoSql database based on the SQLite backend: https://github.com/rochus-keller/Udb.

I use it in many of my apps, e.g. https://github.com/rochus-keller/CrossLine