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'
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.
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/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.