>>Only from (very interested!) reading: it is a "pure" column DB, typically storing each column as a single file.
>>I think there were hints at two options: storing large parts of columns as streams in same file and defining tuples as stream content, if they are always accessed in that way (think variables of larger DS included in multiple correlation). Did not verify follow up.

Multi-file has been one of the weaknesses of dbf. SQLite by comparison has a single db repository. My pick is that DuckDB like SQLLite is more aimed at single user local temporary data munging, so more like a VFP cursor than dbf.

>>[Security] probably relying on OS security of directory of data files at first, and throwing encryption into RAM access is orthogonal to speed of access ;-))

I can see why this might have value for Python or others without native cursor support like VFP, but IMHO persistent data has to be encrypted to demonstrate secure data for the likes of GDPR or HIPAA. Some years back I saw a US consulting and billing juggernaut effectively destroyed after an employee had stolen from his car, a notebook computer containing un-encrypted patient data.