BTW, your questions are exactly those that I've been ask over the last few months, but also with a lot of focus over the last few days. Still learning as much as I can so the following might not be true.
For what it's worth, there's a difference between using duckdb to query a set of files vs loading a bunch of files in to a table. But once the data has been loaded into a table it can be backed up as a duckdb db file.
Therefore it might be more performant to preprocess duckdb db files (perhaps a process that works in conjunction with whatever manages your external tables) and load these db files into duckdb as needed (on the fly analysis) instead of loading datafiles into duckdb, transforming and CTAS every time.
https://duckdb.org/docs/sql/statements/attach
Of course all of this might be introducing more latency esp if you're trying to do NRT analytics.
I assume you could partition your data into multiple db files similar to how you would probably do it with your data files (managing external tables).
https://www.arecadata.com/getting-started-with-iceberg-using...
You would still need to interact with some kind of catalogue to understand which .db files you need to fetch.
And honestly I don't really know or understand the performance implications of the attach command.
I'm excited to see if the duckdb team will be able to integrate with external tables directly one day. (not that data files would be .db files)
Imagine this:
1) you have an external managed external table (iceberg, delta, etc... managed by Glue, databricks, etc)
2) register this table in duckdb
CREATE OR REPLACE EXTERNAL TABLE my_table ... TYPE = 'ICEBERG' CATALOG = 's3://...' CREDENTIALS = '...' etc
3) simply interact with table in duckdb as you would any other table