Configurando o SQL 2025 com Ollama no mesmo PC/localhost

Tempo de Leitura: 7 minutos

Uma das principais novidades do SQL Server 2025 é você poder conectar com as APIs de serviços de IA para conseguir usar diretamente no código T-SQL. E um desses serviços mais famosos que temos atualmente é o ollama, que é open source e você pode instalar na sua própria máquina. Nesse post eu quero te guiar como você pode colocar para funcionar o ollama na mesma máquina que o SQL, que é um cenário comum quando você quiser testar alguma coisa.

Sobre o Ollama

O ollama é o que chamamos de inference engine. Basicamente, é um projeto open source que consegue carregar os mais variados modelos de IA, que geram texto e embeddings, permitindo que você tenha a disposição um modelo que consegue processar os seus dados sem precisar usar APIs externas. Isso pode ser muito útil para cenários onde a privacidade é extremamente importante.

Você pode instalar o ollama facilmente no Windows ou Linux, basta seguir as instruções dessa página: Ollama

Para este post, estou assumindo que você instalou o ollama na sua própria máquina, seja no Windows diretamente, ou via wsl2, que é o Linux dentro do Windows. E, junto com o ollama, você tem um SQL Server (express ou developer, por exemplo) e quer que esse SQL se conecte no serviço que você instalou.

Assumimos que o ollama está rodando na porta 11434, que é a porta padrão, isto é, você pode acessar pela web nesse endereço: http://localhost:11434

Primeira tentativa

O jeito mais fácil de testar o acesso ao ollama com o SQL Server 2025 é usando a nova sp_invoke_external_rest_endpoint. Você precisa habilitar ela usando o seguinte comando:

EXEC sp_configure 'external rest endpoint enabled',1
RECONFIGURE

EXEC sp_configure 'external rest endpoint enabled',1
RECONFIGURE

Uma vez habilitado, você poderia tentar acessar o ollama assim:

exec sp_invoke_external_rest_endpoint 
	@url = 'http://localhost:11434/v1/models'
	,@method = 'GET'

exec sp_invoke_external_rest_endpoint 
	@url = 'http://localhost:11434/v1/models'
	,@method = 'GET'

Mas, ao tentar acessar o ollama na porta http original, você vai tomar esse erro:

Msg 31610, Level 16, State 1, Procedure sys.sp_invoke_external_rest_endpoint_internal, Line 1 [Batch Start Line 0]
Accessing the external endpoint is only allowed via HTTPS.

Isso é devido ao fato de que o SQL Server 2025 somente aceita conexões HTTPS, seja usando a sp_invoke_external_rest_endpoint seja usando as outras funções de IA.

Então, agora precisamos de um jeito de fazer o ollama ser executado em uma porta HTTPS, ai na sua máquina.

Caddy

Existem inúmeras formas da gente conseguir fazer o ollama ser executado via https, sendo algumas delas:

Poderia subir com um nginx, criar os certificados e instalar na sua máquina. Mas acho muito trabalhoso paraq uem não está acostumado
Poderia subir uma máquina em cloud,com ip publico, e usar o nginx ou traefik com lets encrypt para gerar o certificado. De novo, acho trabalhoso e pode ter custos indesejados para você

A maneira mais simples e trivial que encontrei de fazer isso no Windows é usando uma ferramenta chamada Caddy, que é basicamente um proxy que com alguns comandos simples você consegue fazer ele subir um serviço https localhost com um certificado na sua máquina.

Primeiro, instale o caddy conforme doc: Install — Caddy Documentation . É muito simples.

Após instalar o caddy, você pode abrir um powershell ou prompt de comando, e digitar “caddy”, e você vai ver que você tem este comando a sua disposição agora.

Para que possamos jogar nosso ollama atrás de um https, basta rodar esse comando no caddy:

caddy reverse-proxy --from localhost:11443 --to :11434

caddy reverse-proxy --from localhost:11443 --to :11434

reverse-proxy: Informar ao caddy que vamos iniciar um proxy reverso, isto é, um serviço que vai rotear as conexoes que chegam em uma porta para outra
–from localhost:11443
Aqui estamos dizendo ao caddy que ele deve escutar na porta 11443. Logo, se você acessar https://localhost:11443, o caddy vai rotear isso para o serviço de destino. Você pode escolher a porta que quiser, desde que esteja liberada. Eu escolhi 11443 porque é parecida com a porta do ollama. Note que eu preciso especificar o nome “localhost”, para que ele gere o certificado https corretamente.
–to :11434
Aqui é a porta onde o serviço que nós queremos está. O caddy vai rotear as conexões que chegam na porta 11443 para a 11434, que é onde o ollama está respondendo

Quando você roda esse comando pela primeira vez, o caddy vai gerar os certificados necessários para fazer o https funcionar. Um janela de permissão provavelmente vai se abrir pedindo para você confirmar a instalação do certificado:

Clique em Sim/Yes para confirmar.

Agora, você pode acessar no seu navegador: https://localhost:11443/v1/models. Confirme que o browser reconheceu um o site como https:

Voltando ao SQL, você pode tentar:

exec sp_invoke_external_rest_endpoint 
	@url = 'https://localhost:11443/v1/models'
	,@method = 'GET

exec sp_invoke_external_rest_endpoint 
	@url = 'https://localhost:11443/v1/models'
	,@method = 'GET

E surpreendentemente, você pode se deparar com outro erro:

Msg 31608, Level 16, State 29, Procedure sys.sp_invoke_external_rest_endpoint_internal, Line 1 [Batch Start Line 10]
An error occurred, failed to communicate with the external rest endpoint. HRESULT: 0x80070008.

An error occurred, failed to communicate with the external rest endpoint. HRESULT: 0x80070002.

O código do erro acima é bem genérico do Windows, mas, basicamente, o que está acontecendo é que o serviço do SQL está tentando acessar na porta https mas não consegue validar o certificado. Se você habilitar a xp_cmdshell e usar um powershell para acessar, consegue ver uma mensagem de erro melhor:

exec sp_configure 'show',1;reconfigure;
exec sp_configure 'xp_cmdshell',1; reconfigure;
exec xp_cmdshell 'powershell -Command ^& { Invoke-WebRequest -UseBasic https://localhost:11443/v1/models }'

exec sp_configure 'show',1;reconfigure;
exec sp_configure 'xp_cmdshell',1; reconfigure;
exec xp_cmdshell 'powershell -Command ^& { Invoke-WebRequest -UseBasic https://localhost:11443/v1/models }'

Note que mesmo via powershell, ele está tendo erro de certificado ainda. E a razão para isso é muito simples: O caddy instala o certificado na Certificate User Store, que somente o seu usuário logado atual tem acesso. O serviço do SQL roda em uma outra sessão do Windows, logo, ele não enxerga esse certificado. Você precisa instalar o mesmo certificado em um local que o serviço do SQL acesse.

IMPORTANTE: Não é necessário habilitar xp_cmdshell para usar os recursos de IA ou HTTP do SQL 2025. Aqui foi apenas um exemplo de como você pode usar ela para testar o cesso e debugar problemas relacionados a sessão do SQL.

O caddy coloca, por padrão, os certificados nesse diretório: %APPDATA%\Caddy\pki\authorities\local

Dê 2 cliques nesse root.crt, e a tela de instalação do certificado vai se abrir:

Clique em Install, depois em “Local Machine” (Vamos instalar o certificado visivel para todo o PC, o que engloba todas as sessões. Você precisa ser admin para fazer isso):

Na próxima tela escolha a segunda opção, que te permite especificar o local e escolha a Trust RootCertification Authorities:

Depois, clique em Next, e em Finish. Pronto, agora se você executar novamente, o SQL consegue acessar pra você:

-- Le a lista de modelos na api do ollama
declare @resp nvarchar(max)

exec sp_invoke_external_rest_endpoint 
	@url = 'https://localhost:11443/v1/models'
	,@method = 'GET'
	,@response = @resp output

select * from openjson(@resp,'$.result.data') with (id varchar(100))

-- Le a lista de modelos na api do ollama
declare @resp nvarchar(max)

exec sp_invoke_external_rest_endpoint 
	@url = 'https://localhost:11443/v1/models'
	,@method = 'GET'
	,@response = @resp output

select * from openjson(@resp,'$.result.data') with (id varchar(100))

Uma vez que a procedure sp_invoke_external_rest_endpoint funciona normalmente, agora você pode usar os demais comandos, como o CREATE EXTERNAL MODEL, junto com AI_GENERATE_EMBEDDINGS, por exemplo:

create external model Ollama
with (
		LOCATION = 'https://localhost:11443/api/embed'
		,API_FORMAT = 'ollama'
		,MODEL_TYPE = EMBEDDINGS
		,MODEL = 'nomic-embed-text'
)

select AI_GENERATE_EMBEDDINGS('gerar embeddings' use model Ollama)

create external model Ollama
with (
		LOCATION = 'https://localhost:11443/api/embed'
		,API_FORMAT = 'ollama'
		,MODEL_TYPE = EMBEDDINGS
		,MODEL = 'nomic-embed-text'
)

select AI_GENERATE_EMBEDDINGS('gerar embeddings' use model Ollama)

Importante: Note que no exemplo acima estou usando o modelo nomic-embed-text, você deve baixar no seu ollama usando ollama pull nomic-embed-text (ou outro caso queria testar com outros).

Sem o https configurado corretamente, você receberia um erro semelhante aos anteriores:

Msg 31608, Level 16, State 29, Line 19
An error occurred, failed to communicate with the external rest endpoint. HRESULT: 0x80070008.

E então agora você pode finalmente testar a integração com embeddings direto da sua máquina. Obvio que em um cenário de produção, o ideal é separar, colocando o ollama em outro local, para que não afete o processamento do banco. Mas, de todo modo, esse post já te dá um norte de como as coisas funcionam e possíveis problemas e mensagens de erros que você pode obter, mesmo quando o ollama (ou outro serviço) estiver em um local diferente.

E lembrando que usando o caddy é uma das maneiras possíveis. Se você tiver outras ai, que sejam mais fáceis do que essa, é só deixar nos comentários!

Obrigado pela leitura, e fique ligado no blog, que trarei mais e mais assuntos de sql 2025 e IA.