SQL Server 2025: o que muda para quem opera o 2022

O SQL Server 2025 não deve ser tratado como uma atualização de rotina do 2022. Há ganhos relevantes de capacidade, segurança e processamento de consultas, mas também mudanças de edição, componentes descontinuados e comportamentos que precisam entrar no teste de compatibilidade.

O que muda na decisão de upgrade

A primeira mudança prática está na edição Standard. O SQL Server 2025 amplia os limites de compute e buffer pool e passa a oferecer Resource Governor nessa edição. Isso pode alterar a conta de consolidação para ambientes que hoje esbarram no teto da Standard, mas não elimina a necessidade de medir CPU, memória e I/O antes de rever licenciamento ou arquitetura.

Na Express, o limite de banco cresce e os recursos da antiga Express with Advanced Services são consolidados. A edição Web deixa de existir. Essas mudanças não são apenas comerciais: inventários que classificam instâncias por edição precisam ser atualizados antes de qualquer rollout.

Também há componentes descontinuados, como Master Data Services e Data Quality Services, além de mudanças incompatíveis documentadas para linked servers, replicação, log shipping e PolyBase. Uma instância que sobe limpa em laboratório ainda pode quebrar uma integração antiga em produção.

Área	SQL Server 2025	O que verificar
Standard	Até 32 cores e 256 GB de buffer pool, dentro dos limites de sockets documentados	Host, licenciamento, NUMA e memória disponível para o sistema operacional
Resource Governor	Disponível na Standard	Classifier function, pools existentes e risco de limitar uma carga crítica
Express	Banco relacional de até 50 GB	Crescimento, recursos usados e automações que identificam a edição antiga
Web	Edição descontinuada	Inventário de instâncias, contrato e edição de destino
Componentes	MDS, DQS e Synapse Link descontinuados	Dependências, jobs, integrações e alternativa suportada

O limite maior da Standard não significa que toda instância passa a usar mais recursos depois do upgrade. A capacidade efetiva continua limitada pelo host, pela configuração e pelo licenciamento. A tabela serve para abrir a avaliação, não para calcular a arquitetura sem inventário.

Recursos que merecem um piloto

No mecanismo, quatro grupos justificam teste orientado por carga:

Optimized Locking para reduzir memória de locks, escalonamento e bloqueio.
OPPO para consultas com parâmetros opcionais, complementando o PSP do SQL Server 2022.
Feedback de estimativa de cardinalidade para expressões e DOP feedback habilitado por padrão.
ZSTD para compressão de backup, além de backup completo e diferencial em réplicas secundárias.

Recursos de vetor, JSON nativo, expressões regulares e integração com modelos externos chamam atenção, mas só devem entrar na avaliação quando existe um caso de uso. Adotar uma versão nova para “ter IA” sem uma carga definida mistura decisão de plataforma com experimento de aplicação.

Segurança muda mesmo sem alterar a aplicação

O SQL Server 2025 passa a usar PBKDF2 para novos hashes de senha de logins SQL, amplia suporte a TLS 1.3 com TDS 8.0 e adiciona cenários de managed identity para instâncias habilitadas pelo Azure Arc. Também há melhorias para backup e restore em URL usando identidade gerenciada.

Esses recursos reduzem dependência de credenciais e fortalecem comunicação, mas podem expor clientes antigos. O inventário precisa incluir versão de ODBC, JDBC, .NET, sqlcmd, bcp, linked servers e bibliotecas incorporadas em aplicações. Testar apenas com a versão mais recente do SSMS deixa de fora justamente as conexões que costumam falhar na virada.

Use um ambiente de homologação com a mesma política de criptografia planejada para produção. Valide certificado, hostname, modo de criptografia da connection string, rotação de credencial e conexão depois de restart ou failover. Se o plano inclui managed identity, separe a identidade do serviço da identidade usada para deployment e conceda somente as permissões necessárias.

Como avaliar sem transformar o upgrade em aposta

Comece pelo inventário, não pelo instalador. Registre edição, build, nível de compatibilidade, recursos instalados, trace flags, linked servers, topologia de alta disponibilidade, drivers e aplicações dependentes. Em seguida, marque tudo que aparece nas listas oficiais de breaking changes, recursos removidos e recursos preteridos.

Restaure uma cópia representativa em laboratório e mantenha inicialmente o nível de compatibilidade atual. Isso separa a troca do mecanismo da ativação de mudanças do otimizador. Capture um baseline no Query Store antes do teste e compare duração, CPU, leituras, plano e erros depois da restauração.

O roteiro mínimo deve incluir:

Restore e DBCC CHECKDB da cópia.
Teste de conexão com os mesmos drivers usados em produção.
Execução das rotinas críticas e dos jobs do SQL Server Agent.
Simulação de backup, restore e failover.
Comparação do Query Store antes e depois.
Plano de retorno com janela, responsáveis e critérios objetivos.

Separe instalação, compatibilidade e ativação de recursos

Três mudanças diferentes costumam ser tratadas como uma só. A primeira é instalar o novo mecanismo. A segunda é mover ou atualizar o banco mantendo o nível de compatibilidade anterior. A terceira é elevar a compatibilidade e habilitar os recursos do otimizador.

Separar essas fases reduz a quantidade de variáveis por janela. Depois de restaurar ou atualizar o banco, deixe o Query Store capturar a carga no nível anterior. Só então eleve a compatibilidade em canário, compare planos e observe OPPO, feedback de cardinalidade, DOP feedback e demais comportamentos que dependem da configuração.

Não use plano forçado antigo como proteção permanente sem revisão. Ele pode ser útil para conter uma regressão, mas também impedir que uma melhoria do mecanismo seja avaliada. Registre toda hint, trace flag e configuração temporária com responsável e data para remoção.

A janela precisa terminar com um ambiente operável

Além do teste funcional, valide backup, restore, jobs, monitoramento, coleta de Extended Events, alertas, failover e acesso do time de suporte. Atualize scripts que verificam build e edição. Um monitor que não reconhece a versão nova pode deixar a instância sem cobertura justamente depois da mudança.

Defina critérios de abortar antes do início: erro de conexão em aplicação crítica, regressão acima do limite acordado, falha de backup ou ausência de caminho de retorno. O rollback deve ter sido ensaiado e caber na mesma janela; não pode depender de uma decisão improvisada depois que a produção já está indisponível.

O que validar antes de aprovar

O upgrade está pronto quando a equipe consegue responder quais recursos serão ativados, quais permanecerão desligados e qual evidência sustenta cada decisão. A ausência de erro no instalador não comprova compatibilidade da aplicação nem estabilidade do plano de execução.

Use a documentação de novidades do SQL Server 2025 como inventário inicial, mas valide com a carga real. Para preparar a manutenção da instância, complemente com o guia sobre Cumulative Update do SQL Server.

Se o ambiente ainda não possui baseline, inventário e teste de recuperação, um diagnóstico gratuito de SQL Server ajuda a organizar os riscos antes de definir a janela.