O PostgreSQL 8.3 foi lançado. Demorou mais que o dobro do que se esperava. Sim… a expectativa inicial eram de 6 meses até o lançamento. Mas não há motivo nenhum para se ficar triste. 2007 foi um ano excepcional para o PostgreSQL.
Vamos começar simplificando as coisas, agora é correto chamar o PostgreSQL de Postgres. Segundo a documentação oficial:
Many people continue to refer to PostgreSQL as “Postgres” (now rarely in all capital letters) because of tradition or because it is easier to pronounce. This usage is widely accepted as a nickname or alias.
Particularmente eu me acostumei a falar e escrever “PostgreSQL”. Dá mais trabalho e é mais enrolado. Mas além disso, “Postgres” parece ter mais força, causa menos confusão (com pessoas que acabam usando “Postgre” ou “Postgree”). Comercialmente também parece soar melhor, :-).
Bom, antes de falar sobre a versão 8.3, eu gostaria de mostrar alguns detalhes interessantes sobre como o Postgres passou por 2007. A comunidade cresceu, não apenas em número, mas em qualidade. Após a explosão populacional causada pela versão do Postgres nativa para o Windows, houve um crescimento numérico em usuários do Postgres, mas a sua comunidade caiu notavelmente em termos de nível técnico. 2007 pareceu recuperar o fôlego. Veja alguns detalhes interessantes:
- O planet postgresql cresceu em número de participantes e número de artigos;
- No Brasil também surgiram alguns blogs novos sobre PostgreSQL como o PG Viável e o Meu Blog de PostgreSQL;
- O número de companhias contribuindo diretamente com código aumentou, como a Sun e a Skype;
- O número de projetos no Pg Foundry também aumentou muito (hoje conta com mais de 260 projetos). Eles estão mais ativos também, com varias novas versões de projetos sendo lançadas toda semana.
- O número de eventos em que o Postgres esteve presente ou de eventos dedicados exclusivamente ao Postgres também explodiu.
- Foi criado o Postgres OnLine Journal;
Tudo muito bonito… mas chegou a hora do “Show me the code”! Sim, sim, vamos ao que realmente interessa. Vou começar mostrando um teste de performance criado quando o PostgreSQL ainda estava na sua fase Beta.
Antes de dizer qualquer coisa, você precisa entender que o teste foi feito numa condição muito específica:
- Uso do pgbench que realiza uma carga semelhante ao TPC-B, que é uma carga transacional que visa simular um ambiente OLTP;
- As tabelas forma ajustada para um fator de escala de 100, o que equivale a um volume de 10 milhões de linhas;
- 100 conexões ativas simultâneas;
- 10 milhões de transações;
Isto demonstra um cenário bastante específico. Se você esperar um ganho de performance em pequenas aplicações, você certamente não encontrará ganhos de performance tão significativos. Mas o cenário utilizado é muito importante, pois é semelhante a um ambiente corporativo, onde temos aplicações com um grande volume de dados sendo alterado por muitos usuários simultaneamente. Este é um cenário bastante difícil de lidar. Bancos de dados menores certamente sofrerão amargamente neste cenário.
Quando a versão 8.0 foi lançada, uma série de novas funcionalidades importantes marcaram a transição da série 7.x para a série 8.x . Além das novas funcionalidades que tornam a vida do desenvolvedor mais fácil (ou funcionalidades que melhoram a usabilidade) notou-se um aumento significativo nas opções de segurança (PITR, Stand By, etc) e de desempenho (Tablespaces, Particionamento, AutoVacuum, etc). Com a versão 8.3, estas novas funcionalidades atingiram um bom grau de maturidade. Ao comparar a versão 7.4 com a versão 8.3, você verá um salto enorme atingido em apenas 4 anos. Veja a matriz de comparação de funcionalidades para ter uma idéia do que foi realizado.
Ao olhar a última versão do Oracle 11g, percebe-se um aprimoramento notável nas ferramentas de gerenciamento do SGBD. As ferramentas de gerenciamento do Oracle 11g são realmente invejáveis. No entanto, quando pensamos em desempenho, não vemos um aprimoramento significativo. O mesmo aconteceu na transição da versão 9i para o 10g.
Por outro lado, o Postgres tem dado saltos enormes em termos de desempenho e ainda possui ferramentas pouco sofisticadas. A questão é que o desempenho do Postgres deve ultrapassar o do Oracle rapidamente. Uma pergunta que muitos devem estar se fazendo é se ele já não passou com o lançamento do 8.3! De toda forma, isto deverá ser o suficiente para atrair novos investimentos em torno do Postgres, fazendo com que mais empresas ofereçam ferramentas de gerenciamento para o Posrgres. O time principal do Postgres não desenvolve nenhuma ferramenta de gerenciamento além do psql. O resto fica a cargo de outros projetos de software livre ou de empresas que oferecem ferramentas proprietárias.
O Postgres tem simplificado o trabalho para muita gente. Migrar para ele está cada vez mais fácil. Além de incorporar funcionalidades e sintaxes semelhantes as do Oracle, o mesmo tem acontecido com o MySQL, com a introdução do tipo de dados ENUM, por exemplo. Chegou a hora de começar a comparar o Postgres e o MySQL mais de perto. No entanto engana-se quem pensa que o Postgres adota padrões exóticos de vários SGDBs se tornando uma colcha de retalhos. O Postgres concentra a maior parte dos seus esforços em trazer funcionalidades de acordo com o padrão SQL. Isto significa que o Postgres é uma excelente opção para aqueles que estão preocupados com a portabilidade também.
Bom… se você não testou o Postgres 8.3, vá correndo testar. Se já testou, você já pode ir vendo o que está por vir na versão 8.4…
