Switch Non-Schema Lakehouse to Schema-Enabled in Microsoft Fabric

追加: 2026-06-02

[00:00:00]What if somebody has like many non-schema-enabled lakehouses and they would really want to start to use like schema-enabled lakehouses and they would like to migrate over? Are there like really any options to do that or would they have to create completely new lakehouses and migrate or how that would happen?

[00:00:20]>> We have some approach, but it's not a migration from one lakehouse to another. What we have instead is like update of existing lakehouse to make it schema-enabled. So, this update is happening in place. We're not creating a new lakehouses.

[00:00:40]So, the process uses two scripts. As you can see on the screen, these scripts are notebook scripts.

[00:00:49]And the first one moves tables in non-schema lakehouse from tables folder into tables DBO folder, basically making your tables be placed where it should be placed as it would be schema-enabled lakehouse.

[00:01:09]So, if we run that script >> Okay, and you're now running the script for some non-schema-enabled lakehouse there, right?

[00:01:17]>> Yes. So, as you see, the default lakehouse currently attached is non-schema and it has 10 tables.

[00:01:25]Um and the script itself runs very fast and gives you the result. Um The change is nearly instant regardless of the file size or a table size because the it's only updates pointers to files in ADLS Gen2.

[00:01:47]And that update gets instantly. So, if we now look at and refresh our non-schema lakehouse, you see that all of the tables disappeared and they are put into unidentified folder, virtual folder, under DBO. The reason for that is that also all tables already moved to DBO schema, this lakehouse by lakehouse explorer is still being recognized as non-schema lakehouse because we haven't changed its extended property. And that's what for we have a second script. So, the second script when we run it, it all it does it's um calls a certain API which updates extended property for that lakehouse.

[00:02:42]So, let me run it quickly.

[00:02:47]As you see, it's also very fast. And now when it's run, if I go and refresh lakehouse, now as you can see our non-schema lakehouse has a recognizable DBO schema and in this DBO schema it has tables.

[00:03:04]Okay, that's really really cool in my opinion. So, basically everyone could do this in their environments or is there any catches with this or how this would happen? Like is everybody able to do this? So, that particular API has to be white-listed.

[00:03:24]So, we have a form which you need to fill in and then we will enable it for your particular tenant ID.

[00:03:33]You can find the form in aks.ms/lakehouse switch.

[00:03:39]Um once you fill that form, we white-list your tenant ID and that enables you to access that API for um switching uh properties for the lakehouse.

[00:03:54]Um we also, once you fill in that form, provide all the instructions, um other scripts, such as scripts for updating one lake security policies, updating semantic models. Um you don't need to update SQL analytics endpoint because it's already schema enabled, regardless of which lakehouse type you use. Uh data flows also does not need to be updated uh because it uses SQL analytics endpoint to access lakehouse metadata.

[00:04:23]Uh but yeah, we'll provide all instructions after you will fill in the form. Um and there will be some additional steps that customers will need to do. So, for the lakehouse itself, it's just running these two scripts, but then you need to go and refactor your notebook code which references these lakehouses to make sure that now table references um are not using only two part names, but it includes also schema name, DBO. Uh and that's uh basically works with the new lakehouse which just switched from non-schema to schema enabled.

[00:05:03]>> Okay, really cool. Uh what about then like if we think about this from like CI/CD perspective and for example, if we would be using fabric deployment pipelines and like version control and processes, are there any things that need to be considered in that regard or will everything work smoothly?

[00:05:22]>> Uh it's a good question and yes, if you run these scripts and update the lakehouse only at your destination, but not source, uh and then you will try to pull push uh the changes, that will fail. Uh because uh when CI/CD will be checking uh lakehouse extended properties, it will see that it's a different lakehouse at your destination than it was at the source. So, to make sure that it works, you will have to run these scripts both on your source and your destination in CI/CD. And when you do that, everything should be working.

[00:06:01]>> Okay. Yeah, so you need to just make sure that you update those lakehouses in every environment individually and not just basically in dev and then you would just deploy those changes. Okay, that's really good to know.

[00:06:17]Hey, if you found this video insightful, then you definitely want to watch the full video with Ted where we dive into many additional topics like what is the future of non-schema lakehouses and why do we even have two different lakehouses in the first place? You can just click here and start to watch that video. Now, thanks for watching and see you in the next video.