In part 1, UUIDv7 did not fix the page density of a GUID clustered index in SQL Server. SQL Server sorts uniqueidentifier values starting from the last six bytes, which are random in a UUIDv7, so new rows land anywhere in the index. After 25,000 single-row inserts, the UUIDv7 and NEWID() indexes were both ~68 % full, close to the 69 % expected for random inserts into a B-tree, against ~98 % for NEWSEQUENTIALID().

Since then, automatic index compaction has become generally available in Azure SQL Database. This post checks whether it closes that gap.

This is deliberately an unfavorable case for the feature. A random clustering key on a small table under steady inserts is close to the worst workload for page density. It is also a case that is spreading in production, as more applications generate GUID or UUIDv7 keys on their side.

Automatic index compaction in short

My colleague Amine Haloui covered the feature in two posts: part 1 explains the difference between page density and fragmentation, part 2 shows how compaction works with a demo. The short version:

Automatic index compaction runs inside the persistent version store cleaner of Accelerated Database Recovery. It visits recently modified pages, moves rows from the next page into a page that has free space, and deallocates the pages that end up empty. You enable it per database with ALTER DATABASE ... SET AUTOMATIC_INDEX_COMPACTION = ON, without a restart.

It only acts on pages modified after it was enabled, does not move rows into the space reserved by the fill factor (nor free it once inserts have used it), does not reduce fragmentation and does not update statistics.

It has been generally available since September 2026 on Azure SQL Database, Azure SQL Managed Instance with the always-up-to-date update policy, and SQL database in Fabric. It is not in SQL Server 2025 on-premises, so all the tests below run on Azure SQL Database.

In short: when inserts pause, it closes most of the gap. While they keep coming, it cannot fix the underlying problem, a key that sends inserts to random positions. At the default fill factor the index even ends up larger than without compaction, and a lower fill factor limits the effect. Measuring page splits shows why: each compaction pass is followed by a wave of splits.

What has already been shown

I found two representative public tests. In both the clustering key is ordered (Microsoft’s test table has a NEWID() column, but not in the key) and the empty space comes from deletes or from a workload that then stops:

Sources: Microsoft announcement post, Amine Haloui part 2.

In both cases, compaction brings page density back to about 95 % with no maintenance job. This post looks at the case these tests leave out: a random key under steady inserts.

Lab setup

Two Azure SQL databases on the same server, General Purpose serverless, 2 vCores: GuidLab_On with compaction, GuidLab_Off as the control. Every test runs in both at the same time. The tables are those of part 1: a uniqueidentifier clustered primary key filled by NEWID(), a UUIDv7 (RFC 9562) or NEWSEQUENTIALID(), plus a char(100) payload, with rows inserted one per statement.

Each run preloads 5,000 rows per table. The occasional-insert run then measures every 10 seconds for 3 minutes. The continuous-insert runs wait 2 minutes, insert a burst every 10 seconds for 3 minutes, then measure one more minute without inserts. Two parameters vary: the fill factor (100, 90 or 80) and the burst size, 300 rows (6 % of the table) or 50 rows (1 %). Pages and fullness come from sys.dm_db_index_physical_stats in DETAILED mode, rows moved from the compaction_row_move_count column of sys.dm_db_index_operational_stats.

Occasional inserts: compaction does the job

5,000 rows inserted, then no more writes, as when inserts come in batches with quiet periods between them.

Without compaction, the index stays at 123 to 128 pages, 67 to 70 % full. With it, it drops to 92 to 94 pages, 91 to 93 % full, in under two minutes, close to the 87 pages of the sequential key. Most of the drop happens in a single pass.

Compaction also moves some rows more than once: 6,345 and 8,991 moves for 5,000 rows.

Continuous inserts, 6 % of the table every 10 seconds

Now 300 rows per table every 10 seconds, 6 % of the table per burst, for three minutes, then one minute without inserts. Each configuration ran at least twice; the figures below cover all runs and both random keys. The chart shows the first run, for UUIDv7.

At fill factor 100, compaction cannot keep up with this pattern. In the first run, the first burst takes the compacted index from 93 to 172 pages. At the end of the inserts it holds 326 to 334 pages, against 253 to 271 without compaction, and average fullness during the inserts is 56 %, against 68 to 70 %. Over the run, compaction moved more than 51,000 rows for a table of 10,400.

The explanation is that an index nobody compacts keeps about 31 % (100 minus 69) free space, which absorbs part of the next inserts. At fill factor 100, compaction moves rows into a page as long as they fit, so most pages are left with little room, and the next random insert splits them. Each split also writes far more log than a plain insert, about 18 times more for rows of similar size in Paul Randal’s test.

A lower fill factor helps. When pages split again soon after compaction, the documentation suggests a fill factor of 70 to 95 %, while noting that most workloads do best at 100, and the index maintenance guidance gives nonsequential GUID keys as its example. At 80, compaction leaves 20 % of each page free, at 90 only 10 %. That free space lets a page absorb a few random inserts before it splits.

At 80, average fullness during the inserts is 76 % in all three runs, against 68 to 70 % without compaction, and one minute after the inserts the index holds 223 to 230 pages, against 253 to 271. The gain is real but modest at this rate. At 90, the margin is too thin: average fullness is 66 to 69 %, and one run ended the inserts with 324 pages, more than without compaction.

Once the inserts stop, fill factor 100 catches up in one pass and ends the smallest: 202 to 207 pages.

Page splits at fill factor 100

To check the explanation above, I ran the 6 % test twice more at fill factor 100 and also recorded two counters from sys.dm_db_index_operational_stats: leaf_allocation_count, the number of leaf pages allocated, and compaction_page_deallocation_count, the number of pages compaction freed. Compaction only moves rows into pages that have room and frees the pages that end up empty, so the allocations come from the inserts. With a random key, new rows land anywhere in the index, so almost every allocation is a page split in the middle of it; with NEWSEQUENTIALID(), rows always go to the end, so every allocation is a new page there.

Without compaction, the 5,400 inserts split about 130 pages. With compaction, about 460: 3.5 times more.

The chart shows where they come from. Compaction ran about once a minute, and each time, the next burst split 78 to 133 pages. The bursts in between split 0 to 21, because the pages split by the previous wave were still half full and could take the new rows. The four bursts that followed a pass account for 90 % of the splits, and the page count follows the same steps.

From the first burst to the end of the run, compaction moved 46,000 to 47,600 rows to free about 350 pages, about 130 rows per page freed. The counters add up: in the first run of this test (UUIDv7), 94 pages at the start, plus 461 allocations, minus 224 pages freed during the inserts, gives the 331 pages measured at the end of the inserts.

Continuous inserts, 1 % of the table every 10 seconds

The same test at 50 rows per burst, 1 % of the table, also run at least twice. The chart shows the first run, for UUIDv7.

Fill factor 100 still degrades. In the first run, the first 50 inserts turned 95 pages into 128: about two inserts in three split a page. The index ends the inserts at 176 to 194 pages, against 143 to 153 without compaction. The lower rate only slows the degradation.

At 90 and 80, compaction helps throughout. Average fullness stays at 81 to 85 %, against 66 to 70 % without compaction, and the index ends at 115 to 121 pages, about 20 % fewer. Fullness never drops below 77 % at 90 and 74 % at 80. The two fill factors end at the same size.

At fill factor 80, the inserts slowly fill the 20 % that compaction leaves free: fullness rose from 73-76 % before the first burst to about 85 % in three minutes. Compaction does not give that space back. As the documentation puts it, “if that reserved space is already filled by the previous data modifications, then compaction doesn’t currently free it up”. Only a rebuild restores the margin.

All results

Each cell gives the range over all runs and both random keys (NEWID() and UUIDv7). The occasional-insert case ran once; its cells read NEWID() / UUIDv7.

Occasional inserts (5,000 rows, then 3 minutes without writes)

Continuous inserts, 6 % per burst (300 rows every 10 s, 10,400 rows at the end)

Continuous inserts, 1 % per burst (50 rows every 10 s, 5,900 rows at the end)

“Rows moved” counts every row compaction moved during the run: after the preload, during the inserts and in the final pass after them. “Pages at the end of the inserts” is a snapshot that depends on when the last compaction pass ran, so average fullness is the more stable measure. NEWSEQUENTIALID() gives the same figures with and without compaction: there is nothing to compact.

What I expected, and what held

1. Once the inserts stop, compaction brings the random keys well above 68 %. Held: 91 to 93 % within two minutes.
2. Under continuous inserts, fullness drops after each burst and recovers between them, averaging somewhere in between. Wrong at the default fill factor: it averages below the uncompacted index, not above it.
3. NEWID() and UUIDv7 behave the same. Held for pages and fullness: the averages stay within three points. Rows moved differ by up to 50 % between the two keys, in no consistent direction; probably because the rows moved depend on how free space is spread across the index, which is random.
4. Compaction finds nothing to do on NEWSEQUENTIALID(). Held: zero rows moved in every run.

So, should you rely on it?

For a random clustering key, automatic index compaction is worth enabling, but it does not address the root cause: inserts that land at random positions. The fill factor decides how much it can help.

• Inserts in batches with quiet periods: the default fill factor of 100 works. Compaction catches up within a minute or two and gives the densest random-key index. Each new batch still splits many of the freshly compacted pages.
• A steady stream of inserts: at the default fill factor, compaction makes the index larger than doing nothing. A fill factor of 80 helped at both rates tested; 90 helped only at the gentler one.
• Existing indexes: compaction ignores pages not modified since you enabled it, so rebuild once first. The rebuild is also where you set the fill factor.
• Watch page fullness and log volume, not fragmentation, which can go up with compaction.
• The key choice from part 1 still stands: the sequential key stayed the smallest in every run, and compaction never fully closed the gap. These results emphasize how much the application side matters. The clustering key is usually chosen by developers, often for good reasons, so it is a decision worth taking together with whoever runs the database, early, before the table holds millions of rows.
• And on-premises nothing changes for now, since the feature is not in SQL Server 2025.

Limits of these tests

• Small tables, few runs per configuration. 5,000 to 10,400 rows. Control runs of the same setup differ by up to 18 pages.
• Intense rates. 1 % and 6 % of the table every 10 seconds. On a large table, the same inserts per second touch a far smaller share of its pages; how that changes the outcome was not tested.
• Short runs. Three minutes of inserts; how the index behaves at 80 or 90 over hours was not measured.
• An unfavorable case by design. These results say nothing about how the feature behaves on other workloads.
• One platform. Azure SQL Database, General Purpose serverless, 2 vCores, one inserting session.

If you want to reproduce these tests, feel free to contact me and I will share the full scripts.

L’article Azure SQL Database: does automatic index compaction fix the UUIDv7 density problem? est apparu en premier sur dbi Blog.

Logical fragmentation was a problem on spinning disks: an ordered scan on a fragmented index broke the read-ahead into smaller I/Os and each jump cost a disk head movement. On SSD, NVMe and cloud storage, the penalty of non-sequential reads is marginal. And the “physical order” we used to restore so carefully is only the order of the pages inside the data file: below it, the file system, the SSD controller and the storage layer place the blocks wherever they want anyway.

Here is the mapping to remember

• Internal fragmentation = page density = fixed by automatic index compaction
• External fragmentation = page order = ignored by automatic index compaction (it can even increase and we will see it in the demo)

How does it work ?

Automatic index compaction is not a hidden maintenance job. It is an additional task performed by a background process that already exists: the PVS cleaner is a component of Accelerated Database Recovery (ADR).

Here is the principle

• The PVS cleaner periodically visits the pages that were recently modified (insert, update, delete) to remove obsolete row versions
• When automatic index compaction is enabled the cleaner also checks if the visited page has free space excluding the space reserved by the fill factor
• If so, it moves rows from the next page into the current page as long as they fit and repeats the operation on a few consecutive page pairs
• A page that becomes empty is deallocated

The result: the number of pages decreases, the page density increases, and the storage space, I/O, CPU and buffer pool consumption decrease.

The overhead is minimal because the process only considers recently modified pages, unlike a rebuild or a reorganize which process all the pages. Like a reorganize, the compaction acquires short-term exclusive page locks to move the rows. If a lock cannot be acquired immediately, the page is simply skipped and will be considered again later.

One command per database, no restart, no exclusive access. The compaction starts within minutes:

-- Enable the feature
ALTER DATABASE [SQL-DB-1] SET AUTOMATIC_INDEX_COMPACTION = ON;

-- Check if it's enabled
SELECT name, is_automatic_index_compaction_on FROM sys.databases;

One important point before you enable it

The compaction process only considers the pages modified after you enable the feature. If the page density of your indexes is already low, run a one-time reorganize or rebuild to fix the existing situation. From that point on, the automatic compaction keeps the indexes compact without any action on your side.

Demo

• We create a table with a clustered primary key and we insert 5 million rows
• We measure the baseline: page count, page density, fragmentation
• We delete 2 rows out of 3, scattered over the whole table, to simulate index bloat
• We measure again and we let the engine work

We create the table and we insert 50K rows:

CREATE TABLE dbo.Demo (
    Id      int IDENTITY CONSTRAINT PK_Demo PRIMARY KEY CLUSTERED,
    Payload char(400) NOT NULL DEFAULT REPLICATE('X', 400)
);

INSERT INTO dbo.Demo (Payload)
SELECT TOP (50000) REPLICATE('X', 400)
FROM sys.all_columns a CROSS JOIN sys.all_columns b;

We measure the baseline:

SELECT index_level, page_count, avg_page_space_used_in_percent,
       avg_fragmentation_in_percent, record_count
FROM sys.dm_db_index_physical_stats(DB_ID(), OBJECT_ID('dbo.Demo'),1, NULL, 'SAMPLED')
WHERE alloc_unit_type_desc = 'IN_ROW_DATA';

We measure the baseline:

SELECT index_level, page_count, avg_page_space_used_in_percent,
       avg_fragmentation_in_percent, record_count
FROM sys.dm_db_index_physical_stats(DB_ID(), OBJECT_ID('dbo.Demo'),1, NULL, 'SAMPLED')
WHERE alloc_unit_type_desc = 'IN_ROW_DATA';

The internal fragmentation is low.

Here is what we have:

However to observe the automatic index compaction in action we need to create the following situation:

Here is the baseline:

We create the bloat

We delete 2 rows out of 3 scattered uniformly over the table. No page becomes empty. Every page keeps around one third of its rows. We change page density:

DELETE FROM dbo.Demo WHERE Id % 3 <> 0;

Without automatic index compaction, the expectation is simple: the page count stays at 277778 (deletes alone do not deallocate non-empty pages) and the density drops to around 31% (one third of 94.93%).

We measure again

We let the engine finish its job and we check again

The engine did the work in the background while the database stayed fully available.

This feature replaces the compaction part of your maintenance strategy not the whole strategy.

A summary:

• It does not update the statistics. A rebuild updates them the automatic compaction does not. If you rely on your rebuild jobs to refresh the statistics, keep a statistics update job.
• It does not reduce the logical fragmentation and it can even increase as we saw in the demo. For most workloads this has no measurable impact
• It does not recreate the free space reserved by the fill factor. Only a rebuild does. Workloads that need a fill factor below 100 to reduce page splits can still benefit from an occasional rebuild
• It does not shrink the data files. The used space decreases, the allocated size does not change
• It only applies to the leaf level of B-tree indexes in IN_ROW_DATA allocation units. Heaps, LOB data, row-overflow data, compressed columnstore rowgroups and memory-optimized tables are not concerned
• Indexes with page locks disabled (ALLOW_PAGE_LOCKS = OFF) are not eligible

Reference

Automatic Index Compaction – SQL Server | Microsoft Learn

Thank you. Amine Haloui

L’article SQL Server: Automatic index compaction in Azure (preview) – Part 2 est apparu en premier sur dbi Blog.

Microsoft recently released a new feature in public preview: automatic index compaction. The database engine takes care of compacting the indexes itself, in the background, while the data changes. No job, no maintenance window, no script to maintain.

Here is what we will cover in this blog post

• Which problems this feature addresses
• The requirements
• The difference between page density and index fragmentation (and why it matters)
• What the feature does not do

This is the first part of a series of two blog posts.

Which problems does it address?

Automatic index compaction is Microsoft’s answer to a routine operational task: index maintenance jobs.

Here are the problems with these jobs

• They are expensive in CPU and I/O. A rebuild reads and rewrites the entire index
• They take time to run, and maintenance windows keep shrinking
• They generate a lot of transaction log, which impacts log backups and Always On replication
• They can block applications. An offline rebuild locks the table and even an online rebuild needs a short exclusive lock at the beginning and at the end
• Someone has to set them up, monitor them and fix them when they fail

There is also a less obvious problem: for years, these jobs have been optimizing the wrong metric. We will come back to this point in a moment.

Requirements

The feature is currently in public preview and available on

• Azure SQL Database
• Azure SQL Managed Instance, with the Always-up-to-date update policy
• SQL database in Microsoft Fabric

It is not available on SQL Server on-premises, including SQL Server 2025.

There is nothing to install. The feature relies on a background process that already runs on these platforms (the ADR cleaner, more on this below), and Accelerated Database Recovery is always enabled on Azure SQL Database, Azure SQL Managed Instance and SQL database in Fabric.

Internal and external fragmentation

When we talk about index fragmentation, we are actually talking about two different phenomena. They are measured by two different columns of sys.dm_db_index_physical_stats, they have different causes, and above all they have very different costs.

Before we start: how is a data file organized ?

To understand fragmentation, we need one prerequisite: how SQL Server sees its data files.

• For any program, a file is an array of bytes provided by the operating system. Byte 0, byte 1, byte 2, and so on. Reading means asking for a range: an offset and a length

• SQL Server slices this array into pages of 8 KB. The page N is, by definition, the bytes N × 8192 to (N+1) × 8192 − 1. The page ID is not a label, it is an address in the file

• Everything below the file (NTFS clusters, SSD, SAN volumes) is translated and hidden by the storage stack.

Every time we say “physical order” in the rest of this post, we mean the order of the pages inside the data file not their placement on the hardware.

What does it look like?

Internal fragmentation: the pages are not full

Internal fragmentation means that the pages of an index contain free space. It is measured by avg_page_space_used_in_percent, also called page density.

Where does it come from?

• Deletes, especially scattered deletes: the rows disappear, the pages stay
• Page splits: when a page is full, an insert in the middle of the key range or an update that makes a row grow moves half of the rows to a newly allocated page. Both pages end up around 50% full
• Updates that shrink variable length columns
• Large rows that do not pack well: a 5000 bytes row means one row per page, and around 38% of every page is lost mechanically

Note that some free space is normal, and even intentional: the space reserved by the fill factor is internal fragmentation on purpose to absorb future inserts without page splits.

What does it look like?

CREATE DATABASE DemoFrag
GO

ALTER DATABASE DemoFrag SET RECOVERY SIMPLE
GO

USE DemoFrag
GO

CREATE TABLE dbo.SplitDemo (
    Id      int NOT NULL CONSTRAINT PK_SplitDemo PRIMARY KEY CLUSTERED,
    Payload varchar(8000) NOT NULL
);

-- 2 lines about 4000 bytes per page
INSERT INTO dbo.SplitDemo VALUES
(1, REPLICATE('A', 4000)), (2, REPLICATE('B', 4000));

My page is almost full:

Why does it cost ?

Because the same rows are spread over more pages than necessary and everything in SQL Server is done at the page level:

• The buffer pool caches pages, not rows. A page at 40% density wastes 60% of the memory it occupies
• Every read, logical or physical, handles more pages for the same data
• Backups are bigger, integrity checks are longer

This is the key point: internal fragmentation follows the data everywhere, including in RAM. It is a permanent tax on memory, I/O and CPU. However it’s not the case with external fragmentation.

External fragmentation: the offsets do not follow the logical order

At the leaf level of a B-tree, the pages are chained together in the order of the index keys with two pointers stored in every page header (m_nextPage, m_prevPage). This chain is the logical order and it cannot be wrong: it is the order of the keys by definition.

External fragmentation (also called logical fragmentation) means that following this chain no longer corresponds to reading the file sequentially. The pages are logically ordered, but their offsets in the file are not. It takes two forms:

• Holes: the pages of the index are not at consecutive offsets. Pages of other objects, or free pages, sit in between
• Disorder: the pages are at consecutive offsets, but chained in a different order

avg_fragmentation_in_percent counts both forms without distinction. The columns fragment_count and avg_fragment_size_in_pages are closer to the real cost: they measure the length of the contiguous runs.

Where does it come from?

• Several objects growing at the same time: the engine allocates the extents in the order the requests arrive, so the objects interleave in the file. This is the normal life of a database
• Page splits: the new page is allocated where free space is found, rarely next to the original page
• Page deallocations: massive deletes, and the automatic index compaction itself

What does it look like?

USE DemoFrag
GO

CREATE TABLE dbo.SplitDemo (
    Id      int NOT NULL CONSTRAINT PK_SplitDemo PRIMARY KEY CLUSTERED,
    Payload varchar(8000) NOT NULL
);

-- 2 lines about 4000 bytes per page : lines 1 and 2 on 1 page, 3-4 on next page

INSERT INTO dbo.SplitDemo VALUES
(1, REPLICATE('A', 4000)), (2, REPLICATE('B', 4000)),
(3, REPLICATE('C', 4000)), (4, REPLICATE('D', 4000))

-- Lines location (file:page:slot)?
SELECT Id, sys.fn_PhysLocFormatter(%%physloc%%) AS physical_location
FROM dbo.SplitDemo;

My first 2 rows are located on page 376 and the last 2 rows on page 378.

What does page 377 contain? I thought the pages were contiguous?

Since my table has a clustered index on Id it is stored as a B-tree. Can we see it?

SELECT allocated_page_page_id, page_type_desc, page_level, previous_page_page_id, next_page_page_id
FROM sys.dm_db_database_page_allocations(DB_ID(), OBJECT_ID('dbo.SplitDemo'),1, NULL, 'DETAILED');

What does it look like internally?

SELECT * FROM sys.dm_db_page_info (10, 1, 376, DEFAULT);

SELECT * FROM sys.dm_db_page_info (10, 1, 378, DEFAULT);

Page split to generate external fragmentation:

-- Split happens
UPDATE dbo.SplitDemo SET Payload = REPLICATE('B', 4100) WHERE Id = 2;

-- Check page density
SELECT index_level, page_count, avg_page_space_used_in_percent,
avg_fragmentation_in_percent, record_count,
ghost_record_count, version_ghost_record_count
FROM sys.dm_db_index_physical_stats(DB_ID(), OBJECT_ID('dbo.SplitDemo'),1, NULL, 'SAMPLED')
WHERE alloc_unit_type_desc = 'IN_ROW_DATA';

After the page split:

Line 1 is located at page 376

Line 2 is located at page 379

Line 3 is located at page 378

Line 4 is located at page 378

Why does it cost so little today?

There is exactly one mechanism through which external fragmentation ever costed something: the read-ahead. During a scan, the engine prefetches pages with large I/Os and an I/O is a contiguous range of the file: one offset, one length, up to 512 KB. When the index is contiguous one I/O brings back 64 pages. When it is not the same pages arrive in several smaller I/Os.

When do these smaller I/Os hurt ? Three conditions must be met at the same time:

• The data is cold: a page already in the buffer pool generates no physical I/O at all
• The operation is a large scan: a seek navigates the B-tree by page ID and does not care about the order
• Each additional I/O has a price

On SSD, NVMe and cloud storage, an additional I/O costs a few dozen microseconds and the physical placement below the file is arbitrary anyway (SSD controllers and SANs put the blocks wherever they want).

External fragmentation survived its own usefulness for another reason: it was a good symptom. It increases because of page splits, and page splits destroy the page density and inflate the transaction log.

Reference

Automatic Index Compaction – SQL Server | Microsoft Learn

Thank you. Amine Haloui

L’article SQL Server: Automatic index compaction in Azure (preview) – Part 1 est apparu en premier sur dbi Blog.

The opening keynote was about Azure Sovereign Architecture where the presenter gave us an update on the current Azure/Microsoft projects. We also had an explanation on how sovereignty works.

Then I joined a session titled “Time Bombs In Entra ID – How Well Are Your Entra ID Apps Managed?”. The speaker explained to us how Azure App registration and service principal really work. He also gave us some advice on best practices when using this kind of Azure/Entra resource.

Before the lunch break I joined a session on how some architects resolved the “multiple teams needed to deploy something” problem. They automated the deployment with CI/CD and Terragrunt. They did a demo on how they use their code and how they make infrastructure changes with it.

After the lunch, I chose to go in a more network oriented presentation. The topic was how to get rid of VPN by using an Azure service called Global Secure Access. Even though I’m not convinced that we can get rid of VPNs, this option could be something for highly Microsoft infrastructure as it uses the Microsoft backbone for all the network routing.

The last two sessions I attended sessions on Azure Policy. The topics were first using code to deploy Azure policies, as it’s a better way to have them identical in multiple environments and as it as also faster than using the Azure interface, which is slow. The second one was about using conditional access as safer alternative for securing Azure tenants with policies. This method is quite interesting but requires a paid version of Entra to be activated.

Finally, for the closing keynote, we had a presentation about an application developed by a Swiss company that helps emergency services coordinate. It’s allowing call centers to locate and contact closest to scene savers and organize their deployment.

Once again, I’m glad that could attend this event. I learned quite a bunch of things and could also refresh my memory on some other topics. The sessions are long enough to detail a topic and the speakers are always performing well.

L’article Azure Bootcamp Switzerland 2026 edition est apparu en premier sur dbi Blog.

While I was working for a customer, I was tasked to create an Azure infrastructure, using Terraform and Azure DevOps (ADO). I thought about doing it like I usually do with GitLab but it wasn’t possible with ADO as it doesn’t store the state file itself. Instead I have to use an Azure Storage Account. I configured it, blocked public network, and realized that my pipeline couldn’t push the state in the Storage Account

In fact, ADO isn’t supported as a “Trusted Microsoft Service” and so it can’t bypass firewall rules using that option in Storage Accounts. For this to work, I had to create a self-hosted agent that run on Azure VM Scale Set and that will be the topic of this blog.

Azure resources creation

Agent Creation

First thing, we create a Azure VM Scale Set. I kept most parameters to their default values but it can be customized. I chose Linux as operating system as it was what I needed. One important thing is to set the “Orchestration mode” to “Uniform”, else ADO pipelines won’t work.

Storage account

For the storage account that will store our state, any storage account should work. Just note that you also need to create a container inside of it to fill your terraform provider. Also, for network preferences we will go with “Public access” and “Enable from selected networks”. This is will allow public access only from restricted networks. I do this to avoid creating a private endpoint to connect to a fully private storage account.

Entra ID identity for the pipeline

We also need to create an Entra ID Enterprise Application that we will provide to the pipeline. This identity must have Contributor (or any look alike) role over the scope you target. Also, it must have at least Storage Blob Data Contributor on the Storage Account to be able to write in it.

Azure DevOps setup

Terraform code

You can use any Terraform code you want, for my example I only use one which creates a Resource Group and a Virtual Network. Just note that your provider should look like this

Pipeline code

I’m used to split my pipeline in two files, the plan.yml will be given to the ADO pipeline and it will call the template to run its code. The things done in the pipeline are pretty simple. It installs Terraform on the VM Scale Set instance, then run the Terraform commands. The block of code can be reused for the “apply”.

Few things to note, in my plan.yml I set a Variable Group “Terraform_SPN” that I will show you just after. That’s where we will find the information about our previously created Entra Id Enterprise Application

In the template.yml, what is important to note is the pool definition. Here I point just a name, which correspond to ADO Agent Pool that I created. I’ll also show this step a bit further.

For the pipeline creation itself, we will go to Pipeline -> Create a new pipeline -> Azure Repos Git

Then Existing Azure Pipelines YAML file, and pick our file from our repo.

We will also create a Variable Group, the name doesn’t matter, just remember to put the same in your YAML code. Here you create 4 variables which are information coming from your tenant and your enterprise application. That’s gonna be used during the pipeline run to deploy your resources.

ADO Agent Pool

In the Project Settings, look for Agent Pools. Then create a new one and fill it as follow:

The Authorize button will appear after you select the subscription you want, and to accept this your user must have the Owner role, as it adds rights. This will allow ADO to communicate with Azure by creating a Service Principal. Then you can fill the rest as follow:

ADO pipeline run

When you first run your pipeline you must authorize it to use the Variable Group and the Agent pool.

One this is done, everything should go smoothly and end like this.

I hope that this blog was useful and could help you troubleshoot that king of problem between Azure and Azure DevOps.

L’article Deploying Azure Terraform code with Azure DevOps and a storage account as remote backend est apparu en premier sur dbi Blog.

So, I thought I’d write a little catch-up blog post, to help you to find all LinkedIn Posts!

First, a bit of humour with this image of SQL Server scrolling through LinkedIn and wondering if anyone still loves it… Meanwhile, Power BI and Azure Data Fabric are stealing the show.

Let’s talk about SQL Server, and in particular all tests done on SQL Server 2025:  

SSRS Deprecation – It’s time to rethink your reporting architecture explain you how with our Team, we can help you to go forward!

dbi services’ blog on fire for SQL Server 2025 with this Tips to find all our SQL Server blogs : just Google: site:dbi-services.com/blog SQL Server 2025

Exploring SQL Server 2025 blogs with tests on SQL Server 2025 new features

Time to review your SQLServer licenses with 10% price increase for SQL Server licences, we can help you to optimize your SQL Server Architecture!

SQL Server 2025: AI, Performance… and real-world Lessons with a lot of deep tests and new thinking about  Tuning, Performance & AI

Your SQL Server might be exposed right now is a very important topic because Microsoft put in Augaust and Septembre critical patches in High importance

SQL Server 2025 – What’s new & What’s next? withgood feedback and ideas from SQLBits 2025  in London

It’s time to rethink your data strategy with SQL Server 2025 with the end of DQS, MDS and Synapse Link, it’s  the opportunity to see our expertise in Microsoft Fabic

And also, publications about how we can help beside SQL Server and share these experiences & expertise:

Struggling with rising Azure Data Fabric & Power BI costs? with our experience to help to optimize the cost of your Azure Platform using the BI stack

When M-Files meets SQL Server with our SQL Server & M-Files expertise, we are on the top to help you to configure, customize, optimize, secure  your M-File infrastructure

Continue to follow us in our blogs and linkedIn posts!

L’article SQL Server’s LinkedIn Posts catch-up! est apparu en premier sur dbi Blog.

How to begin? Read the documentation of course here but you will see a lot of informations…

After reading the documentation, how to have the first useful information?

The first information will be about the SQL Server installed like the server name, instance name, build and version with also some advanced information like last update date, the KB or CU.

Here this first query:

SELECT  
  SERVERPROPERTY('MachineName') AS [Server_Name],
  SERVERPROPERTY('InstanceName') AS [Instance_Name], 
  SERVERPROPERTY('Edition') AS [Edition],
  SERVERPROPERTY('ProductVersion') AS [Product_Version], 
  SERVERPROPERTY('ProductLevel') AS [Product _Level],
  SERVERPROPERTY('ProductBuild') AS [Product _Build],
   SERVERPROPERTY('ProductMajorVersion') AS [Advanced_Product_ Major_Version],
  SERVERPROPERTY('ProductMinorVersion') AS [Advanced_Product_Minor_Version],
   SERVERPROPERTY('ProductUpdateReference ') AS [Advanced_KB_Version],
  SERVERPROPERTY('ProductUpdateLevel') AS [Advanced_Update _Level],
  SERVERPROPERTY(' ResourceLastUpdateDateTime ') AS [Advanced_Last_Update_Date]

Result of a test:

I run all queries on my sql server container under Visual Studio Code and sql server 2025 CPT2.1.

You can have more info about it here (dbi Blog)

After, some other useful information will be if the instance has features installed like Polybase or Full-Text seach but also some configuration like filestream or HA.

 Here the query:

SELECT 
  SERVERPROPERTY('MachineName') AS [Server_Name],
  SERVERPROPERTY('InstanceName') AS [Instance_Name], 
  SERVERPROPERTY('IsPolyBaseInstalled') AS [Is_Polybase_Installed],  
  SERVERPROPERTY('IsFullTextInstalled') AS [Is_Full-Text_Search_Installed],
  SERVERPROPERTY('IsAdvancedAnalyticsInstalled') AS [Is_Advanced_Analytics_Installed],
  SERVERPROPERTY('FilestreamConfiguredLevel') AS [is_Filestream_enabled],  
  SERVERPROPERTY('IsBigDataCluster') AS [Is_BigData_Cluster_enabled],
  SERVERPROPERTY('IsClustered') AS [Is_Clustered],  
  SERVERPROPERTY('IsHadrEnabled') AS [Is_HADR_enabled],
   SERVERPROPERTY('IsTempDbMetadataMemoryOptimized') AS [Is_TempDB_for_Memory_Optimized_Tables_Enabled],  
  SERVERPROPERTY('IsXTPSupported') AS [Is_IN_Memory_OLTP_Supported],
  SERVERPROPERTY('IsExternalGovernanceEnabled') AS [Is_External_Governance_Enabled];

Result of a test:

You can notice that the last property is the External governance. This is linked to the  Microsoft Purview access policies.  

The next useful information will be about the security.

Here the query:

SELECT 
  SERVERPROPERTY('MachineName') AS [Server_Name],
  SERVERPROPERTY('InstanceName') AS [Instance_Name], 
  SERVERPROPERTY('IsIntegratedSecurityOnly') AS [Is_Integrated_Security_Only],
  SERVERPROPERTY('IsSingleUser') AS [Is_Single_User],
  SERVERPROPERTY('IsExternalAuthenticationOnly') AS [s_External_Authentication_Only];

Result of a test:

The External Authentication concerns the Microsoft Entra-only authentication  for Azure SQL Database & Azure SQL Managed Instance.

The last information package is the collation/character set with this query:

SELECT 
  SERVERPROPERTY('MachineName') AS [Server_Name],
  SERVERPROPERTY('InstanceName') AS [Instance_Name], 
  SERVERPROPERTY('Collation') AS [Collation], 
  SERVERPROPERTY('LCID') AS [Windows_Locale_Identifier], 
  SERVERPROPERTY('SqlCharSetName') AS [SQL_Character_Set_Name], 
  SERVERPROPERTY('SqlSortOrderName') AS [SQL_Sort_Order_Name];

Result of a test:

To conclude, you have now in this blog 4 useful queries to find information on the server level.
Don’t hesitate to add your comments or give me other useful property that you use.!

L’article SQL Server: Do you know how to use SERVERPROPERTY()  function in a useful way? est apparu en premier sur dbi Blog.

In this article, we will explore the concept of data embeddings, a key concept for modern AI-driven applications and platforms. We will then examine the latest capabilities introduced in SQL Server 2025 (preview) and Azure SQL, focusing on their new support for vector data types. Finally, we will generate embeddings using an AI model and store them directly in our database, demonstrating how to integrate AI-powered semantic abstraction into your SQL workloads.

But First: What Exactly Are Data Embeddings?

Let’s start from the back. From a linguistic perspective, written text consists of syntax and semantics. While syntax refers to the structure of the text and the arrangement of words and letters, semantics refers to the actual meaning conveyed by the text. You can have text with a similar syntax but a different semantic and you can also have text with a similar or the same semantic but different syntax. For example:

• Sentence 1: Our customer satisfaction has increased.
• Sentence 2: The contentment of our clients is better than before.

While both sentences have basically the same meaning, they differ in structure and the way the words and letters are arranged.

In IT, we have different simple ways to search for syntax matches, such as exact string matching, wildcard searches or regular expressions (Regex) for more sophisticated syntax matches.

But when we are looking for semantic matches, simple programming functions that only evaluate and compare the arrangement of letters are not enough. In such cases, we need a human, or another form of intelligence, that can interpret those arranged letters and understand their meaning.

That’s exactly where AI comes into play. The AI model basically reads and understands the written text, then it generates a numerical representation for the semantic of that text which we call “embedding”.

When I first heard about embeddings, I asked myself: Okay, but what is the data embedded in?

The answer is that the data is embedded in a high-dimensional mathematical space, with the vector data representing its coordinates within that space. Since the semantics of embedded data are represented as coordinates in a mathematical space, we can calculate the distance between embeddings and use that to search for data with similar meaning.

If you want to learn more about the theory of vectors and embeddings, I can highly recommend the article by my colleague Amine Haloui – he explains the basic mathematical concepts in an understandable way, even if you’re not a mathematician.

Enough Theory for Now – Let’s Get Practical!

Lets take a look how we can generate data embeddings with the latest functions and features of SQL-Server 2025 and Azure SQL directly within our database through T-SQL.

For that I’m using the same sample database which we already used in the previous blog post. But in the meantime I created a new column in my “dbo.products” table and I inserted in that column the AI generated product description for each product. If you are wondering how I did that – you can read it here.

select p.product_id, p.product_name, p.Description, p.currency, p.price, c.category_name, b.brand_name, co.color_name, g.gender, s.season from dbo.products p
inner join dbo.category c on p.category_id = c.category_id
inner join dbo.brand b on p.brand_id = b.brand_id
inner join dbo.color co on p.color_id = co.color_id
inner join dbo.gender g on p.gender_id = g.gender_id
inner join dbo.season s on p.season_id = s.season_id

Deploy an embedding Model:

For generating embeddings for our product data we need first an AI model which is capable to do that. Therefore I go into my Azure OpenAI Resource and I’m searching in the Model catalog in the Azure Foundry Portal for embedding models (I show you exactly who I can go there and deploy resources in the previous blog). There are currently three embedding models available from OpenAI. I’m choosing for this blog post the model 3-small and I’m deploying it with a click on “text-embedding-3-small” -> “use this model”->”Deploy” :

Then I’ll find the model in the Azure AI Foundry Portal under the section “Deployments”:

When clicking on the model I’m able to see my models API endpoint and the access key:

Create a Database Scoped Credential:

Okay so far so good, let’s connect to our SQL-Server 2025 Instance where the ShopAI database is running on. To register the external model in our database and access it through the appropriate T-SQL functions, I first create a database-scoped credential. You can create the credential with a managed identity or with an API Key. I’m using the API Key which I copied from the Azure AI Foundry Portal. Note that the credential name must point to a path which is more generic than the request URL:

-- Create database scoped credential:
CREATE DATABASE SCOPED CREDENTIAL [https://shopai-blog.openai.azure.com/]
	WITH IDENTITY = 'HTTPEndpointHeaders', secret = '{"api-key":"YOUR-API-KEY"}';
GO

Register the External AI Model:

As far as the database scoped credential is created we can register the external model with the “Create External Model” command, which is currently available in SQL-Server 2025 Preview, in our database. You can find more information’s about this brand new command under the following link from Microsoft: https://learn.microsoft.com/en-us/sql/t-sql/statements/create-external-model-transact-sql?view=sql-server-ver17

-- Create EXTERNAL MODEL
CREATE EXTERNAL MODEL OpenAITextEmbedding3Small
AUTHORIZATION dbo
WITH (
      LOCATION = 'YOUR-ENDPOINT_URL',
      API_FORMAT = 'Azure OpenAI',
      MODEL_TYPE = EMBEDDINGS,
      MODEL = 'text-embedding-3-small',
      CREDENTIAL = [YOUR-CREDENTIAL],
      PARAMETERS = '{"Dimensions":1536}'
);

Test the Embedding Function

As far as we created the external model successfully we can generate the embeddings with the “AI_Generate_Embeddings” function. This function is currently available in SQL-Server 2025 Preview.

The function requires the text to be embedded and the name of a pre-created external model as arguments, with optional model-specific parameters that can be appended in JSON format. You can get more information’s about this brand new function under the following link from Microsoft: https://learn.microsoft.com/en-us/sql/t-sql/functions/ai-generate-embeddings-transact-sql?view=sql-server-ver17

Let’s test the registered model and the embedding function with the command below. As you can see, the result is a JSON array containing multiple numerical values:

Generate and Store Product Embeddings:

Having deployed the embedding model in Azure, registered it in our database, and successfully tested the embedding function, our next step is to generate embeddings for our products.

Therefore I add an additional column called “embedding” to our “dbo.products” table. For the column I’m using the vector data type which is currently available in Azure SQL and in SQL-Server 2025 preview. Note the number in the brackets of the datatype definition is representing the amount of dimensions which are used for the embedding. Who many dimensions you need is depending on the model you are using. The “text-embedding3-small” model from OpenAI is using 1536 dimensions per default:

ALTER TABLE dbo.products
ADD embedding vector(1536);

I now want to generate embeddings for all products in my ShopAI database and store them in the newly created column, taking the following product attributes into account when generating the embeddings:

• Product Name
• Product Description
• Product Price
• Product Season
• Product Gender

To accomplish this, I use the code below to generate the embeddings:

UPDATE p
SET p.embedding = AI_GENERATE_EMBEDDINGS(
    CONCAT(
        N'Product Name: ',            COALESCE(p.product_name, N'Unknown'),
        N' | Product Description: ',  COALESCE(p.[description], N'Unknown'),
        N' | Product Price (CHF): ',  COALESCE(CONVERT(NVARCHAR(32), p.price), N'Unknown'),
        N' | Product Season: ',
        CASE p.season_id
            WHEN 1 THEN N'Spring'
            WHEN 2 THEN N'Summer'
            WHEN 3 THEN N'Autumn'
            WHEN 4 THEN N'Winter'
            WHEN 5 THEN N'All Seasons'
            ELSE N'Unknown'
        END,
        N' | Product Gender: ',
        CASE p.gender_id
            WHEN 1 THEN N'Male'
            WHEN 2 THEN N'Female'
            WHEN 3 THEN N'Unisex'
            ELSE N'Unknown'
        END
    ) USE MODEL OpenAITextEmbedding3Small
)
FROM dbo.products AS p
WHERE p.embedding IS NULL;

The query ran for over four minutes and successfully generated embeddings for all products:

Test Semantic Similarity Functions:

So far so good, we were able to deploy an embedding model in Azure, we successfully created a credential for the access to the model, we registered the embedding model with the latest T-SQL command and we were able to generate embeddings for our products.

Let’s see how we can use now the embedding model and the embedded data for semantic search capabilities.

Therefore I’m using the “Vector_Distance” function which is available in SQL-Server 2025 preview and in Azure SQL. The function requires 3 arguments: The first is the metric you want to use for calculating the distance between two embeddings, and the other two are the vectors you want to compare.You can get more information’s about this brand new function under the following link from Microsoft: https://learn.microsoft.com/en-us/sql/t-sql/functions/vector-distance-transact-sql?view=sql-server-ver17

Okay, let’s see how we can use this function – It’s summer and I would like to go on summer vacation (again). Therefore I’m looking for some pants which I can wear during my summer holidays. I don’t like anything flashy, so I’d like the pants in black.

Let’s test with the code below if we can find a matching product for me:

DECLARE @SemanticSearchText Nvarchar(max) = 'Im looking for black pants for men which I can wear during my summer vacation.'

	
	DECLARE @qv VECTOR(1536) = AI_GENERATE_EMBEDDINGS(@SemanticSearchText USE MODEL OpenAITextEmbedding3Small);

	SELECT TOP(10) 
	  product_name, 
	  Description,
	  price,
	  s.season,
	  g.gender,
	  VECTOR_DISTANCE('cosine', @qv, embedding) AS distance 
	FROM dbo.products p
	  inner join dbo.season s on p.season_id = s.season_id
	  inner join dbo.gender g on p.gender_id = g.gender_id
ORDER BY   distance;

As you can see, the results are quite accurate. All of the products are pants, except for the one with the highest distance, which is a full swimsuit. Every product is black in color, and most are categorized for the summer season, except for two that are suited for all seasons:

As you can see by combining SQL Server 2025’s new vector capabilities with external embedding models, we can seamlessly integrate semantic understanding directly into our data workflows. This enables intelligent, context-aware queries that go far beyond simple keyword matching.

You can find all the code again on GitHub and test it by your own. Feel free to share your thoughts with me in the comment section and stay tuned for upcoming posts from my colleagues and me. 😉

Thanks for reading,
Hocine

L’article SQL-Server 2025: Generate Data Embeddings for Semantic Search est apparu en premier sur dbi Blog.

Providers of modern and future-oriented platforms and applications seem to be aware of this development and are integrating AI in a targeted manner to increase efficiency and improve the user experience.

With SQL Server 2025 being the most developer-oriented release in over a decade, Microsoft is clearly targeting the AI evolution making it easier than ever to integrate AI with your data.

In this article I will introduce you in two of the latest AI oriented features which are now available in SQL-Server 2025 preview and I will show you an example how you can interact with an external AI-model programmatically.

sp_invoke_external_rest_endpoint:

While the stored procedure sp_invoke_external_rest_endpoint was already available in Azure SQL Database and Managed Instance it’s now also available in  SQL-Server 2025 Preview and allows you to communicate with external REST services from On-Premise.

This is significant in terms of AI because AI-models which are hosted on Cloud Platforms or on Premise (for example with Ollama) are usually REST compatible. This stored procedure allows you so to interact with an external AI model directly and programmatically through T-SQL.

You can find more information about the stored procedure and the specific parameters on the following Link from Microsoft: https://learn.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-invoke-external-rest-endpoint-transact-sql?view=sql-server-ver17&tabs=request-headers

JSON Datatype:

In the previous version of SQL-Server JSON Data was stored in the varchar and nvarchar datatypes. With SQL-Server 2025 you can now store JSON data in a JSON datatype. The JSON datatype which is also available in Azure SQL Database and Azure SQL Managed Instance brings multiple advantages over working with JSON Data in nvarchar and varchar datatypes.

As the new JSON Datatype is compatible with all JSON functions no code change is necessary while benefiting from the following advantages:

• reads are faster because with the JSON datatype your JSON data is already parsed
• you can update also individual values without accessing the whole JSON data
• the JSON datatype is optimized for compression which makes the storage more efficient

In terms of AI this is significant because external AI-models are usually transferring data in the JSON format. With the new JSON datatype you can handle this data efficiently.

To get more detailed information’s about handling JSON data with T-SQL and about the new JSON datatype, you can access the following Link from Microsoft: https://learn.microsoft.com/en-us/sql/relational-databases/json/json-data-sql-server?view=sql-server-ver17

Hands On – Generating Product Descriptions using AI:

Enough theory for now! let’s get practical. For demonstration purposes, I’ve prepared a sample shop database for a clothing reseller running on SQL-Server 2025.

The database has some few tables which are containing product information’s:

With the following query you can see that we have 3000 products with different categories from different brands etc.

select p.product_id, p.product_name, p.currency, p.price, c.category_name, b.brand_name, co.color_name, g.gender, s.season 
from dbo.products p 
inner join dbo.category c on p.category_id = c.category_id 
inner join dbo.brand b on p.brand_id = b.brand_id 
inner join dbo.color co on p.color_id = co.color_id 
inner join dbo.gender g on p.gender_id = g.gender_id
inner join dbo.season s on p.season_id = s.season_id

What we don’t have is a product description for attracting potential buyers. This is something we will do now using AI. Therefore I need an AI model which I can integrate with my product data. I deploy this model in Azure.

Deploy an AI Model in Azure:

In the Azure Portal I’m looking therefore for Azure AI Foundry.

Then under AI Foundry I create a new resource of Azure OpenAI:

The deployment is pretty much straight forward and after the deployment is finished I access my newly created resource:

In my new Azure OpenAI resource I’m accessing now the Azure AI Foundry portal for deploying a new AI-model:

In the AI Foundry Portal I’m looking under the Model catalog for chat completion models and I select the gpt-4o model which is the “allrounder” AI-model for chat completion tasks from OpenAI(It’s in fact currently the model you are using with ChatGPT by default if you don’t choose anything else specifically):

After clicking on the gpt-4o model, I clik on “Use this model” and finally on “deploy” for deploying the model:

As far as I deployed the model successfully I’m able to find it in the Azure AI Foundry Portal under “Deployments”:

After clicking on the newly deployed model I can also find my https URL and API key for accessing the model:

Interacting with the AI Model using T-SQL:

As the model is now successfully deployed we are ready to interact with it using T-SQL. Therefore I wrote a small stored procedure around the stored procedure sp_invoke_external_rest_endpoint which is doing the following stuff:

It takes the Product ID, API Key, API Endpoint URL and the desired description language as input parameters:

It selects necessary product data for the provided Product ID from the database and stores it as a single string:

It generates a prompt for the chat completion API and dynamically interpolates the selected product data into that prompt:

Finally it invokes the external AI model using the stored procedure sp_invoke_external_rest_endpoint with the generated prompt:

With the code below I’m then executing the stored procedure above for a specific product in my database and I’m extracting the product description from the AI models JSON response:

As a random example I have this swim shorts in the color magenta in my Shop database with the product ID 2354:

I’m now able to generate a product description using the gpt-4o model hosted in Azure for this specific product:

You can see here the full product description which was returned by the gpt-4o model:

The description is pretty good isn’t it? If magenta suited me, I would definitely buy one

The GPT-4o model is also quite a language expert. For example, you can even generate your product descriptions in Chinese.

In case that I have Chinese speaking blog readers or if someone wants to translate it, here is again the full description:

If you want to test it by your own you can find the whole code and a backup of the ShopAI database on GitHub: https://github.com/HocineMechara/SQL2025-AI-Product-Description-Blog

Of course, this is just a simple example. You can do much more. For instance, you could provide additional context to the chat completion model, such as the user’s recent orders or behavioral data, to generate personalized product descriptions tailored to individual customers.

Feel free to share your thoughts in the comments, and stay tuned for upcoming posts from my colleagues and me.

Thanks for reading,
Hocine

L’article SQL Server 2025: Where Data Meets Intelligence est apparu en premier sur dbi Blog.

The sessions and workshops on the event mainly focused on the evolution of AI and a lot about Business Intelligence and Data Engineering with a big focus on Microsoft Fabric the unifying data platform from Microsoft. The choice of topics reflects the direction in which I believe the industry is heading, and I took the opportunity to gain valuable insights from renowned experts.

On the first day, I attended a one-day workshop on the latest AI functionalities in SQL Server and Azure SQL, focusing on how these features support the integration of external AI models with your data, enabling the development of context- and data-aware AI assistants for your application’s users based on the RAG (Retrieval-Augmented Generation) pattern. It was very interesting, the workshop was delivered in a high quality and it was even my personal highlight of the event.

On the second day I joined again a one-day workshop about Microsoft Fabric. I was very curious about Microsoft Fabric because I heard a lot of advantages about this end to end SaaS Data Platform and I was happy to learn more about it. The workshop covered a lot of topics regarding Microsoft Fabric and at the end of the day I had a good feeling of understanding the concept and the core elements about Microsoft Fabric.

During the break I enjoyed a fancy coffee served at the Microsoft booth

On the last day I attended again a one-day workshop about Microsoft Fabric but with more focus on the administration of a Fabric Tenant including workspace management, security, Git Integration etc. The workshop was again delivered in a good quality and I really enjoyed to attend. The Kahoot Quiz at the end of the workshop confirmed my Impression that I’m on track of understanding this platform quite well.

The event was awesome, I learned a lot about the latest technologies and I hope that I will be able to apply the gained knowledge in upcoming projects. I can highly recommend this event to every data professional working with Microsoft technologies!

L’article Exploring the Future of Data at SQLBits 2025 in London est apparu en premier sur dbi Blog.