1 00:00:02,760 --> 00:00:04,950 Today we'll look at the AI integration developer updates 2 00:00:04,950 --> 00:00:06,240 and performance improvements 3 00:00:06,240 --> 00:00:09,570 that make SQL Server 2025 a major upgrade. 4 00:00:09,570 --> 00:00:11,250 We've got a lot to unpack here, 5 00:00:11,250 --> 00:00:13,200 so we're going to waste no time and get straight into this 6 00:00:13,200 --> 00:00:14,610 with lead SQL engineer, Bob Ward. 7 00:00:14,610 --> 00:00:15,570 Welcome back to the show. 8 00:00:15,570 --> 00:00:16,710 - So great to be back. 9 00:00:16,710 --> 00:00:18,930 - So SQL Server 2025, it's brand new. 10 00:00:18,930 --> 00:00:20,220 It's in public preview right now. 11 00:00:20,220 --> 00:00:22,680 So what's behind the release and what's new? 12 00:00:22,680 --> 00:00:25,350 - There are three major areas of updates 13 00:00:25,350 --> 00:00:27,090 that we focus on in this release. 14 00:00:27,090 --> 00:00:29,190 First, we have deep AI integration. 15 00:00:29,190 --> 00:00:32,160 For example, we now have built-in vector search support 16 00:00:32,160 --> 00:00:34,260 for more accurate and efficient data retrieval 17 00:00:34,260 --> 00:00:37,380 with some under the hood optimizations using DiskANN. 18 00:00:37,380 --> 00:00:38,880 Second, if you're a developer, 19 00:00:38,880 --> 00:00:40,910 this is the most significant release of SQL 20 00:00:40,910 --> 00:00:42,690 in the last decade. 21 00:00:42,690 --> 00:00:43,523 You know, some of the highlights 22 00:00:43,523 --> 00:00:46,140 are native support for JSON files 23 00:00:46,140 --> 00:00:48,210 and new change event streaming capabilities 24 00:00:48,210 --> 00:00:49,980 for real-time updates. 25 00:00:49,980 --> 00:00:52,320 And the third area is improved analytics, 26 00:00:52,320 --> 00:00:53,490 where we're going to make it easy 27 00:00:53,490 --> 00:00:56,070 to mirror your SQL Servers into Microsoft Fabric 28 00:00:56,070 --> 00:00:57,450 without moving the data. 29 00:00:57,450 --> 00:00:58,920 - And all of these are very significant updates. 30 00:00:58,920 --> 00:01:01,650 So why don't we start with what's new in search and AI? 31 00:01:01,650 --> 00:01:02,940 - Great, let's get going. 32 00:01:02,940 --> 00:01:05,010 As I've mentioned, we've integrated AI 33 00:01:05,010 --> 00:01:06,600 directly into the database engine 34 00:01:06,600 --> 00:01:08,910 to give you smarter, intelligent searching. 35 00:01:08,910 --> 00:01:11,040 With vector search capabilities built-in, 36 00:01:11,040 --> 00:01:13,500 you can do semantic search over your data 37 00:01:13,500 --> 00:01:17,340 to find matches based on similarity versus keywords. 38 00:01:17,340 --> 00:01:19,380 For example, here I have a database 39 00:01:19,380 --> 00:01:21,840 with a table called ProductDescription, 40 00:01:21,840 --> 00:01:24,330 and I want to search using SQL queries 41 00:01:24,330 --> 00:01:27,660 against the Description table for intelligent search. 42 00:01:27,660 --> 00:01:30,420 Typically, you'd use full text search for this. 43 00:01:30,420 --> 00:01:31,830 Now I've built this out, 44 00:01:31,830 --> 00:01:34,050 but what about these natural language phrases, 45 00:01:34,050 --> 00:01:35,610 Will they work? 46 00:01:35,610 --> 00:01:36,630 They don't. 47 00:01:36,630 --> 00:01:40,590 And even when I use like clauses, as you can see here, 48 00:01:40,590 --> 00:01:43,410 or contains, or even freetext, 49 00:01:43,410 --> 00:01:46,320 none of these methods returns what I'm looking for. 50 00:01:46,320 --> 00:01:48,120 Instead, this is where natural language 51 00:01:48,120 --> 00:01:51,840 with vector search in SQL Server 2025 shines. 52 00:01:51,840 --> 00:01:53,640 As a developer, I can get started 53 00:01:53,640 --> 00:01:56,043 even locally on my laptop, no GPU required. 54 00:01:56,880 --> 00:01:58,860 I'm using the popular framework, Ollama, 55 00:01:58,860 --> 00:02:01,140 to host a free open-source embeddings model 56 00:02:01,140 --> 00:02:02,610 from Hugging Face. 57 00:02:02,610 --> 00:02:04,920 This will convert our data into vectors, 58 00:02:04,920 --> 00:02:06,870 including query prompts, 59 00:02:06,870 --> 00:02:10,980 and I declare it using this CREATE EXTERNAL MODEL statement. 60 00:02:10,980 --> 00:02:13,290 Then I'm able to go in and build a table 61 00:02:13,290 --> 00:02:15,270 using the new built-in vector type 62 00:02:15,270 --> 00:02:17,920 to store what's called embeddings in a binary format. 63 00:02:18,840 --> 00:02:22,410 My table has keys pointing back to my description data 64 00:02:22,410 --> 00:02:24,720 and then I can use a built-in T-SQL function 65 00:02:24,720 --> 00:02:28,830 to generate embeddings based on Ollama and store them. 66 00:02:28,830 --> 00:02:32,220 For vector search to work, I need to create a vector index, 67 00:02:32,220 --> 00:02:34,230 and it's also performance optimized 68 00:02:34,230 --> 00:02:37,680 using Disk approximate nearest neighbor, or DiskANN, 69 00:02:37,680 --> 00:02:39,570 which is a new way to offload 70 00:02:39,570 --> 00:02:42,660 what you'd normally want to run completely in memory 71 00:02:42,660 --> 00:02:44,673 to point to an index stored on disk. 72 00:02:45,540 --> 00:02:46,770 I have a stored procedure 73 00:02:46,770 --> 00:02:49,650 to convert the query prompts into embeddings 74 00:02:49,650 --> 00:02:52,080 so it can be used to find matching embeddings 75 00:02:52,080 --> 00:02:53,880 in the vector index. 76 00:02:53,880 --> 00:02:56,640 So now I have everything running locally on my laptop 77 00:02:56,640 --> 00:02:57,690 running SQL. 78 00:02:57,690 --> 00:02:59,550 Let's see how it works. 79 00:02:59,550 --> 00:03:01,290 I'll try this natural language prompt, 80 00:03:01,290 --> 00:03:02,670 like I showed earlier. 81 00:03:02,670 --> 00:03:03,503 And it worked. 82 00:03:03,503 --> 00:03:05,220 I get a rich set of results, 83 00:03:05,220 --> 00:03:07,530 with matching information based on my search 84 00:03:07,530 --> 00:03:10,050 to find products in the database. 85 00:03:10,050 --> 00:03:12,390 And I can even use Copilot from here 86 00:03:12,390 --> 00:03:14,820 to explore more about SQL data. 87 00:03:14,820 --> 00:03:17,310 I'll prompt it to look for my new table. 88 00:03:17,310 --> 00:03:20,610 And you can see, response here, finding our new table. 89 00:03:20,610 --> 00:03:23,250 And I can ask it to pull up a few embedding values 90 00:03:23,250 --> 00:03:25,620 with product names and descriptions. 91 00:03:25,620 --> 00:03:28,740 And as you saw the result using our open source embeddings 92 00:03:28,740 --> 00:03:30,780 returned a few languages back. 93 00:03:30,780 --> 00:03:31,680 And the good news 94 00:03:31,680 --> 00:03:33,870 is that if your data contains multiple languages, 95 00:03:33,870 --> 00:03:36,510 it's easy to use different embedding models. 96 00:03:36,510 --> 00:03:37,343 For example, 97 00:03:37,343 --> 00:03:40,260 here I've wired up Azure OpenAI's ADA 2 embeddings model 98 00:03:40,260 --> 00:03:41,670 optimized for multiple languages 99 00:03:41,670 --> 00:03:43,500 without even changing my code. 100 00:03:43,500 --> 00:03:46,740 And now I can even search using Mandarin Chinese 101 00:03:46,740 --> 00:03:48,600 and get back matching results. 102 00:03:48,600 --> 00:03:49,890 - And DiskANN and vector-based search 103 00:03:49,890 --> 00:03:52,230 are both massive updates that really go hand in hand 104 00:03:52,230 --> 00:03:54,360 to enable better natural language querying 105 00:03:54,360 --> 00:03:55,440 on modest hardware. 106 00:03:55,440 --> 00:03:57,660 So what about all the developer updates? 107 00:03:57,660 --> 00:03:58,493 - With these updates, 108 00:03:58,493 --> 00:04:00,960 things get so much more efficient for developers. 109 00:04:00,960 --> 00:04:02,280 With JSON file types, 110 00:04:02,280 --> 00:04:05,490 you can bring NoSQL into your SQL relational database. 111 00:04:05,490 --> 00:04:07,020 Let me show you how. 112 00:04:07,020 --> 00:04:08,970 I've created a database called Orders 113 00:04:08,970 --> 00:04:10,620 and a table called Orders. 114 00:04:10,620 --> 00:04:12,750 Notice here the new JSON data type, 115 00:04:12,750 --> 00:04:15,330 which can store up to a massive two gigabytes 116 00:04:15,330 --> 00:04:18,420 of JSON document in this native data type. 117 00:04:18,420 --> 00:04:20,640 Now let's look at a couple of examples. 118 00:04:20,640 --> 00:04:23,520 First, I can easily insert JSON documents 119 00:04:23,520 --> 00:04:25,860 in their native format directly into the table, 120 00:04:25,860 --> 00:04:29,340 and I'll show you some of the JSON functions that you can do 121 00:04:29,340 --> 00:04:31,830 to process this new JSON type. 122 00:04:31,830 --> 00:04:34,230 JSON value will pull a particular value 123 00:04:34,230 --> 00:04:35,820 out of a JSON document 124 00:04:35,820 --> 00:04:38,013 and bring it back in result set format. 125 00:04:38,850 --> 00:04:41,310 And I can just dump out all the JSON values, 126 00:04:41,310 --> 00:04:44,430 so each document will appear as a separate row 127 00:04:44,430 --> 00:04:46,530 in their native JSON format. 128 00:04:46,530 --> 00:04:50,130 But instead of just doing that, I have aggregate functions. 129 00:04:50,130 --> 00:04:53,100 This takes all the rows of JSON types in the table 130 00:04:53,100 --> 00:04:56,730 and produces a single array with a single JSON document 131 00:04:56,730 --> 00:04:59,313 with all the new rows in the native JSON type. 132 00:05:00,240 --> 00:05:02,460 Key-value pairs are also popular in JSON, 133 00:05:02,460 --> 00:05:05,160 and I can use the new OBJECT AGGREGATE function 134 00:05:05,160 --> 00:05:08,100 to take the order ID key and the JSON document 135 00:05:08,100 --> 00:05:11,070 and produce a set of key-value pairs. 136 00:05:11,070 --> 00:05:14,970 And I can modify the JSON type directly from here too. 137 00:05:14,970 --> 00:05:19,290 Notice, for order_id 1, the quantity is also 1. 138 00:05:19,290 --> 00:05:21,240 I'll run this update to modify the value. 139 00:05:21,240 --> 00:05:24,000 And when it's finished, the order_id, quantity 140 00:05:24,000 --> 00:05:28,020 has been updated with the value of 2 directly in the JSON. 141 00:05:28,020 --> 00:05:30,870 Now that's a good example of using the JSON type. 142 00:05:30,870 --> 00:05:35,010 So let me show you how this works with a JSON index. 143 00:05:35,010 --> 00:05:37,200 I've got a different database for contacts, 144 00:05:37,200 --> 00:05:39,240 along with the table for contacts 145 00:05:39,240 --> 00:05:41,970 using a JSON document as one of the properties 146 00:05:41,970 --> 00:05:43,980 of the contacts table. 147 00:05:43,980 --> 00:05:46,585 I can create a JSON index on top of that JSON document, 148 00:05:46,585 --> 00:05:47,673 like this. 149 00:05:48,510 --> 00:05:51,570 Now I've got some sample data that are JSON documents. 150 00:05:51,570 --> 00:05:55,680 And in a second, I'm going to push those into our database. 151 00:05:55,680 --> 00:05:56,670 And as I scroll, 152 00:05:56,670 --> 00:05:59,400 you'll that this has nested tags as properties 153 00:05:59,400 --> 00:06:00,723 in the JSON document. 154 00:06:01,650 --> 00:06:03,780 Now I'll run the query so I can insert these rows 155 00:06:03,780 --> 00:06:05,640 with the names of each tag. 156 00:06:05,640 --> 00:06:07,140 Let's go look at the output. 157 00:06:07,140 --> 00:06:09,390 I'm using JSON value for the name, 158 00:06:09,390 --> 00:06:13,380 but I'm using JSON query because the tags are nested. 159 00:06:13,380 --> 00:06:16,680 Now I'll show you an example searching with the JSON index. 160 00:06:16,680 --> 00:06:19,350 I'm using the new JSON contains function 161 00:06:19,350 --> 00:06:21,300 to find tags called fitness 162 00:06:21,300 --> 00:06:23,670 that are deep nested in the JSON document. 163 00:06:23,670 --> 00:06:26,220 And I can run that and find the right tags 164 00:06:26,220 --> 00:06:28,290 and even the execution plan. 165 00:06:28,290 --> 00:06:29,850 You can see here that it shows 166 00:06:29,850 --> 00:06:31,740 we're using the new JSON index 167 00:06:31,740 --> 00:06:33,330 to help go find that information. 168 00:06:33,330 --> 00:06:34,163 - That's a big deal. 169 00:06:34,163 --> 00:06:36,990 And like you said, there's a lot happening natively in JSON, 170 00:06:36,990 --> 00:06:39,420 and now you've got the benefits of SQL for joins, 171 00:06:39,420 --> 00:06:41,197 and security, and a lot more, 172 00:06:41,197 --> 00:06:44,130 - You know, and for developers who use change data capture, 173 00:06:44,130 --> 00:06:47,460 things become a lot easier with change event streaming. 174 00:06:47,460 --> 00:06:49,320 Here, we're reducing I/O overhead 175 00:06:49,320 --> 00:06:51,300 and sending transaction log changes 176 00:06:51,300 --> 00:06:52,983 directly to your application. 177 00:06:53,850 --> 00:06:55,530 To get started with change event streaming 178 00:06:55,530 --> 00:06:57,210 for our orders database, 179 00:06:57,210 --> 00:06:58,440 I'll run the stored procedure 180 00:06:58,440 --> 00:07:00,990 to enable streaming for the database. 181 00:07:00,990 --> 00:07:02,700 You can see the table we're going to use 182 00:07:02,700 --> 00:07:05,730 to track changes is a typical type of orders table. 183 00:07:05,730 --> 00:07:08,460 Here I've created what's called an event stream group. 184 00:07:08,460 --> 00:07:10,290 This is where I've configured event streaming 185 00:07:10,290 --> 00:07:13,200 to tell it the location of our Azure event hub 186 00:07:13,200 --> 00:07:16,470 to stream our data, and I've added my credentials. 187 00:07:16,470 --> 00:07:18,210 Then I've configured the table orders 188 00:07:18,210 --> 00:07:21,510 to be part of the event streaming group. 189 00:07:21,510 --> 00:07:22,500 I've run these procedures 190 00:07:22,500 --> 00:07:25,320 to make sure that my configuration is correct. 191 00:07:25,320 --> 00:07:26,700 So let's do something interesting. 192 00:07:26,700 --> 00:07:29,010 I'm going to automate a workflow using agents 193 00:07:29,010 --> 00:07:31,350 to listen for changes as they come in 194 00:07:31,350 --> 00:07:33,690 and try to resolve any issues. 195 00:07:33,690 --> 00:07:36,240 First, I've created an Azure function app, 196 00:07:36,240 --> 00:07:37,500 and using my function app, 197 00:07:37,500 --> 00:07:39,870 I have an agent running in the Azure AI service 198 00:07:39,870 --> 00:07:42,090 called ContosoShippingAgent. 199 00:07:42,090 --> 00:07:45,060 It's built to take shipment information, analyze it, 200 00:07:45,060 --> 00:07:47,790 and decide whether something can be done to help. 201 00:07:47,790 --> 00:07:50,760 For example, resolving a shipping delay. 202 00:07:50,760 --> 00:07:52,770 I've started my Azure function. 203 00:07:52,770 --> 00:07:54,300 This function is waiting for events 204 00:07:54,300 --> 00:07:57,513 to be sent to Azure Event Hub in order to process them. 205 00:07:58,620 --> 00:08:01,443 Now, in SQL, I'll insert a new order. 206 00:08:02,430 --> 00:08:04,470 Going back over to my Azure function, 207 00:08:04,470 --> 00:08:06,370 you'll see how the event is processed. 208 00:08:07,290 --> 00:08:10,020 In the code, first, we're dumping up the raw cloud event 209 00:08:10,020 --> 00:08:11,880 that I showed earlier. 210 00:08:11,880 --> 00:08:14,100 Notice the operation is an insert. 211 00:08:14,100 --> 00:08:15,210 It's going to dump out 212 00:08:15,210 --> 00:08:17,580 some of the different fields we've parsed out of the data, 213 00:08:17,580 --> 00:08:20,700 the column names, the metadata, and then the row itself. 214 00:08:20,700 --> 00:08:23,010 Notice that because the shipment is 75 days 215 00:08:23,010 --> 00:08:26,610 greater than our sales date, it will call our agent. 216 00:08:26,610 --> 00:08:29,460 The agent then comes back with a response. 217 00:08:29,460 --> 00:08:30,930 It looked at the tracking details 218 00:08:30,930 --> 00:08:33,600 and determined that it can change the shipping provider 219 00:08:33,600 --> 00:08:35,700 to expedite our delayed shipment, 220 00:08:35,700 --> 00:08:38,040 and it contacted the customer directly 221 00:08:38,040 --> 00:08:39,570 with the updating shipping info. 222 00:08:39,570 --> 00:08:40,830 - And everybody likes faster shipping. 223 00:08:40,830 --> 00:08:42,780 So speaking of things that are getting faster, 224 00:08:42,780 --> 00:08:44,010 it's kind of a tradition on Mechanics 225 00:08:44,010 --> 00:08:45,720 that we cover the speed ups for SQL Server. 226 00:08:45,720 --> 00:08:47,100 So what are the speed ups 227 00:08:47,100 --> 00:08:49,320 and the performance optimizations for '25? 228 00:08:49,320 --> 00:08:50,520 - Well, there's a lot, 229 00:08:50,520 --> 00:08:53,310 but my favorite one improves application concurrency. 230 00:08:53,310 --> 00:08:54,600 We've improved the internals 231 00:08:54,600 --> 00:08:57,450 of how locking works without application code changes. 232 00:08:57,450 --> 00:09:00,030 And I've got an example of this running. 233 00:09:00,030 --> 00:09:02,790 I have a lock escalation problem that I need to resolve. 234 00:09:02,790 --> 00:09:05,640 I'm going to go update about 2,500 rows in this table 235 00:09:05,640 --> 00:09:09,780 just to show what happens, then how we've solved for it. 236 00:09:09,780 --> 00:09:12,090 So running this query against that Dynamic Management View, 237 00:09:12,090 --> 00:09:15,060 or DMV, shows locks that have accumulated, 238 00:09:15,060 --> 00:09:17,790 about 2,500 locks here for key-value locks 239 00:09:17,790 --> 00:09:20,730 and 111 for page locks. 240 00:09:20,730 --> 00:09:23,430 So what happens if I run enough updates against the table 241 00:09:23,430 --> 00:09:25,230 that would cause a lock escalation? 242 00:09:25,230 --> 00:09:28,050 Here, I'll update 10,000 rows in the system. 243 00:09:28,050 --> 00:09:29,610 But you can see with the locks 244 00:09:29,610 --> 00:09:32,610 that this has been escalated to an object lock. 245 00:09:32,610 --> 00:09:33,990 It's not updating the entire table, 246 00:09:33,990 --> 00:09:36,330 but it's going to cause a problem. 247 00:09:36,330 --> 00:09:38,100 Because I've got a query over here 248 00:09:38,100 --> 00:09:40,860 that can update the maximum value in just one row 249 00:09:40,860 --> 00:09:44,610 and it's going to get blocked, but it shouldn't have to be. 250 00:09:44,610 --> 00:09:47,010 You can see here from the blocking query that's running 251 00:09:47,010 --> 00:09:49,530 that it's blocked on that original session, 252 00:09:49,530 --> 00:09:50,820 and I'm not actually updating a row 253 00:09:50,820 --> 00:09:52,500 that's affected by the first one. 254 00:09:52,500 --> 00:09:54,660 This is the problem with lock escalation. 255 00:09:54,660 --> 00:09:57,300 Now let's look at a new option called optimized locking 256 00:09:57,300 --> 00:09:59,460 in SQL Server 2025. 257 00:09:59,460 --> 00:10:02,550 Okay, let's go back to where I updated 10,000 rows 258 00:10:02,550 --> 00:10:04,410 and look at the lock. 259 00:10:04,410 --> 00:10:05,790 Notice how in this particular case 260 00:10:05,790 --> 00:10:07,470 I have a transaction lock. 261 00:10:07,470 --> 00:10:09,780 It's an intent exclusive lock for the table, 262 00:10:09,780 --> 00:10:12,870 but only a transaction lock for that update. 263 00:10:12,870 --> 00:10:15,000 If I use this query to update the max, 264 00:10:15,000 --> 00:10:17,100 you'll see that we are not blocked. 265 00:10:17,100 --> 00:10:18,510 And by looking at the locks, 266 00:10:18,510 --> 00:10:21,000 each item has specific transaction locks, 267 00:10:21,000 --> 00:10:23,010 so we're not blocking each other. 268 00:10:23,010 --> 00:10:25,770 And related to this, we've also solved another problem 269 00:10:25,770 --> 00:10:27,930 where two unrelated updates can get blocked. 270 00:10:27,930 --> 00:10:29,730 We call this lock after qualification. 271 00:10:29,730 --> 00:10:31,680 - Okay, so it's pinpointing the exact lock type, 272 00:10:31,680 --> 00:10:33,270 so you'll get less locks in the end. 273 00:10:33,270 --> 00:10:36,120 So why don't we move on though from locks to joins? 274 00:10:36,120 --> 00:10:37,020 - Sure. 275 00:10:37,020 --> 00:10:38,700 With Microsoft Fabric, it's amazing. 276 00:10:38,700 --> 00:10:40,530 You can pull in multiple databases, 277 00:10:40,530 --> 00:10:44,160 multiple data types into a unified data platform. 278 00:10:44,160 --> 00:10:46,260 Imagine you have two different SQL Servers 279 00:10:46,260 --> 00:10:48,120 in different clouds and on-prem, 280 00:10:48,120 --> 00:10:51,330 and you just want to join this data together in an easy way 281 00:10:51,330 --> 00:10:52,440 without migrating it. 282 00:10:52,440 --> 00:10:54,660 With Fabric, you can. 283 00:10:54,660 --> 00:10:58,140 I have a SQL Server 2022 instance with a database, 284 00:10:58,140 --> 00:11:00,180 and we've already mirrored the product tables 285 00:11:00,180 --> 00:11:02,190 from that database into Fabric. 286 00:11:02,190 --> 00:11:04,110 I'll show you the mirroring configuration process 287 00:11:04,110 --> 00:11:07,080 for a SQL Server 2025 instance with different, 288 00:11:07,080 --> 00:11:08,490 but related tables. 289 00:11:08,490 --> 00:11:09,930 These are similar to the steps 290 00:11:09,930 --> 00:11:11,880 from mirroring any SQL Server. 291 00:11:11,880 --> 00:11:15,033 I've created a database connection for SQL Server 2025. 292 00:11:15,990 --> 00:11:19,260 Now I'll pick all the tables in our database and connect. 293 00:11:19,260 --> 00:11:22,440 I'll leave the name as is, AdventureWorks, 294 00:11:22,440 --> 00:11:25,200 and we're ready to mirror our database. 295 00:11:25,200 --> 00:11:27,810 You can see now that the replication process has started 296 00:11:27,810 --> 00:11:28,953 for all the tables. 297 00:11:29,820 --> 00:11:31,350 All the rows have been replicated 298 00:11:31,350 --> 00:11:34,020 for all the columns on all the tables in my database 299 00:11:34,020 --> 00:11:36,420 and they've been mirrored into Fabric. 300 00:11:36,420 --> 00:11:40,140 Now let's query the data using the SQL analytic endpoint. 301 00:11:40,140 --> 00:11:41,820 And you can see that the tables 302 00:11:41,820 --> 00:11:45,000 that we have previously had in our database and SQL Server 303 00:11:45,000 --> 00:11:47,580 are now mirrored into OneLake. 304 00:11:47,580 --> 00:11:51,090 Let's run a query and I'll use Copilot to do that. 305 00:11:51,090 --> 00:11:53,820 Here's the Copilot code with explanations. 306 00:11:53,820 --> 00:11:55,350 Now I'll run it. 307 00:11:55,350 --> 00:11:58,950 And as it completes, there's our top customers buy sales. 308 00:11:58,950 --> 00:12:00,630 Now what if we wanted to do a join 309 00:12:00,630 --> 00:12:02,670 across the other SQL server? 310 00:12:02,670 --> 00:12:03,600 It's possible. 311 00:12:03,600 --> 00:12:07,080 But normally, there are a lot of manual pieces to do this. 312 00:12:07,080 --> 00:12:10,440 Fabric can make that easier using a lakehouse. 313 00:12:10,440 --> 00:12:12,330 So let's create a new lakehouse. 314 00:12:12,330 --> 00:12:14,700 I just didn't to give it a name, AdventureWorks, 315 00:12:14,700 --> 00:12:16,290 and confirm. 316 00:12:16,290 --> 00:12:18,900 Now notice there are no tables in this lakehouse yet, 317 00:12:18,900 --> 00:12:20,130 so let's add some. 318 00:12:20,130 --> 00:12:22,800 And for that, I'll use a shortcut. 319 00:12:22,800 --> 00:12:24,840 A shortcut uses items in OneLake, 320 00:12:24,840 --> 00:12:27,780 like the SQL Server databases we just mirrored. 321 00:12:27,780 --> 00:12:30,660 So I'll add the AdventureWorks database. 322 00:12:30,660 --> 00:12:33,840 And scrolling down, I'll pick all the tables I want. 323 00:12:33,840 --> 00:12:35,100 Now I'll create it. 324 00:12:35,100 --> 00:12:37,800 And we're not storing the data separately in the lakehouse. 325 00:12:37,800 --> 00:12:38,850 It's just a shortcut, 326 00:12:38,850 --> 00:12:41,670 like an active read link to the source data, 327 00:12:41,670 --> 00:12:43,170 which is our mirrored database, 328 00:12:43,170 --> 00:12:46,740 and therefore something that already exists in OneLake. 329 00:12:46,740 --> 00:12:49,890 And now you can see I've got these objects here. 330 00:12:49,890 --> 00:12:54,240 This icon means that these are shortcut from another table. 331 00:12:54,240 --> 00:12:57,030 So now, let's get data from another warehouse. 332 00:12:57,030 --> 00:13:00,003 The SQL Server 2022 instance, which was ADW_products. 333 00:13:01,320 --> 00:13:05,880 Again, here, I'll pick the tables that I want and Create. 334 00:13:05,880 --> 00:13:07,170 That's it. 335 00:13:07,170 --> 00:13:09,330 So I can go and look at product 336 00:13:09,330 --> 00:13:11,253 to make sure I've got my product data. 337 00:13:12,180 --> 00:13:15,000 Now, let's try to query this as one database 338 00:13:15,000 --> 00:13:17,040 and use another analytic endpoint 339 00:13:17,040 --> 00:13:19,440 directly against the lakehouse itself. 340 00:13:19,440 --> 00:13:21,390 So basically it thinks all the tables 341 00:13:21,390 --> 00:13:23,853 are just part of the unified schema now. 342 00:13:24,750 --> 00:13:25,890 Let's open up Copilot 343 00:13:25,890 --> 00:13:28,470 and write a prompt to pull my top customers 344 00:13:28,470 --> 00:13:30,300 by products and sales. 345 00:13:30,300 --> 00:13:31,470 And it will be able to work 346 00:13:31,470 --> 00:13:34,110 directly against all of these connected databases 347 00:13:34,110 --> 00:13:37,590 because they are in just the same schema. 348 00:13:37,590 --> 00:13:38,580 And there you go. 349 00:13:38,580 --> 00:13:40,320 I have a list of all the data I need 350 00:13:40,320 --> 00:13:42,120 in one logical database. 351 00:13:42,120 --> 00:13:42,953 - And this is really great. 352 00:13:42,953 --> 00:13:44,220 And I know now that everything's in OneLake, 353 00:13:44,220 --> 00:13:46,980 there's also a lot more that you can do with that data. 354 00:13:46,980 --> 00:13:48,690 - With the lakehouse, the sky's the limit. 355 00:13:48,690 --> 00:13:51,180 You can use Power BI, or any of those services 356 00:13:51,180 --> 00:13:53,610 that are in the unified data platform, Microsoft Fabric. 357 00:13:53,610 --> 00:13:55,320 - Okay, so now we've seen all the updates 358 00:13:55,320 --> 00:13:57,480 with SQL Server 2025. 359 00:13:57,480 --> 00:13:58,313 To everyone watching, 360 00:13:58,313 --> 00:14:00,180 what's the best thing they can do to get started? 361 00:14:00,180 --> 00:14:03,330 - Well, the first thing is to start using it. 362 00:14:03,330 --> 00:14:06,150 SQL Server 2025 is ready for you to download 363 00:14:06,150 --> 00:14:08,520 and install it on the platform of your choice. 364 00:14:08,520 --> 00:14:13,500 You'll find it at aka.ms/GetSQLServer2025. 365 00:14:13,500 --> 00:14:15,210 - So thanks so much for sharing all the updates, Bob, 366 00:14:15,210 --> 00:14:17,040 and thank you for joining us today. 367 00:14:17,040 --> 00:14:21,707 Be sure to subscribe for more, and we'll see again soon.