Guide
Azure SQL Database has no Database Mail and no SQL Agent. Real options to email query results as CSV on a schedule, from Logic Apps to an agent.
A team moves a database from an on-premises SQL Server to Azure SQL Database, the migration goes well, and a week later someone asks why the daily orders email stopped arriving. It stopped because the job that sent it was a SQL Server Agent job calling sp_send_dbmail, and the single database flavour of Azure SQL has neither of them.
This catches people because Azure SQL Managed Instance does have both Database Mail and SQL Server Agent. If the database runs on Managed Instance, the classic sp_send_dbmail approach works with the profile configured for an Azure-compatible SMTP relay. Everything below is about Azure SQL Database, where it does not.
Elastic Jobs schedule T-SQL against one or more databases, and they are the closest thing to Agent jobs. They run a query on a schedule, but they cannot send an email and cannot write a file anywhere a person would open it. They are useful for maintenance and for filling a table that something else then reads.
Azure Logic Apps are the answer most Microsoft Q&A threads arrive at. A recurrence trigger, the SQL Server connector running a query or a stored procedure, a "Create CSV table" action and an Office 365 or SMTP action to send the email. It is low code and it works. The friction appears around authentication to the database from the Logic App, around large results, since connector actions have row and payload limits, and around the fact that each report is now a workflow in the Azure portal rather than a query someone on the data team can read.
Azure Automation or Azure Functions with PowerShell or C#: Invoke-Sqlcmd or a small SqlClient program, Export-Csv, and a call to an email API such as Azure Communication Services or SendGrid. Full control, correct CSV output, and a piece of code with a deployment pipeline, a managed identity and secrets for every report.
Azure Data Factory can copy query results to a CSV in blob storage on a schedule, and then something else still has to deliver the file to a person.
All of those options can produce the email. The difference is who maintains each report after it exists. If the reports are owned by engineers who are comfortable with the Azure portal, Logic Apps are a reasonable home. If they are owned by an operations or data team that thinks in SQL, every report becoming a workflow or a function means every change goes through someone else.
Taavik connects to Azure SQL Database with the same SQL Server provider it uses for on-premises instances. A small agent runs on a machine or container that can reach the database server, it only makes outbound connections to the workspace, and the database password is encrypted in the browser for that agent before it is stored.
From there the query goes into a shared library where the team can read and version it, and a schedule turns it into a CSV or Excel file on a daily, weekly, monthly or interval cadence, or a cron expression on the Pro plan, each with its own time zone. The result goes to an email list or a Slack channel, with rules for sending only when rows came back, and every run is recorded with its status and row count.
The email carries a download link rather than an attachment. The agent encrypts the file before uploading it, and the recipient opens it with a passphrase that the schedule owner shares once. That is a different habit from finding a spreadsheet attached, and it is the reason the file does not linger in mailboxes after it was forwarded.
It does not format reports, add charts or build a different file per recipient. If the email needs a branded layout, Power BI paginated reports are the Microsoft path. If it needs to be a plain table that arrives on time and can be changed by whoever owns the query, a scheduled export is the smaller tool.
The free plan covers one connection and one daily schedule, enough to move the report that stopped arriving and see whether the approach fits before migrating the rest.