PostgreSQL é suficiente

• Uma página que reúne links sobre como usar o PostgreSQL em várias áreas
  • jobs em background, fila de mensagens, GIS, log de auditoria, controle de acesso, gerenciamento de permissões, busca, séries temporais, dados em grafo, dados externos, HTTP, API, eventos/replicação/CDC, testes unitários, migrações, dashboards/UI, visualização de dados, HTML e aplicações, LSP (Language Server Protocol)

PostgreSQL is Enough

• Usando PostgreSQL para tudo
• Simplify: simplificando ao mover código para funções do banco de dados

Trabalhos em background

• Com pg_cron, é possível gerenciar tarefas agendadas no PostgreSQL.

Fila de mensagens

• Fornece informações sobre como escolher o PostgreSQL como tecnologia de fila de mensagens.
• pgmq é um sistema de fila de mensagens baseado em PostgreSQL.

GIS/mapas

• PostGIS adiciona funcionalidades de banco de dados geoespacial ao PostgreSQL.

Log de auditoria

• pgMemento e pgaudit rastreiam mudanças e gerenciam logs de auditoria no PostgreSQL.

Controle de acesso

• acl é usado para gerenciar listas de controle de acesso no PostgreSQL.

Autenticação

• O módulo pgcrypto do PostgreSQL e pgjwt lidam com autenticação dentro do banco de dados.

Busca

• Fornece links úteis relacionados ao recurso de busca full-text do PostgreSQL.
• paradedb, pg_embedding, pgvector aprimoram os recursos de busca no PostgreSQL.

Dados de séries temporais

• timescaledb estende o PostgreSQL para gerenciar dados de séries temporais.

Dados em grafo

• Apache AGE estende o PostgreSQL para oferecer funcionalidades de banco de dados em grafo.

Dados externos

• wrappers integra fontes de dados externas ao PostgreSQL.

HTTP

• pgsql-http e pg_net processam requisições HTTP no PostgreSQL.

API

• PostgREST, graphql-engine, postgraphile, pg_graphql constroem servidores de API baseados em PostgreSQL.

Eventos, replicação, CDC

• O comando NOTIFY do PostgreSQL e walex, peerdb, debezium, pglogical rastreiam mudanças de dados e oferecem recursos de replicação.

Testes unitários

• pgtap é uma ferramenta para testes unitários de bancos de dados PostgreSQL.

Migrações

• postgresql-migrations e bytebase gerenciam migrações de bancos de dados PostgreSQL.

Dashboard / UI

• Baserow, NocoDB, AppSmith fornecem interfaces de usuário e dashboards.

Visualização de dados

• Evidence e Metabase são ferramentas de visualização de dados.

HTML e aplicações

• SQLpage, Omnigres, pg_render, plmustache integram dados do PostgreSQL a aplicações web.

Servidor de linguagem

• postgres_lsp oferece suporte ao Language Server Protocol para PostgreSQL.

O que está faltando?

• Compartilhe nos comentários o que ficou de fora

Opinião do GN⁺

• O PostgreSQL mostra, por meio de várias extensões e ferramentas, que é uma plataforma versátil que vai além de um simples sistema de gerenciamento de banco de dados.
• Este texto apresenta formas de atender a diferentes necessidades de aplicações usando PostgreSQL, oferecendo um recurso útil para desenvolvedores.
• Em especial, destaca o potencial de simplificar a arquitetura do sistema e otimizar o desempenho por meio de funcionalidades que podem ser tratadas diretamente dentro do banco de dados.

[eususu]

Dentre esses, eu uso o postgREST pessoalmente e estou satisfeito.

[GN⁺]

Comentários do Hacker News

• Compartilhamento de experiência sobre tentativas de simplificar a stack da aplicação

  Um usuário compartilha que frequentemente tenta simplificar a stack da aplicação, mas, à medida que a complexidade do sistema cresce, percebe a necessidade de uma stack tecnológica mais variada. Tentar consolidar tudo em uma única tecnologia, como o Postgres, pode acabar sendo desconfortável. Ainda assim, pode ser melhor estender uma tecnologia já existente do que adicionar uma nova camada. Por exemplo, usar o Postgres como fila de mensagens é muito mais fácil do que manter uma fila de mensagens separada. O Postgres também se destaca em extensibilidade entre os bancos de dados, e construir tecnologia em cima dele é muito divertido.

• Opinião de um dos criadores do ParadeDB sobre a extensibilidade do Postgres

  Como um dos criadores do ParadeDB, ele comenta que oferece busca rápida e recursos de análise por meio de extensões do Postgres. Para cargas de trabalho pequenas, como em startups, faz sentido permanecer dentro do Postgres pelo maior tempo possível. No entanto, quando a escala cresce, não é possível resolver tudo apenas com Postgres. Para lidar com diferentes cargas de trabalho dentro do Postgres, é preciso separar o sistema de acordo com requisitos específicos e garantir escalabilidade e resiliência independentes. Nesse ponto, passa a ser necessária uma stack de soluções especializadas para cada necessidade. Existe um movimento de construir versões em Postgres de componentes da stack, mas cada solução vai além do Postgres, e ele não acredita que haverá uma solução baseada em Postgres para todos os componentes da stack.

• Opinião sobre a decisão de usar sqlite ao iniciar novos projetos

  Um usuário decidiu começar todo projeto novo com sqlite e só migrar quando isso for absolutamente necessário. Se o Postgres serve para 90% dos casos, o sqlite serve para 80%, além de ser fácil de começar e ter bom desempenho. Quando a escalabilidade vertical falhar, você provavelmente já estará satisfeito com o que construiu.

• Dúvida de um especialista em C++ sobre bancos de dados

  Um especialista em C++ que não está familiarizado com bancos de dados questiona a necessidade deles. Ele vem de uma indústria que usa muito formatos binários personalizados e sente que bancos de dados parecem resolver muitos problemas na superfície, mas na prática não é bem assim. Limitações nos tipos de dados, problemas de atualização e incompatibilidades entre diferentes engines SQL fazem o uso de bancos de dados parecer uma má ideia. Ele entende a vantagem de interoperabilidade em volumes muito grandes de dados, mas, fora isso, pergunta seriamente qual é a necessidade de um banco de dados.

• Opinião sobre recursos adicionais do PostgreSQL

  Alguém aponta que a maioria dos recursos adicionais já vem embutida no MariaDB e cita parte da motivação do cliente HTTP para PostgreSQL. Sobre a ideia de poder escrever triggers que chamam serviços web, o usuário diz que preferiria deixar esse tipo de tarefa para outra pessoa, e não para si mesmo.

• Problema de integração com práticas de gestão de código ao usar recursos avançados

  Embora use Postgres extensivamente, sempre que utiliza recursos avançados esbarra no problema de integrá-los com todas as boas práticas da programação, como controle de versão, code review, tipos, testes e análise estática. Ele também levanta uma questão sobre migrações.

• Vantagens de prototipar novos recursos com a stack existente

  Um usuário compartilha a experiência de que prototipar primeiro um novo recurso é melhor do que introduzir algo novo desde o início. Com curadoria cuidadosa, é possível transformar o protótipo inicial em código de produção usando a mesma stack. Mas, quando o sistema atinge seus limites, pode surgir a necessidade de Redis ou de outras ferramentas especializadas. O importante é escrever wrappers de API, mudar apenas a implementação interna quando necessário e testar bem as migrações. Ele comenta que as pessoas ficariam surpresas com o quanto é possível adiar decisões tecnológicas.

• Compartilhamento de experiência de um usuário que usa Postgres, Redis e S3

  Um usuário diz que usa a combinação de Postgres, Redis e S3, e que ela nunca deu errado até agora. Às vezes tem vontade de experimentar Pub/Sub com Postgres, mas como já precisa de Redis para cache e sidekiq, e o Redis também é excelente, acaba nem tentando.

• Limites do Postgres para análise de dados em grande escala

  Um usuário compartilha que gosta muito do Postgres, mas já sentiu que ele não é suficiente quando o volume de dados é muito grande. O Postgres é perfeito para cargas de trabalho do tipo OLTP, mas, quando é necessário mais suporte a OLAP, ele recomenda usar StarRocks. A experiência de levar dados do Postgres para o StarRocks para análise é excelente, e o StarRocks também oferece suporte a consultas diretas em data lakes.

• Demanda por compressão de jsonb no Postgres

  Alguém usa tanto Mongo quanto PG, mas acha o PG muito mais simples e gostaria de abandonar o Mongo em nome da simplificação. O que falta é apenas uma coluna jsonb comprimida, na qual só seja possível inserir, selecionar e excluir, sem updates nem consultas. Assim seria possível manter uma taxa de compressão de 80-90% para chaves JSON repetitivas, como no Mongo, sem necessidade de manutenção.