BerkeleyDB replacement?
 

During the time since I last checked, Oracle seems to have killed off BerkeleyDB. What, if anything, would be a comparable substitute?

I'd prefer something smallish and ideally with Perl support, but Python would also be acceptable.

not Sqlite then?

Correct. SQLite is an SQL database and arranges the data in 2D arrays (tables) but BerkeleyDB is a key-value database and thus a different animal. I was hoping there would be a fork of BerkelyDB hiding somewhere or something similar yet packaged for APT.

YottaDB could be an alternative, it is a key-value database, but there is not an APT package for it. I myself can install it no problem but those I would hand off to would not enjoy an unpackaged db. Maybe that's on them though.

 

I'm not familiar with BerkeleyDB, but when I want non-relational key-value stuff I'll usually go with either a simple ini file or with Redis - there's a handful of Perl libraries.

(It also happens to be the first response to searching key value perl, which might provide other candidates if Redis isn't suitable for whatever reason.)

I have libdb5.3 - Berkeley v5.3 Database Libraries
On my Mint Ubuntu based repo still.

Thanks. It seems I missed that. That's a relief.

Though there is less pressure, I am still curious as to what other key-value databases are readily available.

https://pypi.org/project/berkeleydb/
https://pypi.org/project/bsddb3/

https://github.com/facebook/rocksdb

https://www.linuxlinks.com/KeyValueStores/

https://www.ibm.com/topics/etcd

https://sourceforge.net/software/key-value-databases/

“BerkleyDB” is basically what we old-schoolers would refer to as “ISAM = Indexed Sequential Access Method.” It provided only the primitive ability to find a single record based on a single key.

If you are still encountering such software in service, it is time to rewrite it. And “SQLite” is now the appropriate solution. You can implement the remedy “a step at a time.”

Thanks all.

After looking around, including at my own scripts, I guess the answer for most use-cases will be SQLite.

For other situations, such as nested comment hierarchies and controlled vocabulary taxonomies, something else is probably better. Though by making convoluted queries one can force a hierarchy from a table.

You can certainly use an SQL table to create the "ISAM" model. You don't make direct calls to low-level subroutines. Instead, you submit a query, and SQLite does the hard work for you. It has a "very solid" shared-file implementation that works on and across all platforms, and "it just works." You will find that your replacement code is much simpler than what Berkely required.

Bear in mind that: "transactions" are very important when working with SQLite. This is what will give you the "'lazy' read/write" behavior that you are probably used to. Without it, SQLite will physically commit every write – waiting for it to complete – and will not "buffer" anything when reading. The result is much slower performance than you might otherwise expect. But, it is designed that way. (Most database interfaces provide a convenient "auto-transactions" feature. Use it.) When you do the right thing the right way, SQLite is a speed demon.