← All posts
· 3 min read

Why Azure SQL Database got a JSON data type

Here is why Microsoft added a JSON data type to Azure SQL Database, and when I would use it instead of the good old data types.

Why JSON matters

The first JSON functions were introduced in SQL Server 2016. In 2025, the JSON data type went to GA in Azure SQL Database first. Before that, you needed to store JSON as nvarchar(max). So why did Microsoft add a new data type? In my opinion, they needed to make the database AI-ready. A positive side effect is that developers can also use JSON now for other use cases.

AI loves JSON

Microsoft announced that for 2025 they wanted to make the database AI-ready (1). They also wanted developers to consider using Azure SQL Database for new AI apps or to make existing apps more intelligent by adding new AI features. As I already mentioned in When should I use Azure Cosmos DB?, one of Azure Cosmos DB’s advantages is schema flexibility. For example, let’s say you want to build an AI chat agent.

A chat demo built with Microsoft Agent Framework and Azure SQL Database. The user asks "What day is today?", the agent calls the tool what_day_is_today(), the tool returns "Saturday, 26 September 2026", and the agent answers with that date. In this scenario, most database columns are known and can be stored with existing data types. But as you can see, the chat agent also made a tool call to get today’s date. The tool result is usually not a string, but rather JSON, which we can’t always predict.

A T-SQL query that joins dbo.Conversations and dbo.Messages for one user. It returns the four messages of that chat: the user's question, the assistant's tool call, the tool result and the assistant's answer. Each message's Contents column holds JSON, for example the function call with its name and the function result with the date. In this case, it makes sense to store a message’s contents as JSON. If the user writes something, it’s always a string. But the chat agent doesn’t always immediately return a string to the user directly. Often, it calls tools first. So the content can’t be a string anymore because we need to store the tool calls as message content as well. And if a tool writes a message, it never returns anything to the user. It just returns the tool response. As you can see, this gets very complicated to store predictably in a database.

With nvarchar(max), you could already store and query this before, but the database engine had to parse the text every time you read it, and indexes only worked through computed columns. The JSON data type stores it in a native binary format, rejects invalid JSON, and can update single values without rewriting the whole document.

Developers love JSON

Besides, many developers love JSON in databases since the rise of NoSQL database solutions last decade. Some even gave up SQL databases altogether. I wouldn’t go that far. I prefer SQL databases for my relational workloads. So my rule of thumb: if I can predict what a column will look like, I use the good old data types.

Summary

If you can avoid the JSON data type for a column, avoid it. But if you need to integrate AI capabilities into your apps, it’s a keeper.

References

The year ahead for SQL Server: Ground to cloud to fabric - Microsoft SQL Server Blog (1)