Arquivos da Tag: Database

Oracle compra Sun e não é 1º de Abril

Publicado em por
3

Sim, após a brincadeira infame de 1º de abril que postei aqui sobre a compra do MySQL… não é que vem a Oracle e faz uma oferta pela Sun? As coisas parecem que não andam muito bem para a gigante IBM. No ano passado a HP comprou a EDS por 14 BI esquentando a concorrência no setor de serviços, e agora é a Oracle que compra a Sun pela ninharia de 7BI. Para se ter uma idéia de como isso é pouco, a Oracle pagou no começo do ano passado 8,5 BI pela BEA e a Sun pagou 1 BI pela MySQL AB. Em tempos de crise quem tem dinheiro em caixa é rei…

E assim como o Yahoo se negou a ser comprado pela Microsoft (por cifras astronômicas em tempos pré crise), a Sun parece ter não gostado muito da oferta da IBM e aceitou uma oferta ligeiramente superior da Oracle. E zilhões de dúvidas vem a cabeça. E agora o que serão dos projetos livres da Sun? Java, OpenOfficce, MySQL, Solaris e por aí vai. Ninguém sabe… mas a primeira coisa que percebemos é que o mercado corporativo de TI vai se afunilando entre gigantes como IBM, Microsoft, HP, Dell e Oracle. Mas seria bom dar uma olhada na Oracle um pouco mais de perto.

  • A Oracle surgiu como um dos primeiros SGDBs relacionais do mercado, logo depois do DB2 da IBM. Se é verdade que o DB2 ainda dita a maior parte do padrão ISO SQL, a Oracle já lidera claramente este mercado há alguns anos;
  • Se é verdade que até a década de 90 a Oracle se firmou no mercado como desenvolvedora do maior banco de dados do mercado, também é verdade que ela virou a mesa e tem hoje uma suite completa de soluções de grande porte:
  • Se por um lado a Oracle tem uma política de licenciamento que lhe cobra por uma base de testes, um stand by e possui inúmeras funcionalidades e parâmetros não documentados nos seus produtos, oferece o download livre para qualquer um baixar e testar seus produtos e uma enorme biblioteca de documentação pronta para baixar e imprimir, em versão PDF ou HTML.
  • Sim, a Oracle investe em Software Livre sim. Tem inclusive um portal para isso, o http://oss.oracle.com/ com projetos como o OCFS2 e o Btrfs, dois poderosos sistemas de arquivos. Além disso, a Oracle tem uma contribuição intensa no kernel do Linux já faz um bom tempo.
  • Sim, a Oracle tem uma política monopolista e compra tudo que está a sua frente. Mas ao contrário de querer dominar a Internet, como a Microsoft e o Google, o foco da Oracle é bem claro: soluções corporativas para grandes empresas. E diga-se de passagem, ela tem crecido numa velocidade incrível neste segmento. Porém, se a excelência de suas soluções em banco de dados deram uma fama de competência e confiabilidade em seus produtos, o mesmo não se pode dizer sobre as suas demais aplicações que rodam sobre o seu banco de dados. O Oracle Aplication Server é uma colcha de tecnologias livres empacotadas como um monstro de várias patas e nenhum cérebro. E vai a Oracle já avisando que depois de abandonar o terrível Forms e Reports, vai abandonar o fiasco do OAS também em função de uma plataforma Java melhor… é esperar para ver. Os seus ERPs também não são a oitava maravilha em termos de tecnologia (ALGUM É)???? O PeopleSoft por exemplo não tem uma única chave estrangeira no banco de dados, fazendo toda a integridade referencial dentro da aplicação. Não é bem o que a Oracle sempre pregou nos seus manuais.
  • O suporte da Oracle é muito eficiente, funciona 24/7 de verdade. Podem lhe atender no Brasil, EUA, Japão, Índia ou onde quer que seja necessário para atendê-lo em qualquer horário. Mas veja: o nível básico de suporte (independente no nome bonito que se dê)  por e-mail, dá um trabalhão para abrir um chamado. Uma das coisas mais irritantes no site de suporte da Oracle é que eles utilizam tecnologia da Oracle para montar o portal web. É horrível, quem está acostumado com o Gmail e outras interfaces cheias de Ajax como o WordPress sabe o quão terrível é o metalink da Oracle. Fizeram uma versão nova com uso de Flash… piorou!

Então se por um lado a Oracle tem tradição com Software Livre, não tem foco em produtos na linha do MySQL e do OpenOffice. É claro que se é para minar a concorrência com a Microsoft pelo mercado de médio porte, pode não ser má idéia investir um pouco neles, mas não acredito que será o foco principal deles. É claro que podem surgir estratégias inovadoras junto ao MySQL… ele pode se tornar mais aberto ao Oracle e virar um novo Times Ten, mas não acho que vai perdes suas características atuais. Manter o Marketshare do MySQL, apesar de não trazer muito lucro será muito bom para a Oracle que pegará duas pontas do mercado. Já o Solaris o Java são com certeza algo de interesse por parte da Oracle. Veja que o Btrfs que a Oracle criou é baseado no ZFS que por problemas de licenças da Sun, não pode ser agregado ao Linux que usa GPL. Daí se vê a preocupação da Oracle com algumas boas tecnologias encontradas no Solaris. O Java então… toda a suite que roda sobre os bancos de dados Oracle usa Java. Isso sim é um tiro certeiro. Já os servidores SPARC são bons competidores para os servidores da HP e IBM. São caros, mas tem um mercado cativo ainda bem definido em soluções de grande e médio porte.

Mas temos um perdedor claro aqui: o PostgreSQL que vinha sido apoiado pela Sun está certamente fadado a perder esta condição. É claro que existem outras e muitas outras empresas apoiando. Mas a ausência da Sun será sentida, com certeza.

OBS: O artigo do Peter Eisentraut é bem interessante. Acho que concordo com quase tudo que ele diz. Vale a pena dar uma olhada lá.

Por que meus testes de desempenho no PostgreSQL usando o pgbench variam tanto?

Publicado em por
Comentar

Hoje recebi um e-mail de alguém me perguntando porque os testes dele com o pgbench variam tanto, mesmo usando os mesmos parâmetros todas as veses. Para quem não sabe o pgbench é um pequeno aplicativo que lhe ajuda a fazer medições de perfomance no banco de dados simulando um teste TPC-B. Ele é muito simples de se utilizar e permite realizar testes com diferentes volumes de dados, conexões simultâneas e transações por conexão. O pgbench NÃO SERVE para fazer tuning em servidores de produção, mas serve para ajudar medir a diferença entre diferentes hardwares, SOs, sistemas de arquivo, etc. No mínimo, com o pgbench você vai começar a aprender muito sobre performance no PostgreSQL, comparando seus resultados em diferentes cenários.

Mas, voltando ao nosso colega, vejamos os resultados que ele obteve:

TPS: 19
TPS: 23
TPS: 18
TPS: 25
TPS: 23
TPS: 29
TPS: 35
TPS: 17

Veja que de 17 para 35, a direrença é de mais de 100%. Realmente, não dá para desprezar uma diferença tão grande. Eu diria que de qualquer forma, apredi no laboratório de física que você tem que realizar a mesma experiência pelo menos umas 5 vezes. Além disso, se você encontra um resultado que está destoando demais dos outros, é melhor repetir o teste mais umas 5 vezes com cuidado redobrado e se apenas um valor destoar, você deve descarta-lo. Assim o seu resultado é uma média entre os testes considerados válidos (sem o resultado descartado). No caso de um instrumento de medida direta (como uma régua ou termômetro) é fácil saber qual é a precisão da sua medida (metade da menor divisão, repetia o professor todas em as aulas no laboratório). No nosso caso, temos que ficar com o dado estatístico das medições considerando a variação dos resultados obtidos.

Veja, se você faz um ajuste na configuração do PostgreSQL e tem um aumento de desempenho de 2%, mas as suas amostras tem uma margem de erro (em relação a média) de 10%, você pode se questionar se realmente pode afirmar alguma coisa. Bom, mas se você tem 100% de variação… alguma coisa está realmente errada.

O primeiro detalhe sobre o nosso colega é que ele usa o PostgreSQL em Windows. Veja… usar o PostgreSQL em Windows funciona… mas fazer tuning em Windows não é tão eficiente. Não sou um profundo conhecedor do Windows, mas que eu saiba você tem muitas opções de ajustes de desempenho neste SO. O PostgreSQL, assim como outros grandes SGDBs, foram construídos para funcionar originalmente em sistemas operacionais Unix. Outro problema é que como o SO é uma caixa preta, você nunca sabe o que está rodando em paralelo exatamente e dificilmente tem controle sobre isso. Isto não quer dizer que não é possível ver o PostgreSQL rodando satisfatóriamente em Windows, significa que o Windows não é a opção número um de quem procura um SO robusto, confiável, seguro e rápido. Mas se você não está querendo levar o seu banco de dados ao limite, não há nada de errado em usar o Windows e ajustar o PostgreSQL para que ele tenha um desempenho melhor nele.

Vejamos alguns outros ítens que você deve se perguntar antes de avaliar os resultados:

  1. Qual tipo de disco você usa? Os discos SATA são muito instáveis para testes, pois não conseguem manter um fluxo de dados em alta velocidade por muito tempo. Este não é um problema do disco físico em si e sim do protocolo do SATA. Usar discos SCSI ou SAS lhe trarão resultados mais confiáveis.
  2. Você deixou os discos isolados para o banco? Deixou discos isolados para o Wall?? A questão aqui é saber se alguma outra aplicação pode estar competindo com o acesso aos discos.
  3. Você tem certeza absoluta que não tem nenhuma outra aplicação rodando em segundo plano. O ideal é deixar uma instalação do SO o mais crua possível. O principio básico da experimentação científica é ter um ambiente controlado para que qualquer pessoa possa reproduzir exatamente os mesmos testes. Isto significa que você tem de documentar exatamente como o SO foi instalado, incluindo parâmetros de configuração.
  4. Você tem que realizar testes mais longos para que ocorram checkpoints no meio. Se você parar para estudar o mecanismo de funcionamento interno do PostgreSQL, descobrirá que o momento em que o checkpoint ocorre há uma degradação de performance significativa. Realize testes que garantam a ocorrencia de pelo menos uns 10 checkpoints. Imagine testes que durem no mínimo uma hora cada.
  5. Você precisa decidir como vai configurar o vacuum. Se usar o autovacuum, tem que utilizar testes longos para que a ocorrencia do autovacuum nas tabelas seja computado e ocorram um número de vacuuns semelhantes em cada testes.
  6. O cache de memória é um ponto crítico. Cada vez que você roda um teste, uma parte dos dados fica em memória, seja o IPC, cache em userspace, kernespace, o cache da controladora de discos ou o cache dos discos em si. Resultado: para ter certeza que a memória está num estado idêntico entre os testes… reinicie o servidor entre cada testes. Após reiniciar o servidor, tenha o cuidado de realizar exatamente as mesmas operações na mesma órdem para minimizar as diferenças de quais dados entram no cache. Podem haver outras formas de controlar o cache do disco, mas eu só conheço esta.
  7. Use uma quantidade gererosa de dados, usar menos de 1GB de dados dificilmente reproduz cenários realistas. A não ser que o seu alvo sejam bases realmente pequenas, é melhor fazer testes com diferentes tamanhos de bases. 1GB, 10GB e 100GB são um bom começo.
  8. Se você pretende realizar os testes simulando uma grande quantidade de conexões, faça-o a partir de 1 ou mais clientes remotos e não a partir do servidor. Testes com 100, 200, 500, 1000 conexões simultâneas podem exigir uma estrutura considerável para os clientes. Você vai querer medir o impácto da rede no desempenho e ao mesmo tempo não vai querer que os clientes sejam um peso no desempenho do servidor, a não ser que a sua aplicação e o seu banco de dados fiquem no mesmo servidor. Se for esse o seu caso, prepare-se para um ajuste de desempenho bem mais complexo.

Antes de você achar que o PostgreSQL é um banco “instável”, “lento” ou pouco confiável, Recomendo enfáticamente que você estude mais sobre o funcionamento do PostgreSQL, realize testes em um SO Unixlike como Linux, Solaris e FreeBSD, e use outras ferramentas de testes como o DBT-2 e os testes do TPC como o TPC-C, TPC-E e TPC-H.

Em tempo, escrevi um pequeno texto para quem está começando: “12 dicas para aprender a ajustar a performance em bancos de dados“.

Coisas que um desenvolvedor da Oracle um dia vai me explicar…

Publicado em por
2

Veja, eu respeito o SGDB Oracle. Ele não apenas é um dos primeiros bancos de dados relacionais do mercado como também é robusto, confiável e possui uma miríade de recursos. Mas convenhamos, para um SGDB que está a tempos no mercado, algumas coisas são realmente incríveis. É claro que existem algumas explicações que dizem respeito a história de como o produto surgiu e muitas que tem mais haver com a estratégia de marketing da Oracle.

  • A Oracle possui uma enorme documentação. Toda ela está disponível on-line para qualquer um baixar. O mesmo acontece com os softwares (não as atualizações, claro). Uma das coisas que eu aprecio na documentação da Oracle, são as suas recomendações quanto as melhores práticas. Algumas delas são específicas em relação ao seu produto, mas muito do que está lá se aplica a qualquer banco de dados. Dito isso, me explique: qual o motivo de tantos produtos da Oracle não seguirem as suas próprias recomendações. Você não acredita? Quem conhece as restrições das aplicações feitas em FORMS sabe do que eu estou falando. Agora imagine um ERP inteiro sem uma FK (chave estrangeira). Isso mesmo… o famoso ERP da Oracle não tem nenhuma. Alguém me explica isso?
  • Eu falei bem da documentação da Oracle, não? Pois é, os caras fazem um bom trabalho nela. Mas tem um problema. Algumas coisas misteriosamente não estão lá. É quase inacreditável que eles esqueçam de documentar coisas tão importantes na documentação. Realmente não faz nenhum sentido. Vou lhes dizer que não é pouca coisa.
  • Mais um detalhe bizarro sobre a documentação da Oracle. Você já olhou o manual de instalação deles? Bom, eles tem uma lista de dependências que devem ser instaladas para que você não falhe miseravelmente no meio do caminho. No entanto há algumas coisas bizarras lá. Eu nunca entendi o que o gnome-libs, o xscreensaver e o control-center fazem na lista de dependências. São completamente inúteis. Você definitivamente não precisa delas no seu servidor, mesmo que você queira usar o instalador gráfico. Ainda assim, se você cair na besteira de ler a documentação que acompanha os CDs do Oracle, ou a documentação que vem junto com os binários que você baixa no site, você pode encontrar sérios problemas no caminho. Algumas dependências simplesmente não estão descritas nesta versão da documentação, como você poderia esperar. Não esqueça, sempre olhas os “Release Notes” na documentação on-line. Particularmente, se você for fazer uma instalação em Linx com 64 bits, você me agradecerá muito por esta dica. Isto acontece porquê o instalador do Oracle de 64 bits roda em 32 bits. Surpresa, as dependências de 32 bits não estão na documentação original.
  • Sim, o famoso processo de instalação do banco de dados está longe de ser um processo simples. Eu realmente não conheci o Oracle nas suas versões mais antigas. Só conheço ele a partir da versão 8. Não tenho nada contra as zilhões de recomendações de acertos no SO antes da instalação. Na verdade, isso é até bem bacana. Uso muito destas recomendações com outros SGDBs. Mas o instalador gráfico deles é simplesmente horrível. Porquê? É muito simples… ele força você a instalar a interface gráfica no seu servidor. Para os usuários do Windows, tudo bem, mas no mundo Unix isto é uma heresia. Para complicar ainda mais… o instalador é feito em Java e pesa uma tonelada. Fazer um instalador em modo texto não seria tão complexo assim. Não é que seja impossível fazer a instalação em modo texto. Claro que é possível. Mas você tem de criar um arquivo enorme de configurações que pode ser um inferno de editar, conforme forem as suas necessidades. Eu mesmo já criei alguns scripts para me ajudar a criar os arquivos de isntalação em modo texto. Daí para criar um instalador em modo texto seria realmente um pulo. Convenhamos que esta não seria uma tarefa árdua para a Oracle.
  • O SQL*Plus número um dos DBAs Oracle. É claro que surgiram coisas mais amigáveis como o SQL Developer, mas o SQL*Plus é a única ferramenta em modo texto que você tem para utilizar. Eu realmente gosto muito das interfaces gráficas. Mas na hora do aperto elas não me servem muito. Quando preciso rodar uma rotina pesada ela também não me ajuda muito. E principalmente, quando quero fazer algum script rápido que acesse o SGDB, o SQL*Plus é uma mão na roda. Mas há um detalhe muito bizarro nele. Ele não tem suporte a biblioteca mais manjada das ferramentas em linha de comando: a ReadLine. Sem ela ou outra substituta a altura, voltamos para a idade do bit lascado. Até as setas do seu teclado perdem a utilidade. É realmente lastimável a perda de produtividade que este detalhe nos proporciona no dia a dia. Para quem está acostumado com o Bash, isto é simplesmente irritante.
  • O metalink é a porta de entrada para um universo a parte da Oracle. Patches de segurança, zilhões de documentos sobre erros bizarros, uma maravilha. Só tem um problema. Parece que a Oracle usou seus próprios produtos para criar o seu site. E vou lhes dizer uma coisa… eles parecem que nunca utilizaram o gmail na vida. Definitivamente nunca ouviram falar em AJAX. Para completar, ainda usam FLASH para montar um site lento, feito e com uma péssima usabilidade. Depois que você se acostuma com o jeito tosco do site, até dá para se virar bem, a não ser é claro, que você esteja com um pepino enorme na mão e a sua conexão com a Internet esteja lenta. Se for esse o seu caso, vou lhe dizer qual é a forma de rezolver seus problemas de forma mais rápida, interativa e eficiente: entre no servidor de IRC da freenodes na sala #oracle. Você vai descobrir que o “suporte livre” realmente funciona.
  • O padrão SQL já vai completar 20 anos em 2009. Ele surgiu em sua primeira versão oficial em 1989. Ficou famoso pela versão de 1992, e depois contou com mais duas grandes versões sendo a última em 2003. É verdade que a moral da ISO anda meio baixa nos últimos tempos. Mesmo assim, não há motivos para a Oracle ser tão lenta na adoção dos padrões. O tipo de dado TIMESTAMP surgiu apenas na versão 9i. O tratamento com os nulos, o nvarchar, a ausência do tipo inteiro e outras coisas estranhas do Oracle lhe garantem não conformidades significativas com o padrão SQL.
  • A Oracle tem uma tara por arquivos binários que nenhum ser usuário possa ler. A coisa não se limita aos dispositivos crús (Raw Devices), vai dos backups com RMAN, ao rastreamento de erros com trace. Enfim, o negócio é confiar na Oracle…

Você não concorda com as minhas observações? Diria que tem outros itens para acrescentar a lista? Coloque nos comentários então!

FreeBSD escalável para Bancos de Dados

Publicado em por
3

É fato:

  • O Linux historicamente escala melhor do que o FreeBSD;
  • O PostgreSQL historicamente escala melhor que o MySQL;

Digam o que quiserem, todos os testes conduzidos por pessoas sérias parecem concordar com estas duas afirmações. Para quem não sabe, “escalar” significa aumentar de performance proporcionalmente ao número de CPUs existentes no equipamento.

Mas o tempo passa, e como prometido, a versão 7.0 do FreeBSD parece ter cumprido a promessa de melhorar o escalonador de processos. O resultado você observa aqui. Os testes podem não ser 100% fidedignos ao representar uma situação real com banco de dados, mas os números parecem ser bastante promissores.

Parabéns a equipe de desenvolvimento do FreeBSD… certamente vocês vão ganhar novos DBAs como usuários.

OBS: Os testes foram realizados com até 8 cores, não há informações para um número maior de processadores.

Pesquisa entre os maiores bancos de dados do mercado: PostgreSQL pede passagem!

Publicado em por
Comentar

A Evans Data Corporation realizou uma pesquisa com 1400 usuário de bancos de dados em todo o mundo para saber o que eles acham dos principais SGDBs do mercado. A pesquisa virou matéria na InformationWeek que por sua vez foi comentada pelo Sr. Lewis Cunningham.

A pesquisa envolveu os seguintes bancos de dados:

  • Informix Dynamic Server
  • IBM DB2
  • Microsoft SQL Server
  • MySQL
  • Oracle Database 10g or later
  • PostgreSQL
  • Sybase Adaptive Server

Os critérios de avaliação foram:

  • Performance
  • Funcionalidades de segurança
  • Scalabilidade vertical
  • Atomicidade
  • Consistência
  • Isolação de transações
  • Durabilidade das transações
  • Qualidade das ferramentas de modelagens
  • Suporte ao XML
  • Suporte a Multiplatforma
  • Qualidade das ferramentas de gerenciamento inclusas no banco de dados
  • Qualidade das ferramentas de gerenciamento avaliáveis por outros fornecedores
  • Suporte a linguagens de programação

Antes de comentar sobre os resultados, é preciso dizer que a pesquisa é sobre a percepção dos usuários e não sobre testes de laboratório. portanto não reflete características reais dos softwares em questão e sim o que os seus usuários pensam deles.

Os resultados:

  • A Oracle ficou em primeiro lugar em todos os critérios. Com o lançamento do 11g no ano passado eu imagino que toda a campanha de marketing esteja ainda viva na memória das pessoas, mas a posição não é de toda desmerecida. Particularmente, acredito que as ferramentas de monitoramento e gerenciamento da Oracle sejam realmente excelentes. Mas acredito que nos itens relativos a ACID (Atomicidade, Consistência, Isolação e Durabilidade) o DB2 rodando em mainframes ainda seja lider absoluto. O DB2 ficou em segundo lugar, mostrando que a Oracle realmente conseguiu cativar os corações do pessoal de TI. Também senti falta da Teradata como competidor, que é líder na área de Data Warehouse e teriam batido a Oracle e o DB2 nesta área. Pelos ítens da pesquisa, o foco foi avaliar os competidores que se destacam na area de OLTP.
  • O MySQL foi o terceiro SGDB mais bem avaliado no geral. Apesar disso ter ficado longe no ranking no que diz respeito a ACID, escalabilidade e funcionalidades de segurança. O que puxou sua nota para cima foi a sua avaliação em suporte multiplataforma (2º lugar), performance (3º lugar), qualidade de ferramentas fornecidas por 3ºs (3º lugar) e suporte a linguagens de programação. Acho que a avaliação reflete bem o status do MySQL, sua popularidade e suas características de bicicleta de velódromo: é leve e rápido, mas não tem freios, câmbio, etc. O lançamento do falcon é a promessa de mudar isso. Particularmente eu gostaria que o MySQL continuasse exatamente do jeito que ele é, pois se torna uma ótima opção em sites web dinâmicos, que não se preocupam muito com transações.
  • O MS SQL Server foi mal em suporte multiplataforma (ok, isso é óbvio) e performance. Se destacou na parte das ferramentas de modelagem, gerenciamento e suporte a XML.
  • O PostgreSQL não foi muito bem… foi mal avaliado nas ferramentas de gerenciamento, modelagem, suporte a XML. No entanto foi bem avaliado em ACID e em funcionalidades de segurança. Estas avaliações positivas são importantes, pois demonstram a percepção dos usuários de que o PostgreSQL é confiável. Uma zebra ocorreu na parte de suporte a plataformas, pois o PostgreSQL deveria ser melhor avaliado aqui. Veja por exemplo que ele roda em FreeBSD uma plataforma para poucos.

O PostgreSQL foi o que teve a segunda pior avaliação Mas estamos em 2008 e apesar do nome da pesquisa, ela foi conduzida em dezembro de 2007. Com o lançamento do PostgreSQL 8.3 algumas coisas mudam na avaliação: a performance melhorou muito e o suporte a XML também. Isto já seria motivo para o PostgreSQL subir vários pontos e encostar no Oracle e no DB2.

O que temos que perceber é que o PostgreSQL vem se desenvolvendo sobre terreno firme. Com a parte de ACID bem resolvida, é possível crescer sem ter que abrir mão da segurança. A performance do PostgreSQL vem crescendo numa taxa que o coloca entre os líderes desta categoria. Algumas funcionalidades que precisam ser melhoradas como a parte de particionamento de tabelas já estão sendo trabalhadas para a versão 8.4. Assim, o que os usuários ainda sentem falta (veja o histórico das listas do PostgreSQL e você verá que isto é recorrente) são de ferramentas de monitoramento, gerenciamento e modelagem. Ainda há muito o que se trabalhar nesta área. Mas acredito que isto seja uma questão que se resolverá. O PostgreSQL tem evoluído muito na quantidade de funções e tabelas de sistemas capazes de fornecer informações úteis para o DBA. O pgsnmpd deverá abrir as portas para o gerenciamento corporativo. O que falta são ferramentas mais amigáveis. Isto não será problema. Já vemos coisas muito promissoras neste sentido. O PostgreSQL está sedimentado sobre uma base sólida, a parte do acabamento virá naturalmente.