Azure SQL Database

Developer Guide
Table of Contents
01 Azure SQL Database essentials ................................................................................. 7
02 Introduction to Azure SQL Database .......................................................................... 8
What is Azure SQL Database ...................................................................................... 8
Purchasing models .................................................................................................... 8
Compute tiers ........................................................................................................... 8
Service tiers .............................................................................................................. 8
Try it out .................................................................................................................... 9
Getting started with Azure SQL Database ....................................................................... 9
How to create an Azure SQL Database ........................................................................ 9
How to manage an Azure SQL Database.................................................................... 11
Available tools to create and manage Azure SQL Database ........................................ 12
03 Connecting and querying Azure SQL Database ......................................................... 13
Security layers protecting Azure SQL Database ......................................................... 13
Network security .................................................................................................. 13
Access management ............................................................................................ 13
Authorization ....................................................................................................... 14
Threat protection ................................................................................................. 14
Information protection and encryption .................................................................. 15
Azure Key Vault usage .......................................................................................... 15
Always Encrypted (Encryption-in-use) ................................................................... 15
Dynamic data masking ......................................................................................... 15
Resources............................................................................................................... 16
04 Modern application development ............................................................................ 17
Introduction to the sample application ......................................................................... 17
Sample application overview .................................................................................... 17
Solution architecture............................................................................................ 17
Microservice and containerized development ............................................................... 18
Microservices.......................................................................................................... 18
Resources ........................................................................................................... 19
Web apps ............................................................................................................... 19
Resources ........................................................................................................... 19

1
 Serverless compute ................................................................................................. 19
Containerized development ..................................................................................... 19
Containerizing layers ............................................................................................ 19
Azure Container Instances (ACI)............................................................................ 19
Azure Container Apps (ACA).................................................................................. 20
App service containers ......................................................................................... 20
Azure Kubernetes Service (AKS) ............................................................................ 20
Data API builder .......................................................................................................... 20
Features ................................................................................................................. 21
General ............................................................................................................... 21
Authentication & authorization.............................................................................. 21
REST API .............................................................................................................. 21
GraphQL API ........................................................................................................ 22
Using data API builder with Azure SQL Database........................................................ 22
Resources............................................................................................................... 22
Multi-model capabilities .............................................................................................. 22
Graph ..................................................................................................................... 23
Spatial .................................................................................................................... 23
REST endpoint ......................................................................................................... 23
Additional resources................................................................................................ 23
Working with JSON in Azure SQL Database ................................................................... 24
Introduction ............................................................................................................ 24
The following JSON scenarios are available ............................................................... 24
Use cases for JSON data in Azure SQL Database ....................................................... 24
Simplify complex data models .............................................................................. 25
Store retail and e-commerce data ......................................................................... 25
Process log and telemetry data ............................................................................. 25
Store semi-structured IoT data .............................................................................. 25
Simplify REST API development ............................................................................. 25
Validate, query, and change JSON data with built-in functions .................................... 25
Video on JSON data in Azure SQL Database ............................................................... 25
Additional resources................................................................................................ 25
Azure Functions .......................................................................................................... 26

2
 Azure Function scenarios ......................................................................................... 27
Creating an Azure Function ...................................................................................... 27
Azure SQL interaction .................................................................................................. 28
Input bindings ......................................................................................................... 28
Output bindings ...................................................................................................... 28
Trigger based functions ............................................................................................ 29
Local development experience .................................................................................... 29
05 Building an AI ready application ............................................................................... 30
Additional resources................................................................................................ 30
AI and Large Language Models (LLMs) .......................................................................... 31
Overview ................................................................................................................. 31
Small Language Models (SLMs) ................................................................................ 32
Selecting an LLM ..................................................................................................... 32
Services vs models .................................................................................................. 32
Open vs closed source ......................................................................................... 33
Text + code .......................................................................................................... 33
Speech to text, text to speech ............................................................................... 33
Image .................................................................................................................. 34
Deploying language models in Azure ..................................................................... 34
Sample code ........................................................................................................... 34
OpenAI models ........................................................................................................... 34
Overview ................................................................................................................. 34
GPT ........................................................................................................................ 35
Embeddings ............................................................................................................ 35
DALL-E ................................................................................................................... 36
Whisper .................................................................................................................. 36
Standard patterns ................................................................................................... 36
RAG .................................................................................................................... 36
CoT ..................................................................................................................... 37
ReAct .................................................................................................................. 37
Prompt engineering ................................................................................................. 37
Vectors in AI applications ............................................................................................ 37
Euclidean distance similarity.................................................................................... 39

3
 Dot product similarity .............................................................................................. 41
Cosine similarity...................................................................................................... 42
Vector storage ......................................................................................................... 44
Additional resources................................................................................................ 44
Samples of AI applications built on Azure SQL Database ............................................... 44
Azure SQL + Azure AI Search..................................................................................... 45
Azure SQL + Azure Promptflow ................................................................................. 45
Azure SQL + Azure OpenAI........................................................................................ 45
Retrieval Augmented Generation (T-SQL sample) ...................................................... 45
Content moderation ................................................................................................ 45
LangChain and Azure SQL Database ......................................................................... 45
End-to-end samples ................................................................................................ 46
Similar content finder ........................................................................................... 46
Session conference assistant ............................................................................... 46
SQL Server database development using prompts as T-SQL development ............... 46
06 Optimizing scale and performance .......................................................................... 47
General performance tips ........................................................................................ 47
Hyperscale tier for Azure SQL Database ....................................................................... 47
Hyperscale capabilities ........................................................................................... 48
Architecture ............................................................................................................ 48
Resources............................................................................................................... 49
Automatic tuning ........................................................................................................ 50
Intelligent query processing ......................................................................................... 51
Monitoring .................................................................................................................. 52
Overview ................................................................................................................. 52
Azure Monitor overview ........................................................................................ 52
Azure database watcher ....................................................................................... 53
Define your monitoring strategy ................................................................................ 54
Application monitoring ................................................................................................ 54
Azure Metrics Explorer ............................................................................................. 55
Application Insights cost management ..................................................................... 55
Additional resources................................................................................................ 55
Database monitoring................................................................................................... 55

4
 Dynamic Management Views (DMVs) ........................................................................ 55
Execution plans ....................................................................................................... 56
Overview of monitoring for Azure SQL Database ........................................................ 57
Diagnostic settings .................................................................................................. 57
Log analytics ........................................................................................................... 58
Query Performance Insight ....................................................................................... 58
Complete monitoring for Azure SQL Database ........................................................... 58
Resources............................................................................................................... 59
Alerting ...................................................................................................................... 59
Guidelines .............................................................................................................. 59
Azure alerting concepts ........................................................................................... 59
Metric alerts ........................................................................................................ 59
Webhooks .............................................................................................................. 60
Metrics resources .................................................................................................... 60
Azure CLI ............................................................................................................. 60
Azure Portal ......................................................................................................... 60
Azure Monitor REST API ........................................................................................ 60
Azure Service Health................................................................................................ 60
Resources............................................................................................................... 61
Best practices ............................................................................................................ 61
Best practices for Azure SQL Database apps ............................................................. 61
1. Co-locate resources ......................................................................................... 61
2. Implement connection pooling .......................................................................... 61
3. Monitor and size containers adequately ............................................................. 61
4. Implement network isolation and SSL connectivity ............................................. 62
5. Retry on transient faults .................................................................................... 62
6. Size database compute resources adequately ................................................... 62
7. Utilize reserved capacity ................................................................................... 62
07 DevOps with Azure SQL Database ........................................................................... 63
Introduction to continuous integration and deployment (CI/CD) ..................................... 63
CI/CD tools ............................................................................................................. 64
Azure App Service Deployment slots ..................................................................... 64
Azure App Service Deployment Center .................................................................. 64

5
 GitHub Actions .................................................................................................... 64
Azure DevOps ...................................................................................................... 65
Infrastructure as Code (IaC) .................................................................................. 65
Deploying to Azure SQL Database using Azure Pipelines ................................................ 66
DACPAC deployment: .............................................................................................. 66
SQL script deployment ............................................................................................ 66
Additional resources................................................................................................ 67
08 Integrating with Azure Services ................................................................................ 68
09 Helpful resources ................................................................................................... 69

6
01 Azure SQL Database essentials
Welcome to developing Azure SQL Database applications on Microsoft Azure! Whether
you’re creating a production application or improving an existing enterprise system, this
guide will take you through the fundamentals of Azure SQL Database application
development to more advanced architecture and design. From beginning to end, this is a
content journey designed to help ensure current or future Azure SQL Database systems
perform at their best even as their usage grows and expands. Azure SQL Database, with its
built-in features designed for creating intelligent applications, offers the ideal starting point
for developing applications that provide rich user experiences through the integration of AI.
This guide outlines available Azure components and how they can be used together for
creating AI assisted Azure applications and customized services backed by Azure SQL
Database. You will learn how to leverage a suite of simple to use, high-value Azure cloud
services in Azure SQL Database architectures. Azure Marketplace provides a vast number
of resources that can help you at every step, so you never have to go it alone!
Because every company and project is unique, this guide provides insightful service
descriptions and tool comparisons to help the reader choose which options best fit their
environment, system, and budget needs. Proven industry architecture examples provide
best practices for solid architecture foundations and potential compliance needs. Efficient
architecture and security practices will avoid the problems and costs of poor design down
the line.
You will also learn how to automate builds and package, test, and deliver applications
based on Azure SQL Database environments. Continuous integration and deployment
(CI/CD) can reduce or completely remove costs related to manual deployment tasks.
Many steps in the application lifecycle go beyond simply building and deploying an
application. This guide will cover how easy it is to monitor system uptime and performance
in the various Azure services. Administrators will appreciate the realistic and
straightforward troubleshooting tips that help keep downtime to a minimum and users
happy.
The ultimate goal is to successfully deploy a stable, performant Azure SQL Database
application running securely in Microsoft Azure using cloud best practices. Let’s start the
journey!

7
02 Introduction to Azure SQL Database
Before jumping into Azure SQL Database, it is important to understand what Azure SQL
Database is and the various development options for it.

What is Azure SQL Database

Azure SQL Database is a fully managed Platform as a Service (PaaS) database engine that
always runs the latest stable version of SQL Server in the Azure Cloud with 99.99%
availability, giving you peace of mind and allowing you to focus on your business
application requirements. With different purchasing models, compute tiers, and service
tiers, you have the flexibility to design and build applications to meet your business needs.

Purchasing models
There are two (2) purchasing models to consider depending on the cost and performance
needs of your project:

• vCore purchasing model: Gives you flexibility, control, and transparency of

resource consumption and has the closest match to resource consumption of on-
premises workloads. For AI-assisted applications, we recommend this model.

• DTU-based purchasing model: Represents a blended measure of CPU, Memory,

Reads, and Writes to meet the application workload requirements. This model can
assist in managing costs during development but will not provide the scale required
when deploying to production. This model is available for backward compatibility
purposes.

Compute tiers
There are two (2) compute tiers to consider depending on the compute resources needed
for a given project:

• Provisioned compute tier: Provides a specific amount of compute resource at a

fixed price per hour regardless of workload. Available in the DTU-based and vCore
purchasing models.
• Serverless compute tier: Auto scales compute resources based on workload
activity and charges per second for the compute used. This is only available in the
vCore purchasing model.

Service tiers
With six (6) service tiers to choose from based on cost, workload, performance, resilience,
and scalability that align closely with our chosen compute tier, we can manage and
maintain our new Azure SQL Database environment.

8
The vCore purchasing model offers three (3) service tiers:

• General Purpose: Designed for common workloads, offering budget-oriented

balanced compute and storage options. This tier has a maximum 2 TB database
size.
• Business Critical: Designed for OLTP applications with high transaction rates and
low latency I/O requirements. This tier has a maximum 4 TB database size.
• Hyperscale: Designed for most business workloads in the cloud, providing the
greatest flexibility and high performance with independently scalable compute and
storage resources. This tier has a maximum 100 TB database size.
The DTU-based purchasing model offers:

• Basic: Best suited for development, testing and workloads. This tier has a
maximum 2 GB database size.
• Standard: Designed the same as the General Purpose tier, except utilizing the
blended resource provisioning. This tier has a maximum 1 TB database size.
• Premium: Designed the same as the Business Critical tier, except utilizing the
blended resource provisioning. This tier has a maximum 4 TB database size.
For AI-assisted and cloud-based applications, we strongly recommend the Hyperscale
tier. This tier allows for the flexibility and scalability required to meet the necessary
processing, storage, and performance requirements of such applications.

Try it out
Start developing on Azure SQL Database now and take advantage of the free trial toget
100,000 vCore seconds of compute every month on the general purpose service tier. Get
your Azure SQL Database free for the lifetime of your subscription with up to 32 GB of data.

Getting started with Azure SQL Database

Before starting any development work, we need to create our development database. As
long as you have an Azure Subscription you are good to start. You can even take advantage
of USD$200 of free credit with the 30 day trial to spin up any azure resource on top of the
Azure SQL Database free offer discussed in the previous section.

How to create an Azure SQL Database

Creating our first database is very simple and quick to do following the Create a single
Azure SQL Database QuickStart guide. Some considerations to make prior to building your
first database are:

• Region: The global location in which you will provision your database.

9
 • SQL Server name: The Microsoft-managed server to which the database will be
deployed. Multiple databases can be created on a SQL Server. However, there are
limits to be aware of when deploying Azure SQL Database onto the server.
• Authentication method: How you will verify your identity to securely connect to
your database.
• Elastic pools: A way for you to group together Azure SQL databases that have
varying and unpredictable usage demands in order to optimize their resource use
and costs.
• Workload environment: Determines if your deployed database is for development
or production purposes. This configuration can have an impact on the default
backup storage you choose. Developer environments will typically prefer budget-
friendly options, while production environments require more robust, expensive
storage systems.
• Service tier: Provides multiple service tiers to choose from based on your
requirements. For AI-assisted and Cloud Associated applications, the Hyperscale
tier provides the ability for rapid scaling of compute resources to accommodate the
typical workloads of cloud applications and AI usage. See the earlier section on
Service tiers for more information.
• Compute tier: Determines resource provisions and costs. See the earlier section
on the Compute tiers for more information.
• Connectivity method: Impacts whether your database can be accessed publicly or
privately. Following the QuickStart will show you how to use a public endpoint that
grants access to your database utilizing a publicly accessible IP Address. This is the
default option when using the QuickStart. However, for production deployments,
we recommend private endpoints for better data security.
• Firewall rules: Impacts the accessibility of the database. In the QuickStart, you can
whitelist your IP Address to have exclusive access. A secure design is outside of the
scope of this guide, but we will provide some tips later on.
The QuickStart provides multiple ways to create your database:

• Azure Portal
• Azure CLI
• PowerShell
Following along in the portal is the easiest way to start and allows you to explore the
various options available during the deployment process. Knowledge of either Azure CLI or
PowerShell makes things easier, as you can build and easily manage your deployment
scripts via your DevOps pipelines directly within source control, which we will cover later in
this guide.

10
How to manage an Azure SQL Database
While Azure SQL Database is a PaaS offering from Microsoft, we are responsible for
managing several components to meet our requirements. Just like creating an Azure SQL
Database in the previous section, we can manage our deployments using:

• Azure Portal
• Azure CLI
• PowerShell
• Transact-SQL (T-SQL)
Monitoring your database is important. Depending on your needs, you may want to change
some of the available configurations to provide a more resilient and/or performant
environment. While we’ll cover database monitoring more in-depth later in the guide, here
is a basic overview of some of things you may want to monitor or reconfigure:

• Compute and storage

o Change service tiers to scale up or down the resources the database
requires.
o Change compute tiers to assist with cost based on workload patterns.
o Change resources (vCore) to scale up or down to assist with performance.
o Configure auto pause to assist in managing costs based on workload
patterns.
o Configure zone redundancy to increase the resiliency and get 99.995%
availability.
o Configure backup storage redundancy to provide multiple copies of your
data, allowing you to recover in the event of a disaster.
• Data management
o Replicas allow for synchronizing data to a replica copy of the database.
• Security
o Configure auditing to meet any compliance standards and identify business
concerns or suspected security violations.
o Configure ledger to protect data from malicious attacks to ensure trust in the
data.
o Configure managed identities to secure connectivity between applications
and the database.
o Data Encryption consists of a number of items, transparent data encryption
and Always Encrypted.
o Server level firewall rules are configured per database or elastic pool at the
server level to restrict access to the database.
• Governance

11
 o Data discovery and classification provides the ability to discover and classify
the data in the database to assist in protecting sensitive data.
o Dynamic data masking provides a way of limiting exposure of sensitive data
by masking the data to non-privileged users.

Available tools to create and manage Azure SQL Database

We have several tools to make source control, deployments, and the use of available
scripting options (PowerShell, AzureCLI, Transact SQL) easy:

• Azure Data Studio: Provides a cross-platform unified tooling experience for data
professionals to easily connect to SQL Server and Azure databases on-premises or
in multi-cloud environments.
• VS Code: Provides a cross-platform tooling experience with extension support for
just about any programming language.
• Visual Studio + SSDT: Turns visual studio into a powerful development
environment for SQL Server, Azure SQL Database and Azure SQL Data Warehouse.
• SQL Server Management Studio: An integrated environment for managing any SQL
Server environment on-premises or multi-cloud. Caters for transact-SQL only unlike
Azure Data Studio or VS Code, where using the terminal CLI code or PowerShell
code is able to be executed.
• Azure Portal: Provides the GUI experience as well as the Azure Cloud Shell
experience, where PowerShell or Bash commands can be entered to manage
resources.

12
03 Connecting and querying Azure SQL Database
This section provides an overview of how to secure the data layer of an application through
Azure SQL Database. It explains a security strategy that adopts a multi-layered, defense-
in-depth approach, as illustrated in the following image, progressing from the exterior
toward the interior:

Security Layers

Security layers protecting Azure SQL Database

Network security
To help protect customer data stored within Azure SQL Database, firewalls prevent
network access to the server until it is explicitly granted based on IP address or Azure
Virtual network traffic origin. Overview of Azure SQL Database firewall.

Access management
Authentication is the process of proving the user is who they claim to be. Azure SQL
Database supports SQL authentication and Microsoft Entra authentication (formerly Azure
Active Directory).
SQL authentication
SQL authentication uses a username and password to authenticate a user’s connection to
Azure SQL Database. When a server is created, you must first establish a server admin
username and password. Using these credentials, a server admin can authenticate to any
database on that server or instance as the database owner. After that, the server admin

13
can create additional SQL logins for other users. It is recommended to NEVER use the
server admin user to allow applications to connect to the database.
Microsoft Entra authentication
Microsoft Entra authentication uses identities in Microsoft Entra ID to connect to Azure
SQL Database. Microsoft Entra authentication allows administrators to manage the
identities and permissions of database users along with other Azure services in one (1)
central location. This minimizes password storage and enables centralized password
rotation policies. This is the recommended approach for authentication, as it makes it easy
to allow other services to connect to Azure SQL via Managed Identities.
Similar to SQL authentication, a server admin called the Microsoft Entra administrator
must first be established to use Microsoft Entra authentication with SQL Database. For
more information, see Connecting to SQL Database with Microsoft Entra authentication.
Microsoft Entra authentication supports both managed and federated accounts. The
federated accounts support Windows users and groups for a customer domain federated
with Microsoft Entra ID.
Microsoft Entra supports several different authentication options, including multifactor
authentication, Integrated Windows authentication, and Conditional Access.

Authorization
Authorization refers to controlling access to resources and commands within a database.
To do this, you will have to assign permissions to a user within a database. Permissions are
ideally managed by adding user accounts to database roles and assigning database-level
permissions to those roles. Alternatively, an individual user can also be granted certain
object-level permissions. For more information, see Logins and users.

Threat protection
Azure SQL Database auditing tracks database activities and helps maintain compliance
with security standards by recording database events to an audit log in a customer-owned
Azure storage account. Auditing allows users to monitor ongoing database activities, as
well as analyze and investigate historical activity to identify potential threats or suspected
abuse and security violations.
Advanced Threat Protection
Advanced Threat Protection analyzes your logs to detect unusual behavior and potentially
harmful attempts to access or exploit databases. Alerts inform you of suspicious activities
like SQL injection, data infiltration, brute force attacks and anomalies in access patterns.
You can view alerts from the Microsoft Defender for Cloud, which provides details of the
suspicious activities and recommendations for further investigation and threat mitigation
measures.

14
Information protection and encryption
Transport Layer Security (Encryption-in-transit)
Azure SQL Database secures customer data by encrypting data in motion with Transport
Layer Security (TLS). Azure SQL Database enforces encryption (SSL/TLS) at all times for all
connections. For further information about TLS and connectivity, see TLS considerations.
Transparent data encryption (TDE)
Azure SQL Database adds a layer of security to help protect raw files and backups from
unauthorized or offline access. Common scenarios include data center theft or unsecured
disposal of hardware or media such as disk drives and backup tapes. TDE encrypts the
entire database using an AES encryption algorithm, which doesn’t require application
developers to make any changes to existing applications.
In Azure, all newly created databases are encrypted by default and the database
encryption key is protected by a built-in server certificate. The service automatically
manages certificate maintenance and rotation with no input from the user. Customers who
prefer to take control of the encryption keys can manage the keys in Azure Key Vault.

Azure Key Vault usage

The support for transparent data encryption (TDE) with the bring your own key (BYOK)
feature empowers you to manage and rotate encryption keys independently using Azure
Key Vault; Azure’s external cloud-based key management system. Should the database’s
permission to access the key vault be withdrawn, it becomes impossible to decrypt and
load the database into memory. Azure Key Vault serves as a centralized platform for key
management, utilizes highly secured hardware security modules (HSMs), and facilitates a
separation of responsibilities between key management and data management, aiding in
the fulfillment of security and compliance standards.

Always Encrypted (Encryption-in-use)

Always Encrypted is designed to safeguard sensitive information, such as credit card
details, national or regional ID numbers, or any data requiring restricted access by
encrypting specific database columns. This encryption even prevents database
administrators or other high-privilege users, who might manage the database but have no
requirement to view the encrypted content, from accessing sensitive data. Encrypted data
is only decrypted during processing by client applications that possess the encryption key.
Importantly, the encryption key remains hidden from the SQL Database and can be
securely stored in the Azure Key Vault.

Dynamic data masking

Dynamic data masking reduces the risk of sensitive data exposure by concealing it from
non-privileged users. This feature proactively identifies potentially sensitive information
within Azure SQL Database and SQL Managed Instance, offering suggestions for masking
15
such data with little to no disruption to the application layer. It achieves this by obscuring
sensitive information in the query results of specified database fields without altering the
actual data stored in the database.

Resources
• Secure Azure SQL Database
• Always Encrypted
• Dynamic Data Masking
• Manage users and logins

16
04 Modern application development
Now that you have familiarized yourself with the core concepts of deploying Azure SQL
Database and some of the features in Azure, you are now ready to learn how to develop
and launch modern cloud-based applications with Azure SQL Database. To give you
practical insights into the architecture, we are going to walk you through the deployment of
a sample application. This application will incorporate a combination of .NET, Python, and
Node technologies, with certain components using containers and others utilizing
serverless services. Now, let’s explore the diverse architectural and deployment strategies
that can help you build your application.

Introduction to the sample application

We’re going to take you step by step through the development process of a single sample
application. By familiarizing yourself with the structure of this application you will have a
solid understanding of the fundamentals of application development in Azure. From there,
you can more easily learn how to make necessary modifications for different deployment
models and architectural progressions.

Sample application overview

Acme is a shared electric vehicle company. Customers can register and pay to use their
vehicles. Initially launching in Seattle, Acme has ambitious plans to expand into other
cities such as Portland, San Diego, Los Angeles, San Francisco, New York, and Miami, with
future aspirations to enter the European and Asian markets.
Acme wants to revolutionize the scooter industry by leveraging extensive data on scooter
utilization and positioning. Their goal is to utilize AI and analytics to enhance vehicle
maintenance and streamline logistics. Acme aims to introduce a “Summon Vehicle”
feature, which would enable customers to request a vehicle through the mobile app,
specify the time and place they need it, and have the vehicle autonomously arrive at the
designated location.
To realize this vision, Acme decides to use Microsoft Azure. Azure’s comprehensive,
developer-centric environment, coupled with its robust analytics capabilities, makes it an
ideal platform for developing Acme’s innovative vision.

Solution architecture
Acme’s platform architecture is designed around a flexible and scalable framework,
utilizing both microservices and modular monolithic structures to support the company’s
strategic objectives as it expands into new markets. The use of microservices ensures the
system’s agility and adaptability, essential for Acme’s growth and diversification. On the
other hand, a modular monolithic architecture helps maintain data integrity, mitigating the
challenges of database proliferation and the complexity of integrating multiple databases.

17
For components of the architecture requiring rapid data exchange—such as payment
processing and live scooter tracking— we employ an event-driven model. This approach
guarantees minimal latency and maximizes efficiency in data transfer across services.

This image shows a sample architecture involving various Azure services and Azure SQL
Database.

Microservice and containerized development

Microservices
Our electric scooter application will use Azure Kubernetes Service (AKS) to orchestrate
microservices to offer resilient, scalable, developer-friendly applications. Unlike
traditional monolithic apps, each service operates independently and can be updated
without redeploying the app. Each service also manages its own stateful layer, meaning
that service teams can perform database schema updates without affecting other
services.
While microservice apps offer major benefits, they require advanced tools and knowledge
of distributed systems. Organizations utilize domain analysis to define optimal boundaries
between services.
On Azure, organizations often deploy microservices to Azure Kubernetes Service through
CI/CD platforms, such as GitHub Actions or Azure DevOps.

18
Resources
• Build microservices on Azure
• Using domain analysis to model microservices

Web apps
Developers can deploy Azure SQL backed apps to Azure on a Windows or Linux
environment through Azure App Service, a PaaS platform that supports popular
frameworks, including PHP, Java, Python, Docker containers, and more. Azure App Service
is compatible with manual deployment mechanisms, including ZIP files, FTP, and local Git
repositories. It also supports automated mechanisms, like GitHub Actions, to deploy
faster and minimize issues. Coupled with powerful management tools, like the Kudu
console, Azure App Service is suitable for many enterprise applications.

Resources
• App Service overview

Serverless compute
Azure Functions, Azure Logic Apps and Azure SQL Database have serverless deployment
options, meaning that customers are billed only for the execution time of their workload.
Azure automatically scales compute resources up and down in response to demand.

Containerized development
Containerizing layers
An application and database built with a specific target environment in mind needs that
environment to be properly configured to support the application and data workload. If an
operations team misses any items, the application will either not load or may error during
runtime.
Containers solve the potential issue of misconfiguration of the target environment. By
containerizing the application and data, the application will run exactly as intended.
Containers can also more easily be scaled using tools such as Kubernetes.
Containerizing an application and data layer can be relatively complex, but once the build
environment is set up and working it is possible to push container updates very quickly to
multi-region load-balanced environments.

Azure Container Instances (ACI)

After application and data layers are migrated to containers, a hosting target must be
selected to run the containers. A simple way to deploy a container is to use Azure
Container Instances (ACI).

19
Azure Container Instances can deploy one (1) container at a time or multiple containers to
keep the application, API, and data contained in the same resource.

Azure Container Apps (ACA)

Azure Container Apps is a serverless platform that allows you to maintain less
infrastructure while running containerized applications. ACA’s provide all the up-to-date
server resources required to keep your applications stable and secure.

App service containers

Developers can extend the benefits of App Service, like scalability, elasticity, and simple
CI/CD integration, to their containerized apps using App Service for Containers. This
offering supports individual containers and multi-container apps through Docker Compose
files. Containers give teams added flexibility beyond the platforms supported directly by
App Service.

Azure Kubernetes Service (AKS)

ACA, ACI and App Service Container services are effective ways to run containers, but they
do not provide many enterprise features: deployment across nodes that live in multiple
regions, load balancing, automatic restarts, redeployment, and more.
Migrating to Azure Kubernetes Service (AKS) will allow the application to leverage all the
enterprise features provided by AKS. AKS offers a managed experience, relieving
customers of infrastructure concerns.

Data API builder

Our sample application utilizes Data API builder for Azure Databases. This significantly
streamlines backend development, enabling developers to construct database endpoints
within hours, not days.
Data API builder securely exposes database objects through REST and GraphQL
endpoints, enabling compatibility with any frontend and providing unparalleled developer
efficiency. Data API builder connects to Azure SQL, SQL Server, PostgreSQL, MySQL, and
Cosmos DB.
Data API builder is open-source and cross-platform. It runs on-premises, in a container, or
in Azure, via Azure Container Apps (ACA), Azure Container Instances (ACI), Azure
Kubernetes Services (AKS), or the database connection feature in Azure Static Web Apps
(SWA). You can learn more at https://aka.ms/dab.

20
This image summarizes the Data API builder architecture.

Features
A list of features and highlights can be found on the official GitHub repository.

General
• Supports Azure SQL, SQL Server, Azure Cosmos DB, Azure Database for Postgres,
and Azure Database for MySQL.
• APIs can be hosted locally, or on services like AKS, ACI, ACA, Static Web Apps, and
App Services.
• Supports collections, tables, views, and stored procedures.
• Development via CLI.
• Application Insights support.
• In-memory caching.

Authentication & authorization

• Support for EasyAuth when running in Azure Static Web Apps.
• Support authentication via OAuth2/JWT/Microsoft Entra ID.
• Role-based authorization using received claims.
• Item-level security via policy expressions.

REST API
• Supports CRUD operations via POST, GET, PUT, PATCH, DELETE.
• Provides filtering, sorting, projection, and pagination.
• Schema declaration through OpenAPI.
21
GraphQL API
• Supports nested queries and mutations.
• Provides filtering, sorting, projection, and pagination.
• Relationship navigation.
Data API builder is built on ASP.NET as a universal REST API controller. The configuration of
its routes, data sources, and entities is managed externally through a JSON configuration
file, allowing for dynamic and flexible API construction.
Additionally, it includes static methods for creating GraphQL object types from SQL table
definitions, which are then made accessible through the ChilliCream GraphQL Platform.

Using data API builder with Azure SQL Database

Creating your first Data API builder configuration is very simple and quick when following
these guides:

• Quickstart guide
• Local development
• Dev Containers
• Using Azure services
• Use Data API builder with Azure SQL and Azure Static Web Apps
• Authentication
• Monitoring
Learn more about the Data API Builder at The Azure SQL Developer channel introducing
Data API builder.

Resources
• Known Issues
• Data API Builder samples

Multi-model capabilities
Our sample application will make use of various data formats. Azure SQL Database offers
a wide range of multi-model capabilities including:

• Graph Processing
• JSON
• Spatial
• OPENXML
• OPENJSON

22
 • XML Indexes
• Key-value pairs
Communication between the Azure Web Application and serverless services will be
undertaken using JSON and/or GraphQL/REST.
OpenAI will use Azure SQL Database’s external REST endpoints.
The backend website will use Django and the REST endpoint asynchronously to
communicate with Azure SQL Database.

Graph
Graph extensions are seamlessly integrated into the SQL Server database engine, utilizing
the same storage engine, metadata, and query processor for both graph and relational
data. This integration allows for querying across graph and relational datasets within a
single query. Furthermore, graph capabilities are enhanced when combined with other
SQL Server technologies, such as columnstore indexes, high availability, R services, and
more. Additionally, SQL graph fully supports all security and compliance features that SQL
Server offers.

Spatial
The Summon Vehicle Service feature of the sample application utilizes spatial data. The
SQL Server Spatial Tools project is an open-source initiative sponsored by Microsoft,
offering a suite of tools designed to work with SQL Server’s spatial types. This collection
delivers a variety of reusable functions that applications can leverage, encompassing data
conversion routines, new transformations, aggregates, and more, to enhance spatial data
handling and operations.

REST endpoint
To find out more about the REST endpoint in Azure SQL Database watch Data Exposed
Video on the REST endpoint available in Azure SQL Database.
We will cover use of the JSON data in the next section of this guide.

Additional resources
• Overview
• SQL Graph database example
• Django and Azure SQL Database REST endpoint
• Multi-model features in Azure SQL Database

23
Working with JSON in Azure SQL Database
Introduction
JSON or JavaScript Object Notation (JSON) is a widely-used textual data format for data
exchange in contemporary web and mobile applications. It serves as a storage format for
unstructured data in log files or NoSQL databases like Azure Cosmos DB. JSON is
commonly utilized by many REST web services, which either return results in JSON format
or accept data in this format. For instance, numerous Azure services, including Azure
Search, Azure Storage, and Azure Cosmos DB, feature REST endpoints that handle JSON
data.
Azure SQL Database offers a hybrid approach that accommodates both relational and
JSON data processing and storage, utilizing the standard T-SQL language. It organizes
JSON document collections within tables, creates relationships among them, and then
integrates strongly typed scalar columns with flexible key/value pairs in JSON columns.
Additionally, it allows for querying across scalar and JSON values in single or multiple
tables using full T-SQL capabilities.
JSON text is stored in either VARCHAR or NVARCHAR columns and indexed as regular text,
ensuring that any SQL Server feature or component that supports text can also support
JSON. Because of this, JSON can interact with other SQL Server functionalities virtually
unrestricted. You can store JSON data in In-memory or Temporal tables, included in Row-
Level Security predicates, among other possibilities.
For example, consider ACME’s scooter app. They want to save data in a flexible format that
integrates neatly with their application’s other functions and are willing to prioritize this
flexibility over performance. They will want to save any new features and options— for
example, user preferences— in JSON format. JSON data is kept as-is within Azure SQL
Database. Communication between the web application, the serverless backend, and
other services will exclusively utilize JSON.

The following JSON scenarios are available

• Formatting relational data in JSON format using FOR JSON clause.
• Working with JSON data.
• Querying JSON data using JSON scalar functions.
• Transforming JSON into tabular format using OPENJSON function.

Use cases for JSON data in Azure SQL Database

JSON support in Azure SQL Database lets you combine relational and NoSQL concepts.
You can easily transform relational to semi-structured data and vice-versa. However, JSON
isn’t a replacement for existing relational models. Here are some specific use cases that
benefit from the JSON support in SQL Server and in SQL Database.

24
Simplify complex data models
Consider denormalizing your data model with JSON fields in place of multiple child tables.

Store retail and e-commerce data

Store information about products with a wide range of variable attributes in a denormalized
model for flexibility.

Process log and telemetry data

Load, query, and analyze log data stored as JSON files with all the power of the Transact-
SQL language.

Store semi-structured IoT data

When you need real-time analysis of IoT data, load the incoming data directly into the
database instead of staging it in a storage location.

Simplify REST API development

Transform relational data from your database easily into the JSON format used by the REST
APIs that support your web site.

Validate, query, and change JSON data with built-in functions

The built-in support for JSON includes the following built-in functions:

• ISJSON
• JSON_ARRAY
• JSON_MODIFY
• JSON_OBJECT
• JSON_PATH_EXISTS
• JSON_VALUE
• JSON_QUERY
• OPENJSON
• SELECT - FOR CLAUSE

Video on JSON data in Azure SQL Database

For an example of how JSON can be used in Azure SQL Database deployments, watch Data
Exposed Video on JSON data in Azure SQL Database.

Additional resources
• JSON data in SQL Server
• Format query results as JSON with FOR JSON

25
 • JSON_ARRAY
• Parse and Transform JSON Data with OPENJSON

Azure Functions
Integration and Automation are crucial parts of your development process. Azure provides
several cloud services that can help you achieve these goals:

• Microsoft Power Automate

• Azure Logic Apps
• Azure Functions
• Azure App Service WebJobs
The service you choose comes down to what you want to achieve. Consider the differences
between these options. In this guide, we will focus on Azure Functions— a serverless
event-driven compute service, providing decoupled apps that give you full control by
writing code and not utilizing a GUI or editing configuration files. Azure Functions can be
combined as a collection to achieve simple or complex requirements.
Take advantage of your existing coding language knowledge when writing your function
code, with Azure Functions supporting:

• C#
• Java
• JavaScript
• PowerShell
• Python
• Custom handlers to use many more languages depending on your needs
Since you are able to use programming languages that you are already familiar with, you
can now also develop with your preferred tools:

• Visual Studio
• VS Code
• IntelliJ IDEA
• JetBrains
When you are ready to deploy your Azure Function, you will need to deploy the code to a
Function App in Azure to meet your deployment requirements such as:

• Tools-based
• App Service Managed
• External pipelines

26
We need to understand the hosting plan options and operating system on which the
Function App is run. Currently, there are three (3) hosting plans:

• Consumption
• Premium
• Dedicated (App Service)

Azure Function scenarios

Our electric scooter application needs to consume change tracking data from our Azure
SQL Database to allow SignalR events to be sent to the Web App and Mobile App. Azure
Functions can integrate with many Azure services to provide feature-rich implementations
that can notify you whenever data is changed. Here are some of the actions that allow you
to track changes in your data:

• SQL trigger: Triggers a given function when a change is detected on a SQL table.
• Input binding: Passes data from the Azure SQL Database to the function’s input
parameter.
• Output binding: Updates the Azure SQL Database with new data.
Some common scenarios on how to utilize Azure Functions are:

• Process file uploads: Allows you to pick up and process data from Azure Storage
sending the results into the main system.
• Real-time streaming and event processing: Allows you to process telemetry data
in near real-time and store in Azure Cosmos DB for use in analytics and
dashboards.
• Machine learning and AI: Allows for inferring on models and not just data
processing.
• Run scheduled tasks: Allows for performing tasks on a schedule you define.
• Build a scalable web API: Allows for HTTP endpoints that run code to connect to
other services.
• Build a serverless workflow: Allows for building out orchestrations using Durable
Functions.
• Create reliable message systems: Allows for integration with service bus queues
and storage queues for advanced event-driven messaging.

Creating an Azure Function

Creating our first Azure Function is very simple and quick to do, following the QuickStart
guide for your tool of choice:

• Visual Studio
• VS Code

27
 • Command Line
The QuickStart will allow for your first HTTP Trigger function as well as look at adding an
Azure Storage Queue to your function. There are a number of Azure Functions patterns you
can create and use:

• Function chaining
• Fan out/Fan in
• Async HTTP APIs
• Monitor
• Human Interaction
• Aggregator

Azure SQL interaction

In the previous section, we introduced the functionality of Azure SQL bindings for Azure
functions, allowing us to read and write to Azure SQL Database by using a programming
language. Having used Data API builder to create the structure in an Azure SQL Database,
we want to utilize Azure SQL Database for what it does best; processing data. This will
allow us to quickly and easily manage the data.
Triggers in SQL Server are created on a table to perform actions on data transactions to
meet business logic requirements. This should not be confused with trigger-based Azure
Functions.
Functions in SQL Server provide several built-in or user-defined functions to perform
common tasks in a reusable fashion. This should not be confused with Azure Functions.

Input bindings
Input bindings read data from an Azure SQL Database passing it to the Azure function. To
retrieve the data from the database we can either have the query text in the function or, for
better performance, security and version control, we can call a stored procedure. To assist
with filtering the data, input bindings support optional parameters being used that would
align with the stored procedure parameters.

Output bindings
Output bindings populate data into an Azure SQL Database from an Azure function. Unlike
input bindings, tables in an Azure SQL Database must exist and match with the object
definitions in the Azure functions to allow for populating data into an Azure SQL Database.

28
Trigger based functions
Trigger-based functions allow for easy extraction of data from an Azure SQL Database
when data changes occur. To accomplish this, Change Tracking must be enabled on the
relevant tables in the database.

Local development experience

Implementing continuous integration and deployment is important in any application
development environment. While we will cover this in more detail later, being able to set
up and use local environments can reduce costs and even give us a head start on
development before all of the production environment resources are available.
Setting up a local development environment depends on your programming language and
tooling preferences. There are also pre-defined templates that give you a place to start
developing function app projects. This allows for developing, testing, and debugging code
against real function runtime on your local environment:

• Visual Studio Code

• Command prompt
• Visual Studio
• Maven
We can also set up a local development experience for Azure SQL Database that can be
linked to a local application development environment. We have some pre-requisites that
we need to review and setup first, then we can run through the QuickStart that will allow us
to setup and create our first database project. We can then locally deploy the project with
the assistance of the Azure SQL Database emulator extension in either VS Code or Azure
Data Studio.
The Azure SQL Database emulator is a local version of Azure SQL Database deployed in a
local Docker container with an image from the Microsoft Container Registry (MCR). This
gives you near full functionality depending on if you choose the Full image (requires more
resources as it gives you access to advanced features like in-memory optimized tables,
geo-spatial data types and more) or the Lite image.

29
05 Building an AI ready application
In today’s rapidly evolving technological landscape, the intersection of artificial
intelligence (AI) and database management systems, particularly Azure SQL Database,
presents fertile ground for innovation that developers should keenly explore. Azure SQL
Database’s high-performance, scalability, and security makes it an excellent platform for
developing sophisticated applications. When coupled with AI, Azure SQL Database’s
potential to process, analyze, and utilize data skyrockets.
Azure SQL Database can be used to build intelligent applications that include AI features,
such as recommenders, and Retrieval Augmented Generation (RAG) patterns, as the
following diagram demonstrates:

This image shows a sample architecture involving AI services and Azure SQL Database.
You can read more about the sample architecture here.
For developers looking to stay at the forefront of innovation and drive forward the
capabilities of modern applications, delving into the synergies between AI and Azure SQL
Database is not just an opportunity, it’s a necessity. Integrating these revolutionary
advancements can enhance application performance, engage users more effectively, and
ultimately, shape the future of digital experiences.
This section provides an overview of using artificial intelligence (AI) options, such as
OpenAI and vectors, to develop intelligent applications with Azure SQL Database.

Additional resources
• Intelligent applications with Azure SQL Database
Microsoft has created several YouTube videos that explain some of the basic concepts
around generative AI:

30
 • AI in a Minute: Generative AI - What it is, why it’s groundbreaking.
• AI in a Minute: Large Language Models - Why they matter, how they work.
• AI in a Minute: Prompt Engineering - What it means, how to apply it.
• AI in a Minute: Vector Search - What it does, why it’s relevant.
• AI in a Minute: Responsible AI - How to think about it.

AI and Large Language Models (LLMs)

Overview
Large Language Models (LLMs) are AI models trained on extensive text datasets, utilizing
deep learning architectures like Transformers to mimic and generate human-like language.
Large language models leverage methodologies as Retrieval Augmented Generation (RAG)
to empower developers to craft user-friendly AI-driven applications. These models are
versatile in natural language understanding and generation, and their design, training data,
and specific use cases guide the selection process for optimal application and
performance enhancement. Azure SQL Database’s numerous features support this
pattern, establishing it as an ideal choice for developing intelligent applications.
Key characteristics and capabilities of Large Language Models include:

• Scale: The hallmark of Large Language Models (LLMs) like GPT-4 is their vast scale,
featuring hundreds of millions to even trillions of parameters. This vast scale equips
these models with the ability to discern intricate language patterns.
• Pre-training: LLMs are pre-trained on expansive text collections sourced from the
internet. This foundational training imbues these models with an understanding of
grammar, syntax, semantics, and wide-ranging knowledge about both language and
the world at large.
• Fine-tuning: Following pre-training, LLMs can undergo fine-tuning with more
focused datasets tailored to particular tasks or fields. This step refines their
capabilities, making them adept at executing specific applications, including text
classification, translation, summarization, and answering questions.
Your choice of model comes down to three major considerations:

• What is the goal

• What does the data look like
• How much budget is available
Moreover, an application or use case may require more than the model’s basic built-in
capabilities. In these cases, developers must integrate an LLM model with company-
specific data. Several approaches for this integration will be explored in detail in the
upcoming sections.

31
Check out the YouTube Video: AI in a Minute: Large Language Models.

Small Language Models (SLMs)

Large Language Models (LLMs) are trained on extensive text datasets, often encompassing
over 100 billion parameters as seen in models like GPT-3/4. Small Language Models
(SLMs), while serving similar purposes, are defined by their smaller size, typically under
100 million parameters. This makes SLMs more efficient, economical, and easier to
customize than their larger counterparts. SLMs have faster inference speeds, reduced
memory and storage requirements, and lower costs for training and operation. However,
the smaller size does reduce the model’s overall capabilities and capacity compared to
giants like GPT-3/4.

Selecting an LLM
Before selecting an LLM model, there are a few key considerations to think about:

• Business use case: What are the specific tasks the business needs the AI solution
to perform? Each LLM is designed for different goals, such as text generation,
language translation, image generation, answering questions, code generation, etc.
• Pricing: For cases where there may be multiple LLMs to choose from, the pricing of
the LLM could be a factor to consider. For example, when choosing between the
current GPT and previous versions of GPT, it may be worth considering that the
overall cost of current GPT may be higher than previous versions due to compute
power that may be required for the current version of GPT.
• Accuracy: For cases where there may be multiple LLMs to choose from, the
comparison of accuracy between them may be a factor to consider.
• Quotas and limits: The Azure OpenAI service has quotas and limits to keep in mind.
This may affect the performance and pricing of the AI solution. Additionally, some
quotas and limits may vary depending on the Azure region used to host the service.
Consider the potential impact of these during the design phase of your solution.

Services vs models
In the AI ecosystem, distinguishing between a service and a model is crucial. A service
integrates models with data and other components to create a user-friendly product, often
with added functionalities like APIs or GUIs and optimized for production. A model,
meanwhile, constitutes the underlying neural network architecture and its parameters.
Services, such as Microsoft Azure OpenAI, incur a cost due to their convenience,
scalability, and additional features like security and responsible AI frameworks. This is in
contrast with models that require hardware and infrastructure investments if deployed
independently.

32
Open vs closed source
Large Language Models (LLMs) can be distinguished by their availability as either open or
closed source. Open-source models like Alpaca, Bloom, and LLaMA are accessible for
public use and modification, though they may lack optimization for production and have
uncertain long-term support.
Closed-source models, owned by companies like OpenAI and Google, are often tailored
for production but restrict user access for inspection or customization, and usage might
incur costs or subscription fees. This categorization affects the models’ adaptability and
performance, and the users’ ability to control training data and ensure responsible AI
practices.

Text + code
Text and code generation models are models that do just that: generate text or code. These
models are often used for text summarization, translation, and question-answering. Text
generation models are usually trained on large datasets of text, such as BookCorpus, and
can be used to generate new text or to answer questions. Code generation models, like
CodeParrot, are often trained on large datasets of code, such as GitHub, and can be used
to generate new code or to fix bugs in existing code.

Speech to text, text to speech

Using LLMs to process audio-to-text has become very common. There are several benefits
to using AI to do this:

• Improved accuracy: LLMs can improve the accuracy of speech recognition

systems in noisy environments.
• Accents: LLMs are more robust to accents than traditional speech recognition
systems. This is because LLMs are trained on a massive dataset of text from a
variety of speakers.
• Scalability: LLMs can be scaled to handle large volumes of audio data. This makes
them ideal for use in areas such as call centers and customer service.
Microsoft provides several options for using speech-to-text and vice versa through the
Azure AI Services offerings as well as the model registries in AI Studio.
For more information, check out the following resources:

• Speech service documentation

• Azure Speech Studio
• Azure AI Studio models registry

33
Image
Image generation models are used for image editing, image synthesis, and image
translation. They can be used to generate new images or to edit existing images with
inpainting, super-resolution, and colorization techniques. Examples include DALL-E-3 and
Stable Diffusion models. Developers often use large image datasets, such as LAION-5B, to
train these models.

Deploying language models in Azure

Azure OpenAI is the most common and practical way to gain access to various Large
Language Models.
Azure OpenAI supports several models, however, due to the ever-changing landscape,
these models are subject to change. To see the latest models available, reference Azure
OpenAI Service models.

Sample code
The concepts presented here can be illustrated by the sample code provided in the
following links.

• Azure OpenAI – Generate embeddings for RAG and integrate with any model
supported by Azure OpenAI.
• Vectors – Learn how to store and query vectors in Azure SQL Database.
• Azure AI Search – Use Azure SQL Database together with Azure AI Search to train
LLM on your data.
• Intelligent applications – Learn how to create an end-to-end solution using a
common pattern that can be replicated in any scenario.
• Copilot – Learn about the set of AI-assisted experiences designed to streamline the
design, operation, optimization, and health of Azure SQL Database-driven
applications.

OpenAI models
Overview
OpenAI is a leading AI research organization best known for developing advanced
generative models like GPT-3 and GPT-4. Azure OpenAI combines these models with
Azure’s security and enterprise features, providing customers with advanced language AI
capabilities, responsible content filtering, and seamless API integration for developing
generative AI applications.
Learn more about Azure OpenAI.

34
Azure OpenAI is powered by a diverse set of models with different capabilities.

Model Description
GPT-3.5 A set of models that improve on GPT-3 and can understand and
generate natural language and code.
GPT-4 A set of models that improve on GPT-3.5 and can understand and
generate natural language and code.
Embeddings A set of models that can convert text into numerical vector form to
facilitate text similarity.
DALL-E A series of models that can generate original images from natural
language.
Whisper A series of models that can transcribe and translate speech to text.

GPT
GPT stands for Generative Pre-trained Transformer, and it refers to a series of large
language models developed by OpenAI. The GPT models are neural networks pre-trained
on vast amounts of data from the internet, making them capable of understanding and
generating human-like text.
Here’s an overview of the major GPT models and their key characteristics:

• GPT-3: Released in June 2020, GPT-3 is one of the most extensive and potent
language models available. It showcases exceptional ability across various natural
language processing tasks, including text completion, translation, and question-
answering, with fluency comparable to human levels. It is offered in multiple sizes
from 125 million to 175 billion parameters.

• GPT-4: The latest GPT model was released in March 2023. It has 1.76 trillion
parameters. GPT-4 surpasses the accuracy of all prior OpenAI models in solving
complex problems. Optimized for chatting similarly to GPT-3.5 Turbo, it also excels
at traditional completion tasks.

The advancements in GPT-4 mark a shift towards conversational interfaces in language

model design. Unlike the earlier GPT-3 iterations that operated on a simple text input-
output basis, these newer models adopt a chat-oriented approach. They are designed to
process inputs as parts of a conversation and generate responses as if they were
messages in a chat. This enhances their performance in multi-turn conversations, though
they remain effective outside chat contexts as well.

Embeddings
Embeddings, such as the text-embedding-3-small model, measure the relatedness of
text strings.

35
Embeddings are commonly used for the following:

• Search - Results are ranked based on their relevance to a search query.

• Clustering - Text strings are grouped by similarity.
• Recommendations - Items with related text strings are recommended.
• Anomaly detection - Outliers with little relatedness are identified.
• Diversity measurement - Similarity distributions are analyzed.
• Classification - Text strings are classified by their most similar label.
A great article on embeddings can be found here.

DALL-E
DALL-E is a model that can generate original images from a natural language text
description given as input.

Whisper
Whisper is a speech recognition model, designed for general-purpose applications.
Trained on an extensive dataset encompassing diverse audio inputs, Whisper operates as
a multi-tasking model capable of executing tasks like multilingual speech recognition,
speech translation, and language identification.

Standard patterns
RAG
Retrieval Augmented Generation (RAG) is a technique that allows for the inclusion of
external data, such as from databases or web endpoints, into the prompting process. This
ensures that relevant information can be fetched and incorporated into the user’s prompt.
Large Language Models (LLMs) are constrained by the data they were trained on, meaning
they lack knowledge of events occurring post-training and cannot access private
information (e.g., internal company data). RAG addresses this by enhancing prompts with
external data snippets, mindful of prompt size limitations. Tools like vector search in Azure
AI Search support this by retrieving pertinent data segments from a range of specified
sources to enrich the prompt context.
This method proves invaluable for businesses lacking the data, time, or resources to fine-
tune an LLM for specific tasks, aiming to boost performance while mitigating the risks of
inaccuracies or inappropriate content.
A simple RAG pattern utilizing Azure SQL Database could be:

• Insert data into an Azure SQL Database table.

• Link Azure SQL Database to Azure AI Search.

36
 • Create an Azure OpenAI GPT4 model and connect it to Azure AI Search.
• Chat and ask questions about your data using the trained Azure OpenAI model from
your application and from Azure SQL Database.

CoT
Chain of Thought (CoT) prompting is a new method that encourages a Large Language
Model (LLM) to articulate its reasoning. The core concept behind CoT is that by providing
the LLM with a few examples that outline the reasoning process, the model is prompted to
mirror this process in its responses, often leading to more precise outcomes.
CoT tends to improve performance primarily with models around the size of 100 billion
parameters. Smaller models often generate illogical reasoning sequences, resulting in
reduced accuracy compared to traditional prompts. Generally, the effectiveness of CoT
prompting scales with the model’s size, with larger models experiencing more significant
enhancements in performance.

ReAct
ReAct is inspired by the synergies between reasoning and acting which allow humans to
learn new tasks and make decisions. ReAct is a general paradigm that combines reasoning
and acting when working with LLMs. ReAct prompts LLMs to generate verbal reasoning
traces and actions for a task. This allows the system to perform dynamic reasoning to
create, maintain, and adjust plans for acting while also enabling interaction to external
environments to incorporate additional information into the reasoning.
The first step is to select cases from a training set and compose ReAct-format outcomes.
These are used as few-shot examples in the prompts and consist of multiple thought-
action-observation steps. This is repeated over many iterations until the desired outcome
is achieved.

Prompt engineering
Prompt engineering is the iterative process of designing, evaluating, and optimizing
prompts to produce consistently accurate responses from language models for a
particular problem domain. It involves designing and refining the prompts given to an AI
model to achieve desired outputs. Prompt engineers experiment with various prompts,
test their effectiveness, and refine them to improve performance. Predefined metrics such
as accuracy, relevance, and user satisfaction measure the impact of prompt engineering.

Vectors in AI applications
Vector embeddings are a powerful technique widely used in fields such as natural
language processing and computer vision. Assessing the similarity between vector

37
embeddings is a critical task in applications like semantic search, recommendation
systems, anomaly detection, among others.
A vector is a mathematical concept used in linear algebra and geometry to represent
quantities that have both magnitude and direction. In the context of machine learning,
vectors are often used to represent data points or features.

Diagram showing a simple vector.

Some key vector attributes and operations include:

• Dimension: The dimension of a vector is the number of elements that it contains. It

is simple to visualize vectors with three dimensions or less, but vectors can have
many more than simply three dimensions. Vectors that encode words and text tend
to have hundreds or thousands of dimensions.

• Magnitude: The magnitude of a vector is a non-negative number that represents the

vector’s size or length. Magnitude can also be referred to as the norm, and can be
denoted with ||v|| or |v|. There are many different definitions of magnitude or norm,
but the most common is the Euclidean norm or 2-norm.

• Unit vector: A unit vector is a vector with a magnitude of one. In the example above,
vector1 and vector2 are unit vectors.

• Direction: The direction of a vector specifies the line along which the vector points.
Direction can be represented using angles, unit vectors, or coordinates in different
coordinate systems.

• Dot product (scalar product): The dot product of two vectors, u and v, is a number
given by u ⋅ v = ||u|| ||v|| cos(θ), where θ is the angle between the two vectors.
Another way to compute the dot product is to do an element-wise multiplication of
38
 u and v and sum the results. The dot product is one of the most important and
widely used vector operations because it measures the similarity between two
vectors.

• Orthogonal vectors: Vectors are orthogonal if their dot product is zero, meaning
that they are at a 90-degree angle to each other. Think of orthogonal vectors as
being completely unrelated to each other.

• Dense vector: A vector is considered dense if most of its elements are non-zero.
Words and text are most usefully represented with dense vectors because each
dimension encodes meaningful information.

Euclidean distance similarity

Euclidean distance is the straight-line distance between two vectors in a multidimensional
space. It is computed as the square root of the sum of the squares of the differences
between the vectors’ corresponding components.
A primary use case for Euclidean distance in AI applications is in the K-Nearest Neighbors
(KNN) algorithm. In this context, Euclidean distance is used to identify the closest
neighbors of a data point, which is fundamental for classification and regression tasks. By
measuring the straight-line distance between points in a feature space, KNN determines
which data points are most similar to a given query point. This proximity information is then
used to predict the label of the query point based on the majority vote or average from its
nearest neighbors, making Euclidean distance a critical component in the effectiveness
and accuracy of the KNN algorithm.

39
Euclidean Distance Measurement in two dimensions.
The equation for calculating the Euclidean distance between two vectors a and b is:

Euclidean Equation.
To calculate the Euclidean distance between two vectors a and b, the equation first
calculates the difference between the first components of the two vectors (a1-b1), then
the difference between the second components (a2-b2), and so on, until it reaches the nth
component (an-bn). The differences are then squared and added together, and the square
root of the sum is taken to give the final distance.

40
 • Inner product – The product of the magnitudes of two vectors and the cosine of the
angle between them. Usually used for natural language processing (NLP) vector
similarity.
• Cosine similarity – The cosine of the angle between two vectors in a vector space.
• Hamming distance – For binary-coded vectors, the number of bits that differ
between the two vectors.

Dot product similarity

The dot product similarity metric for two vectors is calculated by adding the products of
the vectors’ corresponding components. The dot product for vectors a and b is calculated
as follows:

Dot Product Similarity.

This is where a and b are the vectors being compared and ai and bi are the components of
the vectors. The dot product is calculated by multiplying the vector components and
adding the results.

41
The dot product can also be expressed as the product of the magnitudes of the vectors and
the cosine of the angle between them:

Dot Product Similarity.

A main use case for Dot Product Similarity in AI applications is in recommendation
systems, particularly in collaborative filtering. Dot Product Similarity measures the
similarity between users or items by calculating the dot product of their feature vectors.
This approach is essential for identifying users with similar preferences or items that share
similar characteristics.

Cosine similarity
Cosine similarity is a measure of the angle between two vectors. It is computed by taking
the dot product of the vectors and dividing it by the product of their magnitudes. This
metric is not affected by the size of the vector but only by the angle between them. This
means that vectors with large or small values will have the same cosine similarity as long
as they point in the same direction.
A main use case for Cosine similarity in AI applications is in text analysis and natural
language processing (NLP), particularly for document similarity and information retrieval.

42
Cosine similarity measures the cosine of the angle between two non-zero vectors, making
it ideal for comparing texts irrespective of their size.
The cosine similarity is calculated below for vectors a and b:

This is where a and b are the vectors being compared, “•” stands for the dot product, and
||a|| and ||b|| stand for the vectors’ lengths. The cosine similarity is between -1 and 1, where
1 means an angle of 0 (vectors are as close as they can be), 0 means orthogonal, and -1
means that the vectors are pointing in opposite directions.

Cosine similarity.
The process begins with computing the dot product of two vectors by multiplying their
corresponding components and summing those products. This dot product is then divided
43
by the multiplication of the vectors’ magnitudes, which are determined by the square root
of the sum of the squares of their components.
When the model employs cosine similarity for training, one can use either cosine similarity
directly or normalize and use the dot product for comparison, as these approaches are
mathematically equivalent. The choice between normalization and direct cosine similarity
depends on the specific application and its requirements.
Cosine similarity is particularly useful in applications like semantic search and document
classification, where it helps compare the orientation of vectors, reflecting the documents’
content. It is also valuable in recommendation systems, recommending items to users
based on their previous interactions, by comparing the similarity in direction of behavior
vectors.
From a mathematic perspective, cosine similarity measures the cosine of the angle
between two vectors projected in a multidimensional space. This measurement is
beneficial because if two documents are far apart by Euclidean distance because of size,
they could still have a smaller angle between them and therefore higher cosine similarity.
For more information about cosine similarity equations, see Cosine similarity.

Vector storage
Once embeddings have been generated, they must be stored somewhere. This could be in
memory locally, or remotely. It could also be persisted to disk storage. Vectors can be
efficiently stored in Azure SQL Database using columnstore indexes. There is no specific
data type available to store a vector in Azure SQL Database, but a vector is basically just a
list of numbers. Therefore, storing a vector in a table becomes straightforward by
dedicating a column for vector data, with each vector element occupying a single row. To
enhance storage efficiency and searchability for vectors, a columnstore index can be
employed.

Additional resources
• Vector Search with Azure SQL Database
• Intelligent applications with Azure SQL Database
• Example Source Code

Samples of AI applications built on Azure SQL Database

This section lists samples meant to help design AI applications built on data from Azure
SQL Database. The samples illustrate key technical concepts and demonstrate workflows
that integrate Azure SQL data with other popular AI application components inside and
outside of Azure.

44
Azure SQL + Azure AI Search
The AzureSQL_CogSearch_IntegratedVectorization sample notebook shows a simple AI
application that recommends products based on a database of user reviews, using Azure
AI Search to store and search the relevant data. It highlights new preview features of Azure
AI Search, including automatic chunking and integrated vectorization of user queries.

Azure SQL + Azure Promptflow

The AzureSQL_Prompt_Flow sample shows an E2E example of how to build AI applications
with Prompt Flow, Azure AI Search, and your own data in Azure SQL Database. It includes
instructions on how to index your data with Azure AI Search, a sample Prompt Flow local
development that links everything together with Azure OpenAI connections, and also how
to create an endpoint of the flow to an Azure Machine Learning workspace.

Azure SQL + Azure OpenAI

This example shows how to use Azure OpenAI from Azure SQL Database to get the vector
embeddings of any chosen text, and then calculate the cosine similarity against the
Wikipedia articles (for which vector embeddings have been already calculated) to find the
articles that covers topics that are close - or similar - to the provided text.

Retrieval Augmented Generation (T-SQL sample)

This example provides a step-by-step guide on how to use Azure SQL Database to do
Retrieval Augmented Generation (RAG) using the data you have in Azure SQL and
integrating with OpenAI, directly from the database itself. You’ll be able to ask queries in
natural language and get answers from the OpenAI GPT model, using the data you have in
Azure SQL Database.

Content moderation
This example showcases two T-SQL scripts that call Azure OpenAI Content Safety and
Language AI. The Content Safety example will analyze a text string and return a severity
rating in four categories: violence, sexual, self-harm, and hate. The Language AI script will
analyze text and return what PII it found, what category of PII it is, and redact the results to
obfuscate the PII in the original text string.

LangChain and Azure SQL Database

This example contains two python notebooks that use LangChain to create a Natural
Language to SQL (NL2SQL) agent against an Azure SQL Database. The notebooks use
either Azure OpenAI or OpenAI for the LLM. To get started immediately, you can create a
GitHub codespace on this repository, use the terminal to change to the LangChain
directory, and follow one of the notebooks.

45
End-to-end samples
Similar content finder
OpenAI embeddings, and thus vectors, can be used to perform similarity searches and
create solutions that provide customers with a better user experience, better search
results, and a more natural way to find relevant data in a reference dataset. Due to its
ability to provide an answer even when search requests do not perfectly match given
content, similarity search is ideal for creating recommenders. A fully working end-to-end
sample is available here.

Session conference assistant

This example demonstrates how to build a session assistant using Jamstack, Retrieval
Augmented Generation (RAG), and Event-Driven architecture, using Azure SQL Database
to store and search vectors embeddings generated using OpenAI. The solution is built
using Azure Static Web Apps, Azure Functions, Azure SQL Database, and Azure OpenAI. A
fully working, production ready version of this sample is available here.

SQL Server database development using prompts as T-SQL development

In this notebook, you will learn how to use prompts as a method to develop and test
Transact-SQL (T-SQL) code for SQL Server databases. Prompts are natural language
requests that can be converted into T-SQL statements by using generative AI models, such
as GPT-4. This can help you in writing code more quickly, easy, and accurately, while also
facilitating learning from the generated code examples.

46
06 Optimizing scale and performance
Now that we have deployed our AI-assisted application workloads to Azure, we can focus
on optimization. Operation teams must establish performance baselines before fine-
tuning their databases to ensure that changes, especially those requiring application
downtime, are worthwhile. If you can, simulate your workload in a test environment and
make adjustments there before implementing changes in a production environment.
Before jumping into more specific and rigorous optimization efforts, here are a few general
tips that can improve performance:

General performance tips

Here are some basic tips to enhance the performance of an Azure SQL Database
application and database workloads:

• Monitor your environment.

• Ensure the input/output operations per second (IOPS) are sufficient for the
application needs. Keep the IO latency low.
• Create and tune the table indexes to assist in avoiding full table scans.
• Perform regular database maintenance.
• Make sure the application/clients (e.g. App Service) are geographically located as
close as possible to the database to minimize network latency.
• Use accelerated networking for the application server if you use an Azure virtual
machine, Azure Kubernetes Service, or Azure App Services.
• Use Azure Application Gateways with Azure Firewalls to assist with security and
appropriate load balancing.
• Use connection pooling when possible. Avoid creating new connections for each
application request. Utilize load balancing where possible to balance your workload
to multiple read replicas as demand requires.
• Set timeouts when creating transactions.
• Set up read replica to distribute read-only queries and perform analytics, thereby
offloading workloads from the primary database.
• Temporarily scale your Azure SQL Database resources for taxing tasks. Once your
task is complete, scale it down.
See Tune applications and databases for performance in Azure SQL Database.

Hyperscale tier for Azure SQL Database

To support the variable workload of the sample application, we recommend the
Hyperscale tier for Azure SQL Database. The Hyperscale service tier is suitable for all
workload types. Its cloud-native architecture provides independently scalable compute

47
and storage to support the widest variety of traditional and modern applications. The
compute and storage resources in Hyperscale significantly exceed the resources available
in the General Purpose and Business Critical tiers.

Hyperscale capabilities
The Hyperscale service tier in Azure SQL Database provides the following additional
capabilities:

• Rapid scale up - you can constantly scale up your compute resources to

accommodate heavy workloads when needed, and then scale the compute
resources back down when not needed.
• Rapid scale out - you can provision one or more read-only replicas for offloading
your read workload and for use as hot-standbys.
• Automatic scale-up, scale-down, and billing for compute based on usage with
serverless compute.
• Optimized price/performance for a group of Hyperscale databases with varying
resource demands with elastic pools (in preview).
• Autoscaling storage with support for up to 100 TB of database or elastic pool size.
• Higher overall performance due to higher transaction log throughput and faster
transaction commit times regardless of data volumes.
• High availability configuration flexibility.
• Fast database backups (based on file snapshots) regardless of size with no I/O
impact on compute resources.
• Fast database restores or copies (based on file snapshots) in minutes rather than
hours or days.
The Hyperscale service tier was chosen for the sample application as this tier provides
higher performance, availability, compute scalability, and faster storage. It supports the
widest variety of workloads and allows for autoscaling storage size up to 100 TB, fast
vertical and horizontal compute scaling, and fast database restore.

Architecture
The Hyperscale service tier utilizes an architecture with highly scalable and separate
storage and compute tiers. This section describes the components that enabled the
sample application to quickly scale the Hyperscale database while benefiting from nearly
instantaneous backups and highly scalable transaction logging.
Traditional database engines centralize data management functions in a single process.
Even so-called distributed databases in production today have multiple copies of a
monolithic data engine. Hyperscale databases follow a different approach. Hyperscale
separates the query processing engine, where the semantics of various data engines
diverge, from the components that provide long-term storage and durability for the data. In

48
this way, storage capacity can be smoothly scaled out as far as needed. The initial storage
limit is 100 TB.
All network communication between Hyperscale components uses Azure network
infrastructure with built-in redundancy.
High-availability secondary replicas and named replicas are optional compute nodes that
can be added on demand. Both share the same storage components, so no data copy is
required to spin up a new replica. A geo-secondary replica can be added on-demand in the
same or a different Azure region. For data protection and redundancy, geo-secondary
replicas have storage components that are separate from those used by the primary
replica. The following diagram illustrates the functional Hyperscale architecture:

Hyperscale Architecture.

Resources
• Hyperscale FAQ
• Performance Diagnostics in Hyperscale
• Hyperscale Read Replicas

49
Automatic tuning
Acme’s electric scooter application collects data from many data sources such as the
telemetry service, Web App, and Mobile App. To allow for the best user experience
possible, the application needs to provide this information promptly and consistently.
Automatic tuning uses AI and machine learning to continuously optimize performance and
stabilize workloads based on data from the Azure SQL Database.

This image shows an overview of how automatic tuning works.

Once enabled, automatic tuning continually monitors application workloads and applies
optimization recommendations. After applying a recommendation, the system monitors
the change to ensure improvement and rolls it back if regression is detected.
Optimizations are only applied during low utilization periods, minimizing impact on
workloads. The system can also temporarily disable tuning operations to protect workload
performance.
Automatic tuning provides the following three (3) options:

50
 • Create index: Identifies and creates appropriate indexes on tables with clustered
indexes of heaps less than 10GB in size.
• Drop index: Identifies and drops indexes that are unused for 90 days and drops
duplicate indexes.
• Force last good plan: Identifies queries using an execution plan that is slower than
the previous good plan and forces the queries to use the last known good plan.
All recommendations are viewable in the Azure portal allowing for understanding what is
being undertaken as part of the automatic tuning.

Intelligent query processing

Automatic tuning can only provide improvements to a point. To further improve the
performance of our application’s database workload, we should utilize Intelligent Query
Processing.
At the time of this guide, Intelligent Query Processing has nine (9) major features that
assist in optimizing workload performance:

• Batch mode adaptive joins: Defers the choice of which join method to use until
after the input has been scanned to ensure the optimal method is used. Adaptive
Join can also switch to a more optimal method during execution.
• Interleaved execution for MSTVFs: Improves performance by using row counts
returned from the function to make appropriate query plan decisions, rather than
fixed estimates.
• Scalar UDF inlining: At execution time, the function code is transformed, allowing
for better query plan choices.
• Table variable deferred compilation: Allows for improving performance by using
actual table variable row counts not estimated values.
• Parameter sensitivity plan optimization: Allows for improving performance on
those workloads, where a cached plan is not optimal for all executions based on the
parameter values being passed.
• Approximate query processing: Allows for improving performance across large
datasets where absolute precision is not needed over responsiveness.
• Batch mode on rowstore: Allows for improving performance for analytic workloads
without requiring columnstore indexes.
• Query processing feedback features: Allows for improving performance with
several different feedback mechanisms to adjust the resources being used.
• Optimized plan forcing: Allows for improving performance by identifying when a
query plan has regressed and is replaced with the last known good plan. This is
what is used in Automatic Tuning.

51
Monitoring
Once the application and database for the sample application are deployed, the next step
is to manage the new cloud-based data workload and supporting resources. Microsoft
proactively monitors and takes necessary actions to ensure databases are highly available
and perform at the expected level. For more information you can read the Azure SQL
Database SLAs.

Overview
Proper monitoring helps with the following:

• Understanding resource utilization.

• Analyzing workload connection metrics.
• Failure analysis and remediation.
• Environment performance analysis and scaling adjustments.
• Historical performance review.
Azure monitors all of these operational activities using tools such as Azure Monitor, Log
Analytics, and Azure Sentinel. In addition to the Azure-based tools, external security
information and event management (SIEM) systems can be configured to consume these
logs as well.
Alerts should be created to warn administrators of outages, operational performance
problems, or suspicious activities. If a particular alert event has a well-defined remediation
path, alerts can automatically fire Azure runbooks to address and resolve the event.
This section will focus on these monitoring concepts:

• Azure Monitor overview and strategy.

• Application monitoring.
• Database monitoring.
• Alerts and strategies.

Azure Monitor overview

Azure Monitor is an Azure native platform service that provides a centralized area for
monitoring all your Azure resources. It monitors all layers of the Azure stack, starting with
tenant services, such as Microsoft Entra, subscription-level events, and Azure Service
Health.
At lower levels, it monitors infrastructure resources, such as VMs, storage, and network
resources. Administrators and developers employ Azure Monitor to consolidate metrics
about the performance and reliability of their various cloud layers, including Azure SQL
Database. Management tools, such as Microsoft Defender for Cloud and Azure

52
Automation, also push log data to Azure Monitor. The service aggregates and stores this
telemetry in a log data store optimized for cost and performance.

This image clarifies how Azure Monitor integrates with various Azure data sources and
management tools.
For more information on what can be monitored, read: What is monitored by Azure
Monitor?

Azure database watcher

Database watcher is a managed monitoring solution for databases in the Azure SQL
Family. Unlike Azure monitor, this is dedicated to monitoring your Azure SQL Database,
providing information on database performance, configuration and health. While the
collected data is stored in a central data store within your subscription, and has some out
of the box dashboards, you have the ability to analyze the collected data in Azure Data
Explorer, Kusto Query Language (KQL) or T-SQL to build custom visualizations and
dashboards.

53
This image shows an overview of how database watcher works.

Define your monitoring strategy

Administrators should plan their monitoring strategy and resource configuration for the
best results. Some data collection and features are free, while others have associated
costs. Focus on maximizing your applications’ performance and reliability. Identify the
data and logs that indicate the highest potential signs of failure to optimize costs. See
Azure Monitor Pricing for more information on planning monitoring costs.

Application monitoring
After deploying an application, it is important to monitor the uptime and performance
(including response time and latency), and understand usage patterns. Application
Insights is an Azure service that offers comprehensive application performance
management (APM) and monitoring capabilities for web-based applications.
Application insights monitoring supports a wide variety of platforms, including .NET,
Node.js, Java, and Python as well as apps hosted on-premises or on any public cloud. This
versatile monitoring tool is suitable for virtually any application.
Using Application Insights:

• Install a small instrumentation package (SDK) in your application.

• Alternatively, enable Application Insights by using the Application Insights agent in
Azure.

54
This image depicts the overview of Application Insights in Azure.

Azure Metrics Explorer

Azure Metrics Explorer makes it easy to capture performance counters for resources
quickly without adding instrumentation to your application code.

Application Insights cost management

Application Insights offers a generous free allowance typically sufficient for developing and
publishing of an app for a small use base. It is advisable to set limits as best practices to
avoid processing unnecessary data and maintain cost efficiency.
Larger volumes of telemetry are charged by the gigabyte and should be monitored closely
to ensure your finance department does not receive a larger-than-expected Azure invoice.

Additional resources
• Manage usage and costs for Application Insights
• Monitoring any Azure Resource
• Django Monitoring in Application Insights
• OpenAI Monitoring
• Monitoring Containers

Database monitoring
Database monitoring is essential for diagnosing issues and optimizing performance. We
have several monitoring options available for an Azure SQL Database.

Dynamic Management Views (DMVs)

Azure SQL provides a wide selection of dynamic management views for identifying
performance issues that could stem from blocked or lengthy queries, resource
55
constraints, suboptimal query plans, and more. Within Azure SQL Database, these
dynamic management views return information about the server’s state.
There are three main categories of views and functions:

• Database-related dynamic management views (prefixed by sys.dm_db_*)

• Execution-related dynamic management views (prefixed by sys.dm_exec_*)
• Transaction-related dynamic management views (prefixed by sys.dm_tran_*)
Here are some fundamental scenarios you might encounter when exploring the status of
your database instance. Initially, you might be interested in determining the current
resource utilization of the specific instance where your application is operational.
Using your client tool of choice, connect to your database and execute this query:
SELECT * FROM sys.dm_db_resource_stats ORDER BY end_time DESC;

DMV query results.

The results above provide essential metrics related to the resource consumption of your
database instance over the past hour, at 15-second intervals. Should any of these metrics
approach 100%, you typically have the option to either scale up your database service or
computing tier, or more commonly, to investigate resource usage further in order to
identify opportunities for optimizing your workload’s efficiency.

Execution plans
Execution plans in Azure SQL Database are graphical representations of how the SQL
Server engine plans to execute a query, offering valuable insights into the query processing
and optimization. Execution plans display the sequence of operations, such as scans,
joins, and sorts, that SQL Server will perform to retrieve the desired data. By analyzing
execution plans, developers and database administrators can identify performance
bottlenecks, such as expensive operations or unnecessary table scans, and optimize their
SQL queries accordingly.
Furthermore, execution plans can reveal the use of indexes, helping to fine-tune index
strategies to improve query performance and overall database efficiency.
A great place to start learning about execution plans is here.

56
Overview of monitoring for Azure SQL Database
Within the Azure portal, developers can navigate to the Overview section of Azure SQL
Database and then select the Monitoring tab to access a high-level dashboard providing
insight into the basic database monitoring metrics, such as CPU, IO, Query Count, etc.

This image shows Azure SQL Database metrics in the Azure portal.

Diagnostic settings
Diagnostic settings allow you to route logs and metrics continuously to other storage and
ingestion endpoints such as Log Analytics.

This image shows how to setup diagnostic logging in the Azure portal.

57
Log analytics
Once diagnostic settings have been configured, you can navigate to the log analytics
workspace. You can perform specific filtered queries on categories of interest. A great
starting point is Get started with log queries in Azure Monitor.

Query Performance Insight

Query Performance Insight provides intelligent query analysis for Azure SQL Database. It
identifies the top resource consuming and long-running queries in your database
workload. This helps you find the queries to optimize to improve overall workload
performance and efficiently use the resource that you are paying for. Query Performance
Insight helps you spend less time troubleshooting by providing:

• Deeper insight into your databases resource (DTU/vCore) consumption.

• Details on top database queries by CPU, duration, and execution count (potential
tuning candidates for performance improvements).
• The ability to drill down into details of a query, to view the query text and history of
resource utilization.
• Annotations that show performance recommendations from Database Advisor.

This image shows Query Performance Insights.

Complete monitoring for Azure SQL Database

Start monitoring the performance of a database in Azure SQL Database by assessing the
CPU and IO consumption compared to the database performance tier and level you have

58
chosen. For more monitoring options, visit Monitor and performance tuning in Azure SQL
Database.

Resources
• Identify query performance bottlenecks in Azure SQL Database
• Actual Estimation Plans
• Metrics for Azure SQL Database
• Monitor Azure SQL Database
• Log queries in Azure Monitor
• Learning Kusto Query Language

Alerting
Guidelines
Once you have configured monitoring data to flow into Azure Monitor or Log Analytics, the
next step is to create alerts when issue data is generated. Understanding the symptoms is
critical. “You can’t fix what you don’t know is broken.”
Alert creation and remediation will take fine-tuning to ensure that alert fatigue does not set
in. Instead of focusing heavily on integrating monitoring with IT Service Management (ITSM)
systems for incident management, prioritize cloud automation to replace expensive
service management processes, reducing time spent on easily resolvable alerts and
incidents.
For more information: Successful alerting strategy.

Azure alerting concepts

Metric alerts
Metric alerts assess metric time-series based on defined conditions and trigger action
accordingly. They consist of the following parts:

• Alert rules define the alert conditions. They require the following information:

o The metric to monitor (e.g. aborted_connections)

o An aggregation for the selected metric (e.g. total)
o A threshold for the aggregated value (e.g. 10 connections)
o A time window for the aggregation (e.g. 30 minutes)
o A polling frequency to determine if the previous conditions are met (e.g. 5
minutes)

59
 • Action groups define notification actions, such as emailing or texting an
administrator, and other actions such as calling a webhook or Azure Automation
Runbooks.

• Alert processing rules are a preview feature that filters alerts as they are generated
to modify the actions taken in response to that alert (i.e. by disabling action groups).

Webhooks
Webhook action groups send POST requests to configured webhook endpoints and can
use either the common alert schema for webhook calls, or custom JSON payloads. This
feature allows Azure Monitor to integrate with incident management systems like
PagerDuty, call Logic Apps, and execute Azure Automation runbooks.

Metrics resources
Azure CLI
Azure CLI includes the az monitor series of commands for manipulating action groups (az
monitor action-group), alert rules and metrics (az monitor metrics), and more.

• Azure CLI reference commands for Azure Monitor

Azure Portal
While the Azure portal does not provide automation capabilities like the CLI or the REST
API, it does support configurable dashboards and provides a strong introduction to
monitoring metrics in Azure SQL Database.

• Set up alerts on metrics for Azure SQL Database

• Tutorial: Analyze metrics for an Azure resource

Azure Monitor REST API

The Azure Monitor REST API enables applications to access metric values for integration
with other monitoring systems like external SIEM systems. It also allows applications to
manipulate alert rules externally.
To interact with the REST API, applications must obtain an authentication token from
Microsoft Entra ID and then use that token in API requests.

• REST API Walkthrough

• Azure Monitor REST API Reference

Azure Service Health

Azure Service Health notifies administrators about Azure service incidents and planned
maintenance, enabling them to take actions to mitigate downtime. It offers customizable

60
cloud alerts, personalized dashboards for analyzing health issues, monitoring resources
impact, accessing guidance and support, and sharing details and updates.

Resources
• Cloud Adoption Framework
• Best practices for Azure Monitor alerts
• Azure Services Health

Best practices
Best practices for Azure SQL Database apps
When developing cloud applications backed by Azure SQL Database, consider
implementing the following best practices. Note, this list is not exhaustive.
Consult the Azure Well-Architected Framework for more information regarding the core
principles of efficient cloud workloads. Assess existing Azure workloads for Well-
Architected Framework compliance with the Azure Well-Architected Review utility.

1. Co-locate resources
Locating Azure services in the same region minimizes network traffic costs and latency.
Azure SQL Database supports co-location in the same region and co-location in the same
availability zone for regions that support availability zones. Azure SQL Database couples
well with zonal services, such as Azure App Services and Azure Kubernetes Services.

2. Implement connection pooling

You can significantly improve application performance through connection pooling.
Connection pooling reduces the number of times that connections are established and
increases the duration of those connections.

3. Monitor and size containers adequately

To ensure optimal functionality of containerized applications, verify that application
containers are allocated sufficient resources. You may need to adjust application
parameters for container environments, such as Java heap size parameters. Additionally,
consider setting resource limits and quotas for your containers to prevent resource
contention issues.
You can identify container resource issues using monitoring utilities, like Container
Insights, which supports Azure Kubernetes Service, Azure Container Instances, on-
premises Kubernetes clusters, and more.

61
4. Implement network isolation and SSL connectivity
Azure SQL Database natively supports connectivity through Azure Virtual Network,
ensuring that the database endpoint does not face the public internet and database traffic
remains within Azure.

• Introduction to Azure Virtual Networks

5. Retry on transient faults

Given that cloud environments are more likely to encounter transient faults, like network
connectivity interruptions or service timeouts, applications must implement logic to deal
with them, typically by retrying requests after a delay.
API responses typically indicate whether a fault is transient or persistent, sometimes even
specifying a retry interval. If the fault is transient, applications must retry requests without
consuming excessive resources. Common retry strategies include sending requests at
regular, exponential, or random intervals. If a given number of retry requests fail,
applications consider the operation failed.
Azure SDKs typically provide native support for retrying service requests. Consult the
documentation’s list of per-service retry recommendations.

6. Size database compute resources adequately

Teams must be diligent with sizing their Azure SQL Database to be cost-effective while
maintaining adequate application performance. There are three different tiers of Azure SQL
Database, each with different intended use cases and memory configurations.
Use Metrics to determine if a database needs to be scaled. To test database performance
under a realistic application load, consider utilities like Azure Load Testing.

7. Utilize reserved capacity

In addition to resizing instances, compute resources can also be prepaid with reserved
capacity. With Azure SQL Database reserved capacity, you can make an upfront
commitment for a one or three-year period for a significant discount on the compute costs.
To purchase reserved capacity, you must specify the Azure region, deployment type,
performance tier, and term. For more information, see Save costs for resources with
reserved capacity - Azure SQL Database & SQL Managed Instance.

62
07 DevOps with Azure SQL Database
In software development, efficiency and reliability in managing and deploying databases
are paramount. DevOps is a set of practices that combines software development (Dev)
and IT operations (Ops), to shorten the system’s development life cycle. It aims to deliver
features, fixes, and updates frequently in close alignment with business objectives. Azure
SQL Database provides seamless integration with DevOps methodologies, particularly
through GitHub Actions, to enable agile and continuous deployment practices.

Introduction to continuous integration and deployment

(CI/CD)
Manual deployment of applications and databases is not efficient, and changes to the
environment require thorough testing. Microsoft recommends automating build and
deployment processes to minimize errors and the time to release new features. This
practice is often referred to as CI/CD - a cornerstone practice within the DevOps
framework. It bridges the gap between development (Dev) and operations (Ops) through
automation and continuous processes. By automating the build, test, and deployment
phases, CI/CD enables rapid, reliable software releases.

DevOps Process Diagram.

Below are the common terms and definitions:

• Continuous Integration (CI): CI tools automatically build, test, and merge code
pushed by developers to version control systems. CI pipelines execute code

63
 analysis tools to enforce style guidelines, unit tests, integration tests, and more. By
constantly merging developers’ contributions to a shared branch, CI tools improve
developer efficiency.

• Continuous Delivery (CD): Continuous delivery tools package applications and

database code in a format that operations teams can deploy to production.

• Continuous Deployment (CD): Continuous deployment automates the production

deployment process; it does not require an operations team to intervene.
Continuous deployment processes extend the capabilities of continuous delivery.

Implementing build and deployment automation means that development teams can
rapidly serve small features and fixes in production, rather than waiting for one large, error-
prone manual deployment.

CI/CD tools
Azure App Service Deployment slots
App Service instances in the Standard tier or higher support deployment slots, which are
separate instances of an app accessible via different hostnames. Developers can validate
app updates in a staging slot before swapping the updates into the production slot. After
the swap, the staging slot holds the previous production app, facilitating a quick roll back
of unsuccessful changes. Swapping a slot has no downtime.

Azure App Service Deployment Center

The Deployment Center provides a summary of the deployment methods for an App
Service instance. It also allows developers to quickly create CI/CD pipelines for code
stored in version control systems. App Service executes pipelines on multiple targets,
including GitHub Actions, Azure Pipelines, and built-in Kudu.

GitHub Actions
GitHub Actions is a CI/CD platform that allows automation of software workflows,
enabling you to build, test, and deploy your code right from GitHub. It operates through
workflows that are defined in YAML files and is triggered by GitHub events like pushes, pull
requests, or scheduled times. With GitHub Actions, you can integrate various actions
(created by the community or custom ones you define) into workflows, thus automating
tasks across your development process.
For more details, you can explore GitHub’s documentation on Actions.
A GitHub repository can have multiple workflows (pipelines) written in YAML. At their most
basic level, workflows consist of actions that perform some basic task, such as initializing
a build tool. Teams can run GitHub Actions on GitHub runners or self-hosted runners for
greater flexibility.

64
To see how GitHub actions can be used to execute tasks against Azure SQL Database,
watch Data Exposed Video on GitHub Actions for Deploying Azure SQL Database.

Azure DevOps
Azure DevOps includes multiple tools to improve team collaboration and automate
building, testing, and deploying apps.

• Azure Boards: Azure Boards help teams plan and track work items. It supports
multiple processes.
• Azure Pipelines: Azure Pipelines is Microsoft’s CI/CD pipeline platform. It supports
deployment to PaaS services, virtual machines, and container registries in Azure,
other cloud platforms, and on-premises. Azure Pipelines integrates with common
version control systems, like GitHub, GitLab, and Azure Repos.
• Azure Test Plans: Azure Test Plans allows development teams to create manual
tests, for feedback from developers and stakeholders, and automated tests, which
are necessary for any CI/CD pipeline.
• Azure Repos: Azure Repos provides Microsoft-hosted public and private Git
repositories.
• Azure Artifacts: Azure Artifacts allows organizations to share packages, such as
NuGet and npm packages, internally and publicly. Azure Artifacts integrates with
Azure Pipelines.
Organizations can quickly start exploring Azure DevOps by creating a free organization.
Azure DevOps’ suite of project management, CI/CD, and testing tools empowers
organizations to deploy more frequently, more quickly, and with fewer failures.
For an example of using Azure Pipelines deployment with Azure SQL Database, reference
Azure SQL Database deployment.

Infrastructure as Code (IaC)

Infrastructure as Code (IaC) is a modern approach to managing and provisioning
infrastructure through machine-readable definition files, rather than physical hardware
configuration or interactive configuration tools. This method leverages declarative
programming to specify what the automated system should accomplish, without
prescribing how to achieve it, offering a clear contrast to imperative methods like Azure
PowerShell. Declarative techniques, such as those seen with Azure Resource Manager
(ARM) templates and Bicep files, provide greater flexibility and ease of use, making them
the preferred choice in many scenarios.
IaC is a cornerstone in integrating with continuous integration and continuous deployment
(CI/CD) pipelines, ensuring consistency across various application environments. By
storing IaC artifacts in version control systems, teams maintain a thorough record of
changes and can review the evolution of their infrastructure over time. Whenever
developers need to adjust their environment, they modify the IaC definitions, and the

65
automated pipelines adjust the cloud environment to match these new specifications. This
process is inherently idempotent, meaning it can be applied repeatedly without changing
the result beyond the initial application, ensuring that the cloud environment’s state
always aligns with the defined requirements.
This approach not only enhances the reliability and scalability of infrastructure
management but also significantly reduces the potential for human error and
inconsistencies during deployment. By embracing IaC, organizations can automate and
streamline their operations, leading to faster deployments and more robust systems.
GitHub Actions supports automated (ARM) as well as Bicep template deployments.

Deploying to Azure SQL Database using Azure Pipelines

Azure Pipelines deploys automatic updates to Azure SQL Database, ensuring your
database is always up-to-date following successful builds. This guide provides an overview
of deploying databases using DACPACs, SQL scripts, managing Azure service connections,
conditional deployments, and additional SQL actions.

DACPAC deployment:
DACPACs (Data-tier Applications) provide a straightforward method for schema and data
deployment. A data-tier application (DAC) represents a logical database entity that
encompasses all the SQL Server objects including tables, views, and instance objects,
such as logins associated with a user’s database. A DAC is a self-contained unit of the
entire database model and is portable in an artifact known as a DAC package, or .dacpac.
A DAC supports the following operations:

• EXTRACT – The user can extract a database into a .dacpac. For more information,
see SqlPackage extract and Extract a DAC From a Database.
• DEPLOY/PUBLISH – The user can deploy a .dacpac to a host server. When the
deployment is done to an existing database, the difference between the database
and the DAC is applied to the database as an object update operation. The term
“publish” is often used interchangeably with “deploy.” For more information, see
SqlPackage publish, Deploy a Data-tier Application, and Deploy a Database By
Using a DAC.
To learn more about the deployment of DACPACS in Azure Pipelines, reference Azure SQL
Database deployment.

SQL script deployment

Alternatively, deploy using SQL scripts for database updates. This requires Azure
PowerShell scripts to manage Azure firewall rules, allowing Azure Pipelines agents to
communicate with Azure SQL Database.

66
Additional resources
The recommended learning path is Automate database tasks for Azure SQL.

67
08 Integrating with Azure Services
Developing applications in Azure facilitates seamless integration between Azure services,
enhancing the user experience. Throughout this guide we have focused on several services
associated with the Electric Scooter Use Case.
For example, the Electric Scooter telemetry services can leverage Azure Event Hubs to
stream millions of events per second from all of the operational scooters, ensuring low
latency delivery of real-time tracking information to our Azure SQL Database. This data can
be displayed in real-time tracking on both the mobile app and web app hosted on Azure
App Service.
Additionally, GraphQL enables faster application development compared to traditional
REST APIs, allowing retrieval of all required data in a single request for a smoother user
experience. By utilizing data API builder tables, views and stored procedures in your Azure
SQL Database can be transformed into REST or GraphQL API endpoints enabling data to be
accessed using modern techniques across any platform, any language, and any device.

68
09 Helpful resources

Azure SQL Database documentation

aka.ms/SQLDB_documentation

View technical content in these video series

aka.ms/dataexposed
aka.ms/sql_db_essentials

Read an overview of how to build AI applications with Azure SQL Database

aka.ms/sqlai

Access code samples to help design AI applications with Azure SQL Database
aka.ms/sqlaisamples

Learn to access data using modern REST and GraphQL endpoints with data API builder
aka.ms/dab

69
 70

© 2024 Microsoft Corporation. All rights reserved.