Why SQL Rules the Data World in 2025

Por que o SQL ainda domina o mundo dos dados em 2025

Descubra a história surpreendente do SQL e entenda por que algumas tecnologias permanecem enquanto outras desaparecem no universo de TI.

Michael Schmidt 11 min

SQL está morto. Vida longa ao SQL!

Estou em Enterprise IT há 30 anos. Tempo suficiente para ver muitos hypes irem e virem, e um cemitério cheio de promessas fracassadas feitas por vendedores e consultores que prometiam um impacto tecnológico real e transformador para os negócios.

Aqui estão alguns exemplos de coisas que nos venderam como uma espécie de santo graal, mas que acabaram sendo efêmeras ou foram parar em nichos depois do seu minuto de fama.


Mas também existem os casos opostos. Tecnologias que foram declaradas mortas décadas atrás chegaram até a era da AI e continuam vivas e bem hoje.

Gráfico de tecnologias zumbis em Enterprise IT
“Zombie Tech” em Enterprise IT

A maioria das previsões de longo prazo sobre adoção de tecnologia simplesmente não se confirma.

Há muitos fatores que contribuem para isso, mas um se destaca. Temos uma tendência notória a subestimar a inércia na adoção de tecnologia, especialmente em Enterprise IT.

Isso pode ter relação parcial com a natureza humana, mas está principalmente ligado à experiência dos profissionais em ambientes de Enterprise IT. Sim, a TI precisa entregar inovação de impacto para o negócio, melhorar a competitividade e sustentar o crescimento. Mas a função central da liderança de TI é gerenciar riscos e otimizar custos no equilíbrio certo para manter tudo funcionando. Isso envolve pessoas e tecnologia e vai muito além de disponibilidade de sistemas e cibersegurança.

Como as decisões são tomadas em Enterprise IT

Para dar um exemplo simples: como CTO, ao selecionar uma linguagem de programação para um novo projeto, eu preciso olhar muito além das capacidades da linguagem em si. Outros fatores são ainda mais críticos na minha tomada de decisão. Preciso olhar para dentro da empresa e para o mercado como um todo para entender quão popular a linguagem é. Será fácil contratar desenvolvedores para essa linguagem?

Por exemplo, se eu tivesse que escolher entre JavaScript e Ruby para um novo projeto em 2025, eu verificaria rapidamente que mais de 66% dos desenvolvedores conhecem JavaScript, mas apenas 6,4% conhecem Ruby (uma possível alternativa server-side), segundo a pesquisa do StackOverflow. Em um caso assim, mesmo que Ruby fosse uma opção melhor, eu provavelmente escolheria JavaScript. Não é só porque contratar seria potencialmente mais fácil, mas também porque, com uma comunidade maior de desenvolvedores, você pode contar com um ecossistema mais completo: tooling, suporte, disponibilidade de empresas de serviços profissionais e assim por diante. Da mesma forma, ao escolher uma ferramenta de recruitment marketing, as empresas costumam priorizar plataformas com uma base de usuários robusta e forte apoio do ecossistema,
garantindo estabilidade no longo prazo e integração mais simples.

Depois eu preciso olhar para as tendências de longo prazo. Há quanto tempo essa linguagem existe? A adoção dela ainda está subindo, estabilizou ou já começou a cair? Ela continuará evoluindo para absorver novas tendências e inovações? Ainda haverá suporte disponível daqui a 5 ou 10 anos?

E é exatamente aí que a nossa história sobre SQL e sua trajetória realmente começa.

O que é SQL?

SQL é uma linguagem de programação amplamente usada, padronizada e predominantemente declarativa, com elementos procedurais, cujo objetivo é definir estruturas de dados, manipular, consultar e controlar dados. Ela se baseia em álgebra relacional e aprimorou significativamente técnicas anteriores de consulta e manipulação de dados, como o VSAM. Uma instrução é composta de cláusulas, expressões, predicados, consultas e subconsultas recursivas.

Sempre existiram extensões e dialetos específicos de fornecedores, mas o núcleo da linguagem em si está em conformidade com o padrão em todas as principais implementações. As incompatibilidades afetam tipos de dados e construções mais avançadas.

SQL não é perfeito. Ele não segue de forma consistente seus elegantes fundamentos matemáticos, não é ideal para dados hierárquicos e orientados a grafos e nunca se encaixou bem no paradigma orientado a objetos. Em geral, não se integra de forma suave com linguagens orientadas a objetos nem com linguagens procedurais (é aí que entra o Object-Relational Mapping, ou ORM). Instruções mais complexas podem se tornar difíceis de escrever e ler, e não é eficiente escrever uma lógica grande e mais complexa inteiramente em SQL ou PL/SQL. 

É por isso que, ao longo do tempo, muitas alternativas foram propostas, e várias se tornaram bastante bem-sucedidas, por exemplo linguagens de consulta para grafos e noSQL para key-value stores e dados orientados a documentos.

No entanto, a maioria das alternativas bem-sucedidas acabou se estabilizando em seu nicho e, na verdade, vemos até um recuo de algumas delas em favor do SQL nos últimos anos. Por outro lado, alguns desses conceitos, como JSON ou grafos, já foram incorporados a versões mais novas do SQL, reduzindo a necessidade de alternativas. 

SQL é antigo, mas é claramente o vencedor desta maratona.

As origens do SQL

As origens do SQL remontam ao início da década de 1970. Em 1970, Edgar F. Codd publicou A Relational Model of Data for Large Shared Data Banks, introduzindo o modelo relacional de bancos de dados.

Esse foi o nascimento do RDBMS, uma categoria totalmente nova de sistemas de TI na época, que agora, 55 anos depois, ainda está entre as 3 principais categorias globalmente (ao lado de infraestrutura de TI e sistemas ERP). A adoção de RDBMS foi impulsionada pela ascensão do ERP e a adoção do SQL caminhou lado a lado com ela. Como gêmeos, um não pode existir sem o outro.

Dois grandes protótipos de sistemas de banco de dados relacional foram criados entre 1974 e 1977. Foram eles o Ingres, desenvolvido na UC Berkeley (UCB), e o System R, criado na IBM San Jose. O Ingres utilizava uma linguagem de consulta conhecida como QUEL e levou à criação de sistemas como Ingres Corp., MS SQL Server, Sybase, PostgreSQL, Wang’s PACE e Britton-Lee. Já o System R utilizava a linguagem de consulta SEQUEL e contribuiu para o desenvolvimento de SQL/DS, DB2, Allbase, Oracle e Non-Stop SQL. 

Também foi nessa década que Relational Database Management System, ou RDBMS, se tornou um termo reconhecido.

Padronização e adoção do SQL

Depois de quase 10 anos de P&D em SQL, os anos 1980 foram a década da comercialização e da padronização dos RDBMS. Vários sistemas de banco de dados comerciais foram lançados nos anos 1980. Isso inclui Oracle V2 (1979), Sybase SQL Server (1984), IBM DB2 para mainframes (1983, sucessor do System R), IBM Informix (1985), Microsoft SQL Server 1.0 (1987) e SAP DB (1988).

Um passo importante foi a adoção do SQL como linguagem padrão de banco de dados pela ANSI e pela ISO em 1986 e 1987, respectivamente. Esse padrão passou por muitas iterações ao longo do tempo, com a revisão mais recente em 2023. 

As razões para os fornecedores aderirem à padronização incluíam a expectativa de um crescimento geral mais rápido com um padrão em um mercado em evolução; o medo de perder para concorrentes por não apoiar o padrão; a capacidade de influenciar o padrão; e os benefícios de ecossistema.

O sucesso inicial do SQL não surgiu do nada. Havia claramente uma demanda.

No entanto, o crescimento massivo só começou de fato a partir do início da década de 1990. Ele foi causado pela queda nos preços de hardware, pela ascensão das arquiteturas client-server com UNIX e PC e pela adoção do ERP. Essa também foi a década do surgimento dos bancos relacionais open source com MySQL (1995), PostgreSQL (1996) e MariaDB (1999).

A genealogia dos bancos de dados relacionais é bastante complexa – os detalhes podem ser vistos aqui.

Genealogia do gerenciamento de bancos de dados relacionais
Genealogia do gerenciamento de bancos de dados relacionais, Hasso-Plattner-Institut

Panorama atual e perspectivas

Resumindo: SQL veio para ficar. E não só isso. Está mais vivo do que nunca e continua crescendo. Esse dinossauro sobreviveu a todos os seus concorrentes modernos e os superou em popularidade.

É um exemplo perfeito de que, no longo prazo, os conceitos de technology adoption lifecycle e Gartner Hype Cycle nem sempre se aplicam. SQL entrou em seu “estágio tardio” por qualquer definição, mas está crescendo mais rápido do que nunca. Um exemplo é o Gartner Hype Cycle de 2018, em que SQL nem aparecia mais como categoria (e ainda não aparece em 2025).

Gartner Hype Cycle para Data Management 2018
Gartner Hype Cycle para Data Management, 2018

Nos últimos cinco anos, os bancos de dados SQL não apenas resistiram, como prosperaram. Na Stack Overflow Developer Survey de 2020, MySQL e PostgreSQL já estavam entre os bancos de dados mais usados no mundo. Em 2025, sua liderança só aumentou. MySQL, PostgreSQL, Microsoft SQL Server e SQLite agora formam o top 4 entre os bancos de dados usados por desenvolvedores profissionais, muito à frente de qualquer alternativa noSQL. Apesar de anos de previsões de que “SQL está morto”, os dados mostram o contrário: SQL continua sendo a espinha dorsal do software moderno e dos sistemas orientados por dados.

Gráfico de sistemas de banco de dados da Stack Overflow Developer Survey 2025
Stack Overflow Developer Survey 2025 – Sistemas de banco de dados

Por que o SQL está vivo de novo?

Aqui estão minhas quatro hipóteses sobre por que o SQL está voltando com tanta força. Fique à vontade para discordar de mim – eu realmente gostaria de ouvir sua opinião.

Por que o SQL sobreviveu ao hype?

Fundação

SQL foi uma das primeiras linguagens declarativas (em contraste com as linguagens procedurais mais comuns na época). Uma linguagem declarativa permite descrever o que você quer, em vez de como fazer. Isso é muito atraente para usuários que não estão tão familiarizados com outras linguagens de programação. É muito fácil de aprender e aplicar (pelo menos para casos de uso básicos) e, ao mesmo tempo, oferece um enorme grau de flexibilidade, o que a torna adequada para uma ampla variedade de padrões de acesso a dados, como consultas ad hoc versus acesso e manipulação transacional.

Maturidade

Obviamente, uma tecnologia desenvolvida e amadurecida por tanto tempo pode ser considerada muito estável e completa. Nenhum tomador de decisão assume um risco tecnológico ao escolher SQL. 

Adoção

Já tocamos nesse ponto na introdução. Os níveis de adoção do SQL cresceram durante muito tempo, às vezes mais devagar, às vezes mais rápido, mas hoje ele é, de longe, o player dominante como linguagem de acesso a dados. Essa posição por si só reforça ainda mais seu crescimento futuro. 

Se fizermos um breve desvio pela teoria de vantagem competitiva nos negócios, sabemos que, em mercados baseados em plataformas de dois lados, os líderes têm uma vantagem competitiva enorme. Os bancos de dados relacionais baseados em SQL compõem uma plataforma de dois lados em sentido amplo:

  • Comunidade (ou várias comunidades no caso do SQL, já que elas se organizam em torno de sistemas de banco de dados específicos) – inclui usuários de SQL, desenvolvedores e outros profissionais
  • Indústria – inclui fornecedores de sistemas, organizações de serviços profissionais, provedores de serviços cloud e outras partes. 

É aqui que entram fortes efeitos de rede. Uma comunidade maior impulsiona o crescimento do ecossistema e das capacidades dos sistemas, já que a indústria quer capitalizar o tamanho do mercado. Ao mesmo tempo, a comunidade cresce por si só, porque a escolha de uma tecnologia pelos usuários ou pelas organizações em que trabalham também é influenciada pelo tamanho da comunidade, para gerenciar risco e garantir acesso a talentos.

Esse efeito é muito forte e pode até levar plataformas a “sugar” casos de uso para os quais não foram construídas, como extensões de bancos de dados de grafos e vetores para bancos relacionais.

Evolução

Como na evolução biológica, não conseguimos prever eventos externos na evolução tecnológica. Só podemos nos adaptar a eles depois que acontecem. Não é a espécie mais forte, mais rápida ou maior que tem as melhores chances de sobrevivência no longo prazo. É aquela que melhor consegue se adaptar à mudança. O SQL de 2025 já não é o SQL de 1970. 

Ao longo do caminho, o SQL incorporou mudanças importantes, incluindo big data e sistemas distribuídos (sharding e particionamento, bancos SQL distribuídos, armazenamento colunar e analytics), integração suave com linguagens modernas de programação e AI, suporte a dados semiestruturados e não estruturados (json, tipos array, xml), adaptação à analytics em tempo real, suporte a analytics avançada e ML (por exemplo BigQuery ML e extensões do PostgreSQL), integração com pipelines de AI, processamento in-memory, execução vetorizada de consultas e ML acelerado por GPU.

O que vem a seguir para o SQL?

O SQL provou que consegue evoluir mais rápido do que as previsões sobre seu declínio. À medida que AI, busca vetorial e analytics em tempo real transformam a forma como construímos aplicações, o SQL continua se adaptando em vez de desaparecer. A próxima onda não vai substituir o SQL. Vai expandi-lo. SQL é o banco de dados de escolha para AI. Veremos integração mais profunda com processamento de dados orientado por AI, extensões nativas para vetores e cloud-native scaling que torna os bancos de dados mais dinâmicos do que nunca.

Para aqueles de nós que viram décadas de hype irem e virem, o futuro do SQL parece ao mesmo tempo familiar e novo. Ele continua sendo a linguagem dos dados, mas agora também fala a linguagem da inteligência. Eu teria muito interesse em ouvir seu feedback sobre minhas hipóteses e sobre o futuro do SQL. 

Pessoalmente, acredito que o SQL ainda é o futuro e é por isso que estamos construindo a Vela. A Vela é uma plataforma moderna de Backend-as-a-Service construída sobre Postgres. Assim, podemos mostrar como o Postgres mantém o SQL relevante para as workloads cloud e de AI de hoje.