Azure SQL Database ou SQL Server em uma VM? O que aprendi

Quando fiz o deploy da Sports Betting API no Azure, eu precisava de um database atrás dela, e havia duas opções óbvias: Azure SQL Database, o managed service, ou uma virtual machine com SQL Server instalado. Os dois rodam SQL Server. A diferença está em tudo o que cerca o database, não no database em si.

O que a opção da VM significa na prática

Uma VM com SQL Server é uma máquina minha. Eu escolho o tamanho, instalo o SQL Server, configuro, e ele se comporta exatamente como um SQL Server em qualquer outra máquina, porque é isso que ele é.

Isso também significa que tudo naquela máquina é responsabilidade minha. Updates do operating system, patches do SQL Server, backups, configurar high availability, garantir que o disco não encha. Se sai um security patch, aplicar é tarefa minha e o downtime é meu.

A vantagem é controle total. Acesso completo à instance, qualquer feature do SQL Server, qualquer configuração, jobs do SQL Server Agent, o file system, cross-database queries. Se eu precisar de algo específico no nível da instance, está lá.

Do que o Azure SQL Database abre mão e o que devolve

O Azure SQL Database é o database as a service. Eu não recebo uma máquina, recebo um database, e o Azure cuida do operating system, dos patches e dos automated backups.

O preço disso é que algumas coisas deixam de ser minhas. Não existe SQL Server Agent na mesma forma, não há acesso ao file system, não há configuração no nível da instance, e coisas como cross-database queries funcionam de outro jeito ou simplesmente não funcionam. É SQL Server, mas uma versão com escopo reduzido.

Por que escolhi o managed

Para a minha API a decisão foi direta, e não foi bem por causa de features. Foi por causa daquilo em que eu de fato quero gastar meu tempo.

Estou construindo uma API. Não sou DBA e não quero me tornar o responsável por aplicar patches num database server de um projeto de estudo. Cada hora cuidando de uma VM é uma hora que não passei na coisa que eu realmente quero aprender. Azure SQL Database significa que o database é uma connection string e nada mais.

Os backups também pesaram. Automated backups que eu não preciso configurar valem muito comparados à alternativa, que é eu montar um backup schedule e descobrir depois se ele funcionava mesmo.

Como a aplicação inteira roda no Azure Container Apps e é configurada só por environment variables, o database ser um managed endpoint encaixa exatamente nesse formato. Nada na aplicação sabe ou se importa com o que está do outro lado da connection string.

Quando eu escolheria a VM

Existem motivos de verdade, só não se aplicavam a mim.

Se uma aplicação precisa de uma feature do SQL Server que o managed service não suporta, isso encerra a discussão. Aplicações legacy às vezes dependem de comportamento no nível da instance, linked servers, jobs específicos do agent, ou cross-database queries que assumem que tudo vive na mesma instance.

Migrar um database on-premises existente também pode ser mais simples para uma VM, porque é o mesmo ambiente em que ele já rodava. Levantar do jeito que está e não mudar nada é menos arriscado do que adaptá-lo às restrições de um managed service.

E se um time já tem DBAs que sabem como querem o SQL Server configurado, abrir mão desse controle não é economia, é perda.

A regra geral que tirei disso

Managed é o default, a não ser que exista um motivo específico para não dar. A pergunta não é qual dos dois é mais capaz, porque a VM é obviamente mais capaz. É se eu preciso dessa capacidade extra o suficiente para assumir a operação de um servidor por ela.

Para a maioria das aplicações novas, e com certeza para qualquer coisa que eu esteja construindo agora, a resposta é não. Prefiro ter menos coisas que são minhas para manter de pé.