Blog
Para quem já sabe o básico e quer ir fundo. Aqui o assunto é como os modelos funcionam em produção: memória, roteamento, ferramentas, agentes. O lado técnico que pouca gente explica direito.
Multi-Version Concurrency Control: Postgres não locka reads, cria snapshots. xmin/xmax em cada tuple. Isolation levels reais no PG: Read Committed (default), Repeatable Read (snapshot), Serializable (SSI — detecta dangerous patterns). Dirty read impossível no PG.
Planner compara planos por cost estimado. Nodes: Seq Scan, Index Scan, Bitmap Index Scan, Nested Loop, Hash Join, Merge Join. EXPLAIN ANALYZE executa e mostra real. Ler plan: cost, rows estimates vs actual (diferença = stats desatualizadas). BUFFERS mostra I/O.
B-tree (default) é 90% dos casos. BRIN pra tabelas muito grandes ordenadas (log data). GIN pra arrays/jsonb/FTS. GiST pra geométrico/proximity. Partial (WHERE condition) reduz tamanho. Covering (INCLUDE) elimina heap fetch. Expression index pra computed values.
MVCC cria dead tuples em cada UPDATE/DELETE. Autovacuum limpa — mas em workloads agressivos, não dá conta → bloat (tabela crescendo, performance caindo). Configurar autovacuum_vacuum_scale_factor por tabela. VACUUM FULL bloqueia — use pg_repack. Monitoring: pg_stat_user_tables.
Postgres usa 1 process por conexão (pesado). App moderno com pool em cada instância + autoscale = easy 10k conexões. pgbouncer entre aplicação e PG, em 3 modes: session (1 conn por client), transaction (reuse entre txs — mais comum), statement. Serverless (Lambda) trap: spawn exhaustion; use RDS Proxy ou Supabase pooler.
Streaming replication (binary WAL) — primary→replica quase sync. Logical replication (decoded, selective) pra CDC/partial. synchronous_commit: off (fast but can lose) / on (default, replica ACK) / remote_apply (replica applied). Failover: Patroni, pg_auto_failover. Split-brain é real; STONITH obrigatório.
Declarative partitioning no PG 10+: RANGE (por data), LIST (por região), HASH. Partition pruning (planner ignora partitions irrelevantes). Sharding = múltiplos servers; Citus (agora Microsoft) é extensão canônica. Quando sharding? > 10TB ou >100k writes/s sustentados.
Projeto: dataset real (100M+ rows), query inicial lenta (30s+). Diagnosticar com EXPLAIN ANALYZE + BUFFERS. Adicionar índices corretos. Rewrite query se necessário. Medir melhoria (pg_stat_statements). Entregável: before/after benchmark + análise escrita.