PostgreSQL e SQL

Em plataformas de dados, é comum armazenarmos o histórico de execuções de cada pipeline. Uma mesma rotina pode ter sido executada dezenas ou centenas de vezes, mas algumas consultas precisam mostrar apenas seu estado mais recente. No PostgreSQL, podemos resolver esse problema de forma concisa com DISTINCT ON. O problema Considere uma tabela que registra as execuções de pipelines: CREATE TABLE execucoes_pipeline ( id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY, pipeline text NOT NULL, status text NOT NULL, iniciado_em timestamptz NOT NULL, finalizado_em timestamptz ); Cada linha representa uma execução: ...

Em relatórios SQL, é comum precisarmos calcular diferentes totais a partir do mesmo conjunto de dados. Imagine uma tabela de pedidos com a seguinte estrutura: CREATE TABLE pedidos ( id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY, cliente_id bigint NOT NULL, status text NOT NULL, valor numeric(12, 2) NOT NULL, criado_em timestamp NOT NULL DEFAULT current_timestamp ); Queremos apresentar, em uma única consulta: quantidade total de pedidos; pedidos pagos; pedidos pendentes; pedidos cancelados; valor total dos pedidos pagos. A solução tradicional com CASE Uma forma comum de resolver o problema é colocar expressões CASE dentro das funções de agregação: ...

Ao inserir um registro no PostgreSQL, é comum precisar do identificador gerado pelo banco para continuar o processamento. Uma solução possível é executar o INSERT e, em seguida, fazer outra consulta. O PostgreSQL oferece uma alternativa mais direta: a cláusula RETURNING. O problema Considere uma tabela que armazena tarefas de processamento: CREATE TABLE jobs ( id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY, file_path text NOT NULL, status text NOT NULL DEFAULT 'pending', created_at timestamptz NOT NULL DEFAULT now() ); Depois de criar um job, a aplicação precisa conhecer o id, o estado inicial e a data atribuída pelo banco. ...

No Lab 01, construímos a fundação: uma instância PostgreSQL reproduzível, persistente e validada com Docker. Mas subir um banco saudável é apenas o primeiro passo. Para testar backup, replicação, observabilidade ou performance, precisamos de uma base que se aproxime de um cenário real: usuários com responsabilidades diferentes, schemas bem definidos, extensões operacionais, relacionamentos, índices e dados suficientes para exercitar o ambiente. Esse é o objetivo do Lab 02 do PostgreSQL Reliability Lab. ...

Um dos problemas mais comuns ao trabalhar com banco de dados é a falta de consistência entre ambientes. Quantas vezes já vimos situações como: “Na minha máquina funciona” Diferenças entre desenvolvimento, homologação e produção Dados que não persistem após reiniciar o ambiente Dificuldade em reproduzir bugs Esses problemas geralmente não estão relacionados ao código da aplicação, mas sim à forma como o ambiente de banco de dados é configurado. Neste post, vou mostrar como construir um ambiente PostgreSQL utilizando Docker com foco em reprodutibilidade, persistência e confiabilidade, servindo como base para cenários mais avançados. ...

Instalar PostgreSQL no Windows para um ambiente de desenvolvimento com Protheus não é apenas questão de executar um instalador. É necessário configurar o banco corretamente para que a integração com DBAccess funcione de forma estável e previsível. Este guia apresenta o passo a passo completo, desde o download até a integração total com o Protheus. ⚠️ Importante: Recomendação da TOTVS A instalação do PostgreSQL em Windows é recomendada APENAS para ambientes de desenvolvimento ou testes. ...

O ponto de partida Quando começamos a trabalhar com backup no PostgreSQL, a primeira ferramenta que aparece é o pg_dump. Mas rapidamente surge uma dúvida importante: Isso é suficiente para produção? A resposta está diretamente ligada a entender a diferença entre backup lógico e backup físico. Essas duas abordagens não competem entre si: elas resolvem problemas distintos, e uma estratégia madura usa as duas. Uma analogia simples Antes de entrar nos detalhes técnicos, uma analogia ajuda a situar a diferença: ...

O que é PostgreSQL O PostgreSQL é um sistema gerenciador de banco de dados objeto-relacional e open source. Na prática, isso significa combinar aderência forte ao padrão SQL com recursos clássicos de bancos relacionais, como transações, integridade e controle de concorrência, sem abrir mão de extensibilidade para criar tipos, funções, operadores e extensões. Esse equilíbrio explica por que ele é visto como um banco de dados generalista: funciona muito bem em sistemas transacionais e também atende cenários analíticos e geoespaciais. ...

Uma dúvida comum entre desenvolvedores e analistas de dados é: Qual a diferença entre EXISTS, IN e JOIN? Essas três abordagens podem retornar o mesmo resultado, mas possuem diferenças importantes de comportamento e performance, especialmente em bases grandes. Para quem trabalha com ERP como o Protheus, onde as tabelas crescem rapidamente, entender essas diferenças ajuda a evitar consultas lentas e escolhas ruins de modelagem SQL. Neste artigo, vamos analisar: como cada abordagem funciona quando usar cada uma diferenças práticas de performance exemplos com tabelas comuns do Protheus Exemplo prático Imagine duas tabelas comuns em um cenário de ERP: ...