> large enough to sustain a product this critical down the road? This may not be a 'product' per se. also, these libraries tend to be small and self containe

> large enough to sustain a product this critical down the road? This may not be a 'product' per se. also, these libraries tend to be small and self contained and little changing over time. See also: https://svnweb.freebsd.org/base/release/12.0.0/lib/libc/db/changelog?revision=341707&view=markup https://svnweb.freebsd.org/base/release/12.0.0/lib/libc/db/c... for a view into the original berkeley db as still incorporated in freebsd base (BSD Berkeley DB v1; not the later lineage by same authors which led to sleepycat / oracle Berkeley DB). > Why not make an extension or fork postgres to demonstrate your concept? this isn't that kind of database. this is a k/v store optimized around a particular use case, k/v stores being what is more traditionally considered 'database' before the term 'database' colloquially implied 'relational database managment system' (RDBMS - e.g. a system to manage your k/v database files relationally..) well, techincally 'database' is any 'base of data'. but.. yes. 'base of data' -> 'k/v store' -> 'rdbms' See also: isam,dbm,bdb,cdb,gdbm,tdb,tokyo cabinet,kyoto cabinet,etc. concievably, if desired, one would take this library and integrate it into a higher level application, whether that be a custom application datastore, or a new backend for something like postgres.