Most developers think of a database as the place where an application stores information. Tables, transactions, indexes, stored procedures, reporting, backups, and reliable data storage are the traditional responsibilities we associate with SQL. But what happens when the database itself becomes an active participant in the application architecture? In this episode of M365 FM, Mirko Peters talks with Dirceu Resende about how Azure SQL Database is evolving beyond traditional data storage. The conversation explores REST API integration, automation, external services, security, performance, Microsoft Fabric, Power BI, AI, vector search, RAG, observability, and the changing architectural role of databases inside modern applications. Dirceu brings a combination of database, business intelligence, Microsoft, and community experience to the discussion. His career spans database development and performance tuning, business intelligence, Power BI, and cloud technologies, including previous work at Microsoft as a Senior Program Manager for Power BI.
AZURE SQL DATABASE IS BECOMING MORE THAN A DATABASE
Azure SQL Database provides the familiar relational capabilities of SQL Server while removing much of the infrastructure management traditionally associated with running a production database. Organizations can use a managed cloud database without having to directly maintain the underlying operating system and infrastructure. Azure also provides capabilities around security, availability, backups, performance, and integration with other cloud services. But Dirceu argues that one of the most interesting developments is what Azure SQL can now do outside the traditional boundaries of the database. Azure SQL Database can make HTTP requests and communicate with external services. This creates scenarios where the database can participate directly in workflows that previously required another application or integration layer. The database is no longer necessarily waiting passively for an application to tell it what to do.
AZURE SQL DATABASE VS MANAGED INSTANCE VS SQL SERVER
Choosing the correct SQL deployment model still depends heavily on application architecture. Dirceu explains that Azure SQL Managed Instance provides an experience closer to traditional SQL Server. It supports scenarios involving multiple databases within an instance and capabilities that organizations migrating existing SQL Server workloads may require. Azure SQL Database is more naturally aligned with independent databases and architectures where applications or microservices have separate database resources. If an application depends heavily on cross-database queries, linked services, SQL CLR, or other traditional SQL Server capabilities, migration may require architectural changes rather than simply moving the existing database into Azure SQL Database unchanged. This makes workload assessment an important part of any SQL modernization strategy.
WHY AZURE SQL FITS MODERN APPLICATION ARCHITECTURES
Moving data into Azure can make integration with other Azure and Microsoft services significantly easier. Applications running through services such as Azure App Service, containers, or Kubernetes can operate closer to the database. Microsoft Fabric and Power BI can also consume Azure SQL information through increasingly integrated architectures. Azure SQL Database additionally receives cloud capabilities that may arrive later in traditional SQL Server releases. Dirceu highlights sp_invoke_external_rest_endpoint as an important example because it allows Azure SQL Database to communicate directly with REST endpoints. That seemingly simple capability fundamentally changes what developers can consider doing inside or close to the database.
WHEN THE DATABASE BECOMES AN ACTIVE APPLICATION COMPONENT
Traditional application architecture often places the database behind an application layer. The application receives requests, executes business logic, communicates with other systems, and finally reads or writes information to the database. That separation remains useful and appropriate in many architectures. But Azure SQL can now perform more activities independently. Dirceu describes scenarios where the database can retrieve information from an external API, combine it with application data, work with information stored in Azure Blob Storage, and initiate other processes without requiring a separate application to orchestrate every individual step. This does not mean developers should move every application function into SQL. It means architects now have another option.
CALLING REST APIS DIRECTLY FROM AZURE SQL
REST API integration is one of the central topics of this episode. If an external service provides an appropriate API, Azure SQL can potentially communicate with it. This opens the door to integrations with communication platforms, SaaS applications, Microsoft 365 services, AI platforms, monitoring systems, and custom applications. The database can therefore respond to business information rather than simply storing it. Imagine an order reaching the database. Instead of waiting for another application to periodically discover the new order, a database-driven process could potentially initiate an appropriate external action. This creates interesting opportunities for event-driven and data-driven architectures.
USING AI TO ANALYZE CUSTOMER FEEDBACK
One example discussed in the conversation involves customer feedback. Imagine an application that stores thousands of customer comments inside Azure SQL Database. Manually reading every comment and classifying whether the customer is satisfied, unhappy, extremely dissatisfied, or enthusiastic quickly becomes impractical. Azure SQL can potentially send that information to an AI or cognitive service through an API. The external service analyzes the text and returns a classification or score. That information can then be stored alongside the original customer feedback. The business could identify extremely dissatisfied customers requiring immediate attention or particularly satisfied customers relevant to another business process. The database becomes part of the AI workflow rather than simply the final storage destination.
AI-POWERED DATA CLEANING
Another practical scenario involves data quality. Anyone who has worked with CSV files, spreadsheets, FTP integrations, or external data feeds knows how inconsistent incoming information can become. Locations can be misspelled. Values may use different formats. Names can contain unexpected variations. Hundreds of columns can require complex transformation rules. Historically, developers and data engineers might create substantial amounts of custom code to normalize this information. Dirceu discusses how AI services can potentially help classify, standardize, and clean incoming data. Instead of attempting to anticipate every possible incorrect value through manually created rules, the database can send problematic information to an AI service and use the result as part of the data preparation workflow.
EMAIL, SMS, TEAMS, SLACK AND EXTERNAL SERVICES
REST APIs also make communication scenarios possible. Dirceu discusses integrations where Azure SQL could work with services capable of sending emails, SMS messages, WhatsApp messages, Telegram notifications, or Slack messages. A database could therefore participate in operational alerting. Imagine inventory falling below a defined threshold. A scheduled database process detects the condition and initiates a notification to the employee responsible for purchasing. The same principle could apply to failed processes, unusual business conditions, customer activity, or operational alerts. The important architectural change is that the trigger can originate directly from information already inside the database.
MICROSOFT 365 AND THIRD-PARTY API INTEGRATION
The same concept extends beyond simple notifications. Dirceu discusses the potential to integrate with Microsoft 365 services and third-party platforms when appropriate APIs are available. A business event occurring inside the database could potentially create another action in a connected business application. For example, information could result in creating a task, updating another system, creating a lead, or initiating another business process. The exact possibilities depend on the capabilities and authentication mechanisms exposed by the target service. This turns REST API support into a general integration capability rather than a feature designed for one specific scenario.
SYNCHRONOUS VS ASYNCHRONOUS DATABASE INTEGRATION
Not every business process should happen immediately. The episode distinguishes between synchronous and asynchronous integration patterns. A synchronous process could respond when information reaches the database. An order is inserted, a database process detects the event, and another action happens immediately. An asynchronous approach works differently. A scheduled process might periodically collect everything that happened during a defined period and then perform a batch action. For example, rather than sending ten individual notifications for ten orders, the system could generate one summary containing all ten orders. The right architecture depends on whether the business process requires immediate action or whether delayed and grouped processing is more appropriate.
Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.
