PostgreSQL no VS Code: como usar a extensão com Copilot

Perfis de conexão e Microsoft Entra ID

Para conectar o PostgreSQL no VS Code, o diálogo de conexão oferece três modos de entrada. Nele, o modo Parameters pede host, porta, banco e usuário separadamente, enquanto o modo Connection String aceita a string completa.

O terceiro modo, Browse Azure, lista suas assinaturas, grupos de recursos e servidores. Assim, você escolhe o banco sem copiar endereço nenhum do portal.

Quanto à autenticação, a extensão aceita senha, Microsoft Entra ID e AWS IAM para RDS e Aurora. Quando você salva a senha, a extensão a guarda no gerenciador de credenciais do sistema operacional, nunca em texto puro nos arquivos de configuração.

Os perfis salvos aparecem na lista de conexões para reuso. Também é possível organizá-los em grupos com cores, o que ajuda a separar desenvolvimento, homologação e produção de forma visual.

Explorando objetos com o Object Explorer

Depois de conectar o PostgreSQL ao VS Code, expanda o servidor, o banco e os esquemas no Object Explorer. Ali aparecem tabelas, views, funções, sequências, tipos, extensões e roles.

A recomendação da Microsoft é simples: comece por uma única tabela que a sua aplicação usa. Você não precisa entender o banco inteiro para dar o próximo passo.

Além disso, o explorador tem uma busca por nome e gera scripts com o botão direito. Com isso, um SELECT, um CREATE ou um ALTER de qualquer objeto abre direto no editor de consultas.

Um exemplo: receita por cliente no trimestre

O artigo original propõe um cenário bem comum: descobrir quais clientes geraram mais receita em um trimestre. Para isso, você junta clientes e pagamentos, filtra por data, agrupa e ordena.

-- Primeira versão: junta tudo e agrega depois
SELECT c.customer_id,
       c.first_name,
       c.last_name,
       SUM(p.amount) AS total_revenue
FROM customers AS c
JOIN payments AS p ON p.customer_id = c.customer_id
WHERE p.payment_date >= DATE '2026-07-01'
  AND p.payment_date <  DATE '2026-10-01'
GROUP BY c.customer_id, c.first_name, c.last_name
ORDER BY total_revenue DESC
LIMIT 10;

Essa consulta funciona e é fácil de ler. No entanto, em tabelas grandes, o join acontece antes da agregação, e o banco pode processar muito mais linhas do que o necessário.

Uma reescrita possível agrega os pagamentos primeiro e só depois junta com os clientes. O texto da Microsoft faz questão de dizer que isso é uma hipótese a investigar, não uma regra para aplicar em todo lugar.

-- Segunda versão: agrega os pagamentos antes do join
WITH quarter_revenue AS (
    SELECT customer_id,
           SUM(amount) AS total_revenue
    FROM payments
    WHERE payment_date >= DATE '2026-07-01'
      AND payment_date <  DATE '2026-10-01'
    GROUP BY customer_id
)
SELECT c.customer_id,
       c.first_name,
       c.last_name,
       qr.total_revenue
FROM quarter_revenue AS qr
JOIN customers AS c ON c.customer_id = qr.customer_id
ORDER BY qr.total_revenue DESC
LIMIT 10;

Por fim, a regra mais importante dessa etapa: confira os resultados, e não só o tempo de execução. Uma consulta mais rápida ainda precisa responder à pergunta certa, então compare as duas saídas linha a linha antes de trocar uma pela outra.

Lendo o plano de execução do PostgreSQL no VS Code

Para comparar as duas versões com dados, use o Query Plan Visualizer do PostgreSQL no VS Code. Selecione a consulta e clique em Visualize Query Plan na barra do editor.

Em seguida, a extensão pergunta o formato e as opções do EXPLAIN. JSON funciona melhor nas visões gráficas, enquanto ANALYZE, BUFFERS e TIMING acrescentam números reais de execução.

Atenção, porém: ANALYZE executa a consulta de verdade. Por isso, a extensão pede confirmação antes de rodar um INSERT, UPDATE, DELETE ou TRUNCATE nesse modo.

O visualizador oferece quatro visões. A Tree View desenha os nós, a Table View permite ordenar e buscar, a Icicle View mostra onde o custo se concentra e a Source View guarda a saída original.

Uma dica da documentação ajuda muito na leitura: compare as linhas estimadas com as linhas reais em cada nó. Quando os dois números divergem bastante, as estatísticas da tabela costumam estar desatualizadas.

Modos de acesso: leitura ou escrita

Dentro do PostgreSQL no VS Code, a configuração pgsql.copilot.accessMode define quanto poder o agente tem. No modo ro, ele só executa operações de leitura como SELECT, SHOW e EXPLAIN.

No modo rw, o agente também roda DML e DDL, sempre com confirmação explícita antes de executar. A documentação recomenda o ro para produção e ambientes compartilhados.

Essa separação importa porque o Copilot consegue, sim, alterar dados e esquemas. Portanto, revise todo SQL gerado antes de aprovar, e prefira testá-lo primeiro em um ambiente descartável.

Para enviar um plano já capturado ao Copilot, use o botão Analyze with Copilot no visualizador. A configuração pgsql.copilot.autoAttachQuery controla se o texto da consulta vai junto, e você pode escolher perguntar sempre, enviar sempre ou nunca enviar.

Perguntas focadas ao Copilot

Com o contexto do PostgreSQL disponível no chat do VS Code, faça perguntas pequenas e objetivas. Em uma aplicação de locadora de filmes, por exemplo, três boas perguntas seriam: quais tabelas guardam atores e filmes, como elas se ligam e onde fica o status da locação.

Trate a resposta como ponto de partida, e não como mapa verificado. Em seguida, confira os objetos na árvore, revise as ligações no visualizador e rode uma consulta pequena de leitura para confirmar o caminho dos dados.

-- Confirma o caminho entre filme, cópia em estoque e locação
SELECT f.title,
       r.rental_date,
       r.return_date
FROM rentals AS r
JOIN inventory AS i ON i.inventory_id = r.inventory_id
JOIN films AS f ON f.film_id = i.film_id
ORDER BY r.rental_date DESC
LIMIT 5;

O conselho final da seção original resume bem a postura: faça uma pergunta de descoberta, valide contra o banco e só então faça a próxima. Dessa forma, um erro do modelo não contamina as etapas seguintes.

Do índice recomendado à decisão revisada

O exemplo do artigo original envolve consultas repetidas de histórico de clientes em uma tabela grande de transações. Esse padrão pode levar a uma recomendação de índice composto.

No PostgreSQL no VS Code, o próximo passo, no entanto, não é simplesmente criar o índice. Primeiro, revise as métricas que sustentam a recomendação, o resultado esperado e o caminho de reversão.

-- Índice composto para buscas de histórico por cliente
CREATE INDEX CONCURRENTLY ix_transactions_customer_id_created_at
    ON transactions (customer_id, created_at DESC);

-- Plano de reversão, caso o resultado não seja o esperado
DROP INDEX CONCURRENTLY ix_transactions_customer_id_created_at;

O uso de CONCURRENTLY evita bloquear escritas na tabela durante a criação. Inclusive, é o mesmo padrão que o ajuste autônomo do Azure Database for PostgreSQL usa nos scripts que recomenda.

Database Agent e o que ainda está por vir

O Database Agent reúne essas peças na experiência do Azure PostgreSQL exibida no VS Code, ao lado do restante da extensão. Ele relaciona sintomas, métricas e recomendações em um só lugar.

Contudo, o vídeo da série o apresenta como uma experiência ainda por chegar, com ações aplicadas manualmente. A remediação automática aparece como capacidade futura, então confira a disponibilidade e os requisitos do Azure antes de contar com ela.

Enquanto isso, a pergunta de controle continua valendo para qualquer mudança: você consegue explicar por que ela deve ajudar, como vai medir o resultado e o que fará se não funcionar?