@Chinmay Phadke @Will Needham Interesting to start the debate about workarounds or rigth way to do all of this point. A new thread @Will Needham ?

@Chinmay Phadke my thoutghs / comments: 1) I am reading incremental data from a Lakehouse to the warehouse: 1.1) From Sql Server on-prem, I flag the incremental data. you can use CDC, or your own method. 1.2) Using Copy activity I am calling a Store procedure into the on-prem database, this store proc only brings the incremental data into a Lakehouse table. 1.3) Using a Store proc in a warehouse I am inserting/updating the incremental data into the large table. 2) you can use Dataflow Gen2 same way as the point 1) 3) using the abfss with the right security as you mention is the workaround. Youd can read files from many sources, one of them is the lakehouses. 4) As I use warehouse for Silver + Gold layer (Lakehouse for Bronze), then, I call a store procedure into the Warehouse, and here, you have the update options (I load the data from on-prem to a lakehouse table using copy activity, and then I call a Store proc into a warehouse to clean and upsert the data). 5) Workarround. use more lakehouses. I agree that Schema is needed on lakehouse for better organization. 6) I agree. This is pain point. I suppose Microsoft will fix this ASAP. If you create first the table into a specific schema, then you can see that table into the Dataflow Gen2 (it needs additional effort to create the table first). 7) you can use copy activity to load the data from on-prem to the lakehouse (to a file or a table), and use pyspark to process this information (you can sync this using pipelines) 9) Views will fall back the Direct lake connection to Direct Query. It is only available to SQL Endpoint. 10) RLS will fall back the Direct lake connection to Direct Query. Something to be improve by Microsoft. 11) A lot of benefis with Direct lake. You can pre-warm the data and the performance will be similar to import. 12) I didn't know that. Something to be improve by Microsoft 13 to 18) I didnt know this restrictions.. thanks for sharing.

This option will replace in some case the use of the ADLS, and with Fabric P1/F64 we have until 1Terabyte include into the prices for all uses (including the files into the lakehouse).

I don't have the option yet

Amazing news.. Now, we can use Azure DevOps to control the source of all the objects!!!

As I know, we need to drop and create... I think, you can try to use a store proc to dump the data into a temporal table, drop and create the new table with the new types, and after that move the data back..