Hi Bill,

Thanks for your post

"My research into Duckdb led me to conclude that it was best used for OLAP, rather than OLTP, which all of my apps do.
Do you think that OLTP apps would benefit from using duckdb as compared to SQL Server?"

I am not so fond of database categories. But, sure, those columnar engines, Duckdb being the sort of SQLite version, qualify as OLAP. And certainly not OLTP.

What makes Duckdb so special: it is really tiny. Tiny in the way of SQLite. And this brings value in the way, spreadsheets brought value on the workstation in the 80s (and VFP brought some during the nineties). You can start it and feed a one million records in below one second. And way more if you can afford a couple more seconds of your workstation cpu-s. That will take RAM as well. But I know no other workstation technology that will allow any one to set up and browse through the kind of database size that would kill regularo OLTP machine processors.

Duckdb can, in some way, provide to midsized businesses what 'data lakes' provide to banks and internet actors. Smart, I really mean 'smart' data handling. The kind that would kill any kind of OLTP engines.

IMHO though, you have to accept two pillars of big data in this kind of 'data lake' world. First, your feeding data will preferably be stored, part or all of it, as 'parquet resources' (a columnar format). The Arrow project is part of this loop. Csv-s no more... Second, security-wise, you are mostly on your own, at OS level.

I am just entering this world - python "big data" eco-system as I speak with a lot to learn!

Daniel