'Lite' Databases (Re: sqlite3 and dates)

[Paul Rubin]

Ben Finney <ben+python at benfinney.id.au> writes:
> I don't know of a free-software concurrent RDBMS which can be considered
> lighter than that. (No, MySQL doesn't count; its concurrency is
> *unreliable* and it commonly loses data silently. Don't use MySQL.)

I thought they fixed MySQL transactions years ago, with the InnoDB
engine.  For some reason it's not the default, so you have to turn it on
explicitly: is there more to it than that?

For stuff like browser bookmarks or other typical embedded database
purposes, I don't see why SQL or relations are needed.  Berkeley DB is a
transactional key-value store that's been around for decades and is way
simpler than SQLite, and there's other things like that too.

SQLite always seemed bloated (from the embedded NoSQL point of view) and
fragile to me, and the vendor plays an annoying anti-forking trick,
which is that the code is released but the developers' test suite is
secret and proprietary (can be licensed from them for big bucks).  So if
you want to make your own version of SQLite you have to either pay for
the test suite, or have much less reliability assurance for your patched
version than the vendor has for their version.  Add that Sqlite is
written in C (think of naked whirling razor blades) and you've got a
pretty serious disincentive against modification.