Por que o PostgreSQL é a base para o futuro dos dados

Uma das maiores tendências no desenvolvimento de software atualmente é o surgimento do PostgreSQL como o padrão de banco de dados de fato. Houve algumas postagens no blog sobre como usar o PostgreSQL para tudo, mas nenhuma ainda sobre por que isso está acontecendo (e, mais importante, por que isso é importante).

Até agora!

Índice

01 PostgreSQL está se tornando o padrão de banco de dados de fato

02 Tudo está virando um computador

03 O retorno do PostgreSQL

04 Liberte-se, construa o futuro, adote o PostgreSQL

05 A escala de tempo começou como “PostgreSQL para séries temporais”

06 Escala de tempo expandida além das séries temporais

07 A escala de tempo agora é “PostgreSQL tornado poderoso”

08 Coda: Yoda?

PostgreSQL está se tornando o padrão de banco de dados de fato

Nos últimos meses, “PostgreSQL para tudo” tornou-se um grito de guerra crescente entre os desenvolvedores:

“O PostgreSQL não é apenas um simples banco de dados relacional; é uma estrutura de gerenciamento de dados com potencial para abranger todo o domínio do banco de dados. A tendência de “usar Postgres para tudo” não está mais limitada a algumas equipes de elite, mas está se tornando uma prática recomendada”.

( fonte )

“Uma maneira de simplificar sua pilha e reduzir as partes móveis, acelerar o desenvolvimento, diminuir o risco e fornecer mais recursos em sua startup é “Usar Postgres para tudo”. O Postgres pode substituir – até milhões de usuários – muitas tecnologias de back-end, entre elas Kafka, RabbitMQ, Mongo e Redis.”

( fonte )

( Fonte )

“Quando ouvi pela primeira vez sobre o Postgres (em uma época em que o MySQL dominava totalmente), ele foi descrito para mim como “aquele banco de dados feito por aqueles nerds da matemática”, e então me ocorreu: sim, essas são exatamente as pessoas que você quer que sejam criadas. seu banco de dados.”

( Fonte )

“Ele fez um retorno notável. Agora que o NoSQL está morto e a Oracle é dona do MySQL, o que mais existe?”

( Fonte )

“Postgres não é apenas um banco de dados relacional. É um modo de vida."

( Fonte )

Graças à sua base sólida, além de sua versatilidade por meio de recursos e extensões nativos, os desenvolvedores agora podem usar o PostgreSQL para tudo, substituindo arquiteturas de dados complexas e frágeis por uma simplicidade direta:

Isso pode ajudar a explicar por que o PostgreSQL no ano passado assumiu o primeiro lugar do MySQL no ranking de banco de dados mais popular entre os desenvolvedores profissionais (60.369 entrevistados):

Em quais ambientes de banco de dados você realizou um extenso trabalho de desenvolvimento no ano passado e em quais você deseja trabalhar no próximo ano? Mais de 49% dos entrevistados responderam PostgreSQL. ( Fonte )

Esses resultados são da pesquisa de desenvolvedores Stack Overflow de 2023. Se você olhar ao longo do tempo, poderá ver o aumento constante na adoção do PostgreSQL nos últimos anos:

Embora o PostgreSQL tenha sido o segundo banco de dados favorito dos entrevistados da Pesquisa de Desenvolvedores do Stack Overflow entre 2020-2022, seu uso aumentou consistentemente. Fonte: 2020 , 2021 , 2022

Esta não é uma tendência apenas entre pequenas startups e hobbyistas. Na verdade, o uso do PostgreSQL está aumentando em organizações de todos os tamanhos:

A porcentagem de uso do PostgreSQL por tamanho da empresa. ( Fonte )

Na Timescale, essa tendência não é nova para nós. Acreditamos no PostgreSQL há quase uma década. É por isso que construímos nosso negócio em PostgreSQL, porque somos um dos principais contribuidores do PostgreSQL , por que realizamos o relatório anual Pesquisa sobre o estado do PostgreSQL (mencionado acima) e por que oferecemos suporte a encontros e conferências do PostgreSQL. Pessoalmente, uso PostgreSQL há mais de 13 anos (quando mudei do MySQL).

Houve alguns posts no blog sobre como usar o PostgreSQL para tudo, mas nenhum ainda sobre por que isso está acontecendo (e, mais importante, por que isso é importante).

Até agora.

Mas para compreender porque é que isto está a acontecer, temos de compreender uma tendência ainda mais fundamental e como essa tendência está a mudar a natureza fundamental da realidade humana.

Tudo está se tornando um computador

Tudo – os nossos carros, as nossas casas, as nossas cidades, as nossas quintas, as nossas fábricas, as nossas moedas, as nossas coisas – está a tornar-se um computador. Nós também estamos nos tornando digitais. Todos os anos, digitalizamos mais a nossa própria identidade e ações: como compramos coisas, como nos divertimos, como colecionamos arte, como encontramos respostas às nossas perguntas, como nos comunicamos e nos conectamos, como expressamos quem somos.

Há vinte e dois anos, esta ideia de “computação ubíqua” parecia audaciosa. Naquela época, eu era estudante de graduação no Laboratório de IA do MIT, trabalhando em meu tese em Ambientes Inteligentes. Minha pesquisa foi apoiada por Projeto Oxigênio do MIT , que tinha um objetivo nobre e ousado: tornar a computação tão difundida quanto o ar que respiramos. Para colocar esse tempo em perspectiva: tínhamos nosso rack de servidores em um armário.

Muita coisa mudou desde então. A computação é agora omnipresente: nas nossas secretárias, nos nossos bolsos, nas nossas coisas e na nossa “nuvem”. Isso nós previmos.

Mas os efeitos de segunda ordem dessas mudanças não foram o que a maioria de nós esperava:

• A computação ubíqua levou a dados ubíquos . A cada novo dispositivo de computação, coletamos mais informações sobre a nossa realidade: dados humanos, dados de máquinas, dados de negócios, dados ambientais e dados sintéticos. Esses dados estão inundando nosso mundo.

  
  

• A inundação de dados levou a uma explosão cambriana de bancos de dados . Todas essas novas fontes de dados exigiram novos locais para armazená-los. Há vinte anos, havia talvez cinco opções viáveis de banco de dados. Hoje existem várias centenas, a maioria delas especializadas em casos de uso ou dados específicos, com novos surgindo a cada mês.

  
  

• Mais dados e mais bancos de dados levaram a uma maior complexidade de software . Escolher o banco de dados certo para sua carga de trabalho de software não é mais fácil. Em vez disso, os desenvolvedores são forçados a montar arquiteturas complexas que podem incluir: um banco de dados relacional (pela sua confiabilidade), um banco de dados não relacional (pela sua escalabilidade), um data warehouse (pela sua capacidade de servir análise), um armazenamento de objetos ( pela sua capacidade de arquivar dados antigos de forma barata). Essa arquitetura pode até ter componentes mais especializados, como uma série temporal ou um banco de dados vetorial.

  
  

• Mais complexidade significa menos tempo para construir. Arquiteturas complexas são mais frágeis, exigem lógica de aplicação mais complexa, oferecem menos tempo para desenvolvimento e retardam o desenvolvimento. A complexidade não é um benefício, mas um custo real.

À medida que a computação se tornou mais onipresente, nossa realidade tornou-se mais interligada com a computação. Trouxemos a computação para o nosso mundo e nós mesmos para o seu mundo. Não somos mais apenas nossas identidades offline, mas um híbrido do que fazemos offline e online.

Os desenvolvedores de software são a vanguarda da humanidade nesta nova realidade. Somos nós que construímos o software que molda esta nova realidade.

Mas os desenvolvedores agora estão inundados com dados e se afogando na complexidade do banco de dados.

Isso significa que os desenvolvedores – em vez de moldar o futuro – estão gastando cada vez mais tempo gerenciando o encanamento.

Como chegamos aqui?

Parte 1: Ondas de computação em cascata

A computação ubíqua levou a dados onipresentes. Isto não aconteceu da noite para o dia, mas em ondas em cascata ao longo de várias décadas:

• Mainframes (1950+)
• Computadores pessoais (1970+)
• Internet (década de 1990+)
• Móvel (anos 2000+)
• Computação em nuvem (anos 2000+)
• Internet das Coisas (anos 2010+)

A cada onda, os computadores tornaram-se menores, mais poderosos e mais onipresentes. Cada onda também se baseou na anterior: os computadores pessoais são mainframes menores; a Internet é uma rede de computadores conectados; os smartphones são computadores ainda menores conectados à Internet; a computação em nuvem democratizou o acesso aos recursos computacionais; a Internet das Coisas são componentes de smartphones reconstruídos como parte de outras coisas físicas conectadas à nuvem.

Mas nas últimas duas décadas, os avanços da computação não ocorreram apenas no mundo físico, mas também no digital, refletindo a nossa realidade híbrida:

• Redes sociais (2000+)
• Blockchains (anos 2010+)
• IA generativa (2020+)

A cada nova onda de computação, obtemos novas fontes de informação sobre a nossa realidade híbrida: exaustão digital humana, dados de máquinas, dados de negócios e dados sintéticos. As ondas futuras criarão ainda mais dados. Todos estes dados alimentam novas ondas, a mais recente das quais é a IA Generativa, que por sua vez molda ainda mais a nossa realidade.

As ondas de computação não são isoladas, mas em cascata como dominós. O que começou como um fluxo de dados logo se tornou uma inundação de dados. E então a inundação de dados levou à criação de cada vez mais bases de dados.

Parte 2: Crescimento incremental do banco de dados

Todas essas novas fontes de dados exigiram novos locais para armazená-los – ou bancos de dados.

Os mainframes começaram com o Armazenamento de dados integrado (1964) e mais tarde Sistema R (1974), o primeiro banco de dados SQL. Os computadores pessoais fomentaram o surgimento dos primeiros bancos de dados comerciais: Oráculo (1977), inspirado no Sistema R; DB2 (1983); e servidor SQL (1989), a resposta da Microsoft à Oracle.

O poder colaborativo da Internet permitiu o surgimento de software de código aberto, incluindo os primeiros bancos de dados de código aberto: MySQL (1995), PostgreSQL (1996). Os smartphones levaram à proliferação de SQLite (inicialmente criado em 2000).

A Internet também criou uma enorme quantidade de dados, o que levou aos primeiros bancos de dados não relacionais, ou NoSQL: Hadoop (2006); Cassandra (2008); MongoDB (2009). Alguns chamaram isso de era do “Big Data”.

Parte 3: Crescimento explosivo do banco de dados

Por volta de 2010, começamos a atingir um ponto de ruptura. Até então, os aplicativos de software dependiam principalmente de um único banco de dados – por exemplo, Oracle, MySQL, PostgreSQL – e a escolha era relativamente fácil.

Mas o “Big Data” continuou a crescer: a Internet das Coisas levou ao aumento dos dados mecânicos; o uso de smartphones começou a crescer exponencialmente graças ao iPhone e ao Android, levando a uma exaustão digital ainda maior; a computação em nuvem democratizou o acesso à computação e ao armazenamento, amplificando essas tendências. Recentemente, a IA generativa agravou este problema com a criação de dados vetoriais.

À medida que o volume de dados recolhidos crescia, assistimos ao surgimento de bases de dados especializadas: Neo4j para dados gráficos (2007), Redis para um armazenamento básico de valores-chave (2009), InfluxoDB para dados de séries temporais (2013), ClickHouse para análises de alta escala (2016), Pinecone para dados vetoriais (2019) e muitos, muitos mais.

Há vinte anos, havia talvez cinco opções viáveis de banco de dados. Hoje, existem várias centenas , a maioria deles especializada em casos de uso específicos, com novos surgindo a cada mês. Embora os bancos de dados anteriores prometam versatilidade geral, esses especializados oferecem compensações específicas, que podem ou não fazer sentido dependendo do seu caso de uso.

Parte 4: Mais bancos de dados, mais problemas

Confrontados com esta inundação e com bases de dados especializadas com uma variedade de compromissos, os programadores não tiveram outra escolha senão montar arquitecturas complexas.

Essas arquiteturas normalmente incluem um banco de dados relacional (para confiabilidade), um banco de dados não relacional (para escalabilidade), um data warehouse (para análise de dados), um armazenamento de objetos (para arquivamento barato) e componentes ainda mais especializados, como uma série temporal. ou banco de dados vetorial para esses casos de uso.

Mas mais complexidade significa menos tempo para construir. Arquiteturas complexas são mais frágeis, exigem lógica de aplicação mais complexa, oferecem menos tempo para desenvolvimento e retardam o desenvolvimento.

Isso significa que, em vez de construir o futuro, os desenvolvedores de software gastam muito tempo na manutenção do encanamento. É aqui que estamos hoje.

Há um caminho melhor.

O retorno do PostgreSQL

É aqui que nossa história dá uma reviravolta. Nosso herói, em vez de ser um banco de dados novinho em folha, é um velho robusto, com um nome que apenas um desenvolvedor principal poderia adorar: PostgreSQL.

No início, o PostgreSQL estava distante em segundo lugar, atrás do MySQL. O MySQL era mais fácil de usar, tinha uma empresa por trás dele e um nome que qualquer um poderia pronunciar facilmente. Mas então o MySQL foi adquirido pela Sun Microsystems (2008), que foi então adquirida pela Oracle (2009). E os desenvolvedores de software, que viam o MySQL como o salvador gratuito da dispendiosa ditadura da Oracle, começaram a reconsiderar o que usar.

Ao mesmo tempo, uma comunidade distribuída de desenvolvedores, patrocinada por um punhado de pequenas empresas independentes, estava lentamente tornando o PostgreSQL cada vez melhor. Eles adicionaram silenciosamente recursos poderosos, como pesquisa de texto completo (2008), funções de janela (2009) e suporte JSON (2012). Eles também tornaram o banco de dados mais sólido, por meio de recursos como replicação de streaming, hot standby, atualização no local (2010), replicação lógica (2017) e corrigindo diligentemente bugs e suavizando arestas.

PostgreSQL agora é uma plataforma

Um dos recursos de maior impacto adicionados ao PostgreSQL durante esse período foi a capacidade de suportar extensões: módulos de software que adicionam funcionalidade ao PostgreSQL (2011). As extensões permitiram que ainda mais desenvolvedores adicionassem funcionalidades ao PostgreSQL de forma independente, rápida e com coordenação mínima.

Graças às extensões, o PostgreSQL começou a se tornar mais do que apenas um ótimo banco de dados relacional. Graças ao PostGIS, tornou-se um grande banco de dados geoespacial; graças ao TimescaleDB, tornou-se um excelente banco de dados de séries temporais; hstore, um armazenamento de valores-chave; AGE, um banco de dados gráfico; pgvector, um banco de dados vetorial. PostgreSQL se tornou uma plataforma.

Agora, os desenvolvedores podem usar o PostgreSQL por sua confiabilidade, escalabilidade (substituindo bancos de dados não relacionais), análise de dados (substituindo data warehouses) e muito mais.

E quanto ao Big Data?

Neste ponto, o leitor inteligente deve perguntar: “E quanto ao big data?”. Essa é uma pergunta justa. Historicamente, “big data” (por exemplo, centenas de terabytes ou mesmo petabytes) — e as consultas analíticas relacionadas — têm sido uma má opção para um banco de dados como o PostgreSQL, que não é dimensionado horizontalmente por conta própria.

Isso também está mudando. Em novembro passado, lançamos “ armazenamento em camadas ”, que classifica automaticamente seus dados entre disco e armazenamento de objetos (S3), criando efetivamente a capacidade de ter uma tabela infinita.

Portanto, embora o “Big Data” tenha sido historicamente uma área de fraqueza do PostgreSQL, em breve nenhuma carga de trabalho será grande demais.

PostgreSQL é a resposta. PostgreSQL é como nos libertamos e construímos o futuro.

Liberte-se, construa o futuro, adote o PostgreSQL

Em vez de mexer com vários sistemas de banco de dados diferentes, cada um com suas peculiaridades e linguagens de consulta, podemos contar com o banco de dados mais versátil e, possivelmente, mais confiável do mundo: o PostgreSQL. Podemos gastar menos tempo no encanamento e mais tempo na construção do futuro.

E o PostgreSQL está cada vez melhor. A comunidade PostgreSQL continua a melhorar o núcleo. Existem muito mais empresas contribuindo para o PostgreSQL hoje, incluindo os hiperescaladores.

O ecossistema PostgreSQL atual ( Fonte )

Existem também empresas mais inovadoras e independentes construídas em torno do núcleo para tornar a experiência do PostgreSQL melhor: Supabase (2020) está transformando o PostgreSQL em uma alternativa viável ao Firebase para desenvolvedores web e móveis; Néon (2021) e Xata (2022) estão ampliando o PostgreSQL para zero para cargas de trabalho intermitentes sem servidor; Tembo (2022) está fornecendo pilhas prontas para uso para vários casos de uso; Nilo (2023) está facilitando o PostgreSQL para aplicações SaaS; e muitos mais.

E, claro, há nós, Escala de tempo (2017).

A escala de tempo começou como “PostgreSQL para séries temporais”

A história da escala de tempo provavelmente soará um pouco familiar: estávamos resolvendo alguns problemas difíceis de dados de sensores para clientes de IoT e estávamos nos afogando em dados. Para acompanhar, construímos uma pilha complexa que incluía pelo menos dois sistemas de banco de dados diferentes (um dos quais era um banco de dados de série temporal).

Um dia, chegamos ao nosso limite. Em nossa IU, queríamos filtrar os dispositivos por device_type e tempo de atividade. Esta deveria ter sido uma simples junção SQL. Mas como estávamos usando dois bancos de dados diferentes, foi necessário escrever código cola em nosso aplicativo entre nossos dois bancos de dados. Levaríamos semanas e todo um sprint de engenharia para fazer a mudança.

Então, um de nossos engenheiros teve uma ideia maluca: por que não construímos um banco de dados de série temporal diretamente no PostgreSQL? Dessa forma, teríamos apenas um banco de dados para todos os nossos dados e estaríamos livres para enviar software com mais rapidez. Então nós construímos e isso tornou nossas vidas muito mais fáceis. Então contamos aos nossos amigos e eles quiseram experimentar. E percebemos que isso era algo que precisávamos compartilhar com o mundo.

Então, abrimos o código-fonte de nossa extensão de série temporal, TimescaleDB, e anunciou isso para o mundo em 4 de abril de 2017. Naquela época, as startups baseadas em PostgreSQL eram bastante raras. Fomos um dos primeiros.

Nos sete anos seguintes, investimos pesadamente na extensão e em nosso serviço de nuvem PostgreSQL, oferecendo uma experiência de desenvolvedor PostgreSQL cada vez melhor para séries temporais e análises: consultas 350x mais rápidas, inserções 44% maiores via hipertabelas (auto-tabelas). tabelas de particionamento); tempos de resposta em milissegundos para consultas comuns por meio de agregações contínuas (visualizações materializadas em tempo real); Mais de 90% de economia nos custos de armazenamento por meio da compactação colunar nativa; armazenamento de objetos infinito e de baixo custo por meio de armazenamento em camadas; e mais.

Escala de tempo expandida além das séries temporais

Foi aí que começamos, nos dados de séries temporais, e também é por isso que somos mais conhecidos.

Mas no ano passado começamos a expandir.

Vetor de escala de tempo

Nós lançamos Vetor de escala de tempo (“PostgreSQL++ para aplicações de IA”), o que torna o PostgreSQL um banco de dados vetorial ainda melhor. O Timescale Vector pode ser dimensionado para mais de 100 milhões de vetores, baseado no pgvector com desempenho ainda melhor. Empresas e equipes inovadoras já estão usando o Timescale Vector na produção em grande escala, incluindo OpenSauced , uma plataforma de insights de eventos do GitHub, com mais de 100 milhões de vetores; VieRally , uma plataforma de previsão de viralidade social, com mais de 100 milhões de vetores; e Leitor de mercado , uma plataforma de insights financeiros, com mais de 30 milhões de vetores.

PopSQL

Recentemente, também adquirimos o PopSQL para construir e oferecer a melhor UI PostgreSQL. PopSQL é o editor SQL para colaboração em equipe, com preenchimento automático, exploração de esquema, controle de versão e visualização. Centenas de milhares de desenvolvedores e analistas de dados usaram PopSQL para trabalhar com seus dados, seja em PostgreSQL, Timescale ou outras fontes de dados como Redshift, Snowflake, BigQuery, MySQL, SQL Server e muito mais.

PopSQL é o editor SQL para colaboração em equipe

Percepções

Também lançamos “ Insights”, o maior esforço de dogfooding que já empreendemos , que rastreia cada consulta ao banco de dados para ajudar os desenvolvedores a monitorar e otimizar o desempenho do banco de dados. O Insights supera diversas limitações do pg_stat_statements (a extensão oficial para ver estatísticas do seu banco de dados). A escala tem sido enorme e é uma prova da capacidade do nosso produto (e da equipe): mais de um trilhão de consultas normalizadas (ou seja, consultas cujos valores de parâmetros foram substituídos por espaços reservados) foram coletadas, armazenadas e analisadas, com mais de 10 bilhões de novos consultas ingeridas todos os dias.

A escala de tempo agora é “PostgreSQL tornado poderoso”

Hoje, o Timescale é PostgreSQL tornado poderoso - em qualquer escala. Agora resolvemos problemas concretos de dados — que ninguém mais faz — não apenas em séries temporais, mas em IA, energia, jogos, dados de máquinas, veículos elétricos, espaço, finanças, vídeo, áudio, web3 e muito mais.

Acreditamos que os desenvolvedores deveriam usar o PostgreSQL para tudo e estamos melhorando o PostgreSQL para que eles possam fazer isso.

Os clientes usam o Timescale não apenas para dados de séries temporais, mas também para dados vetoriais e dados relacionais gerais. Eles usam escala de tempo para poder usar o PostgreSQL para tudo. Você também pode: comece aqui gratuitamente .

Coda: Yoda?

A nossa realidade humana, tanto física como virtual, offline e online, está repleta de dados. Como diria Yoda, os dados nos cercam, nos prendem. Esta realidade é cada vez mais governada por software, escrito por desenvolvedores de software, por nós.

Vale a pena apreciar o quão notável isso é. Não faz muito tempo, em 2002, quando eu era estudante de graduação no MIT, o mundo havia perdido a fé no software. Estávamos nos recuperando do colapso da bolha pontocom. As principais publicações de negócios proclamaram que “ Não importa .” Naquela época, era mais fácil para um desenvolvedor de software conseguir um bom emprego em finanças do que em tecnologia – que foi o que muitos dos meus colegas do MIT fizeram, inclusive eu.

Mas hoje, especialmente agora neste mundo de IA generativa, somos nós que moldamos o futuro. Nós somos os futuros construtores. Deveríamos estar nos beliscando.

Tudo está se tornando um computador. Isto tem sido em grande parte positivo: os nossos carros são mais seguros, as nossas casas são mais confortáveis e as nossas fábricas e explorações agrícolas são mais produtivas. Temos acesso instantâneo a mais informações do que nunca. Estamos mais conectados uns com os outros. Às vezes, isso nos tornou mais saudáveis e felizes.

Mas não sempre. Assim como a força, a computação tem um lado claro e um lado negro. Tem havido evidências crescentes de que os telemóveis e as redes sociais estão a contribuir diretamente para uma epidemia global de doenças mentais em adolescentes . Ainda estamos nos debatendo com as implicações IA e biologia sintética . Ao abraçarmos o nosso poder maior, devemos reconhecer que ele vem acompanhado de responsabilidade.

Tornámo-nos administradores de dois recursos valiosos que afetam a forma como o futuro é construído: o nosso tempo e a nossa energia.

Podemos optar por gastar esses recursos no gerenciamento do encanamento ou adotar o PostgreSQL para tudo e construir o futuro certo.

Acho que você sabe onde estamos.

Obrigado por ler. #Postgres4Life

( Fonte )

Esta postagem foi escrita por Ajay Kulkarni .