vino
Udb
| vino | Udb | |
|---|---|---|
| 2 | 3 | |
| 37 | 4 | |
| - | - | |
| 4.7 | 0.0 | |
| 4 months ago | about 1 year ago | |
| Emacs Lisp | C++ | |
| GNU General Public License v3.0 only | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
vino
-
Notion or small databases in emacs
If you're looking for a fairly complicated quasi-relational example in emacs, you might check out the Vino wine database (https://github.com/d12frosted/vino), which is built on vulpea, which is a database-backed emacs package. The author recently launched another project on top of that, https://barberry.io/, which has a lot of the features you'd find in a complicated Notion workflow. But if Notion works for you, don't switch -- use whatever tools work best for you.
-
I use Org Mode for personal logging/journalling
If you're trying to do this in org, take a look at vulpea. It's roughly the same engine that powers the current version of org-roam. It's useful for automating org files; a good example application of this is the vino wine database: https://github.com/d12frosted/vino
Udb
-
BoringDB: A high-performance key-value store built on SQLite
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 use Org Mode for personal logging/journalling
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.
-
Ask HN: What is the SQLite of nosql databases?
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
What are some alternatives?
org-roam-bibtex - Org Roam integration with bibliography management software
emacs-everywhere - Mirror of https://git.tecosaur.net/tec/emacs-everywhere
.emacs.d - My Emacs Configuration
emacs-db - very simple database for emacslisp, can also wrap other databases.