Show HN: PRQL no PostgreSQL
Uma nova extensão do PostgreSQL traz o PRQL, uma linguagem de consulta em pipeline que compila para SQL, provocando debate sobre se DSLs de nível mais alto valem a adoção quando o SQL já é onipresente e poderoso. Os defensores argumentam que a sintaxe funcional e composável do PRQL, o melhor potencial de autocompletar e a concisão para padrões analíticos complexos podem melhorar a experiência do desenvolvedor, especialmente para não especialistas. Os céticos respondem que isso adiciona outra camada de abstração, arrisca mal-entendidos de desempenho e enfrenta barreiras estruturais de adoção devido às ferramentas de SQL existentes, ao treinamento e às diferenças entre bancos de dados.
O que é PRQL e como funciona
- PRQL é apresentado como uma linguagem de consulta de nível mais alto e mais regular que compila para SQL.
- Não é um ORM e não adiciona capacidades além do SQL; é em grande parte açúcar sintático com um estilo funcional / em pipeline.
- A extensão para Postgres é construída sobre
pgrxe atualmente só suporta Mac/Linux porquepgrxnão tem suporte para Windows.
Motivações: DX, legibilidade, autocomplete
- Os defensores enfatizam a experiência do desenvolvedor: expressão mais rápida de consultas analíticas, pensamento mais funcional e sintaxe em pipeline “from-first”.
- Autocomplete e verificação de tipos são pontos de venda importantes; a ordenação SELECT antes de FROM do SQL é vista como estranha para ferramentas.
- Alguns veem isso como uma forma mais clara de pensar em transformações/álgebra relacional, especialmente para análises complexas e EDA.
Ceticismo: SQL é suficiente / custos de abstração
- Muitos argumentam que SQL é rico, onipresente, bem documentado e suportado em todo lugar; adicionar outra camada aumenta a complexidade, o custo de treinamento e o potencial de confusão.
- Alguns acham que PRQL não corrige a parte mais difícil do SQL: pensar em conjuntos/termos relacionais. Ele principalmente organiza a sintaxe.
- Há preocupação de que outra abstração possa ocultar implicações de desempenho, especialmente em torno de escolhas de join/filter/order.
Debate de exemplo: “Longest Track Per Album”
- Um debate central: PRQL é materialmente mais simples para consultas de “top N por grupo”?
- A discussão mostra várias soluções em SQL (o
DISTINCT ONespecífico do Postgres, window functions,QUALIFY, subconsultas) e observa que esse padrão não é trivial, mas é bem conhecido. - Alguns admitem que não conseguem escrever o SQL canônico de memória; outros dizem que qualquer usuário de SQL com experiência moderada consegue.
Composabilidade, depuração e ferramentas
- Alguns criticam a falta de composabilidade do SQL; outros respondem que CTEs, views e funções já fornecem composição.
- A depuração de stored procedures/funções é amplamente vista como dolorosa.
- Há discussão sobre inlining de funções, volatilidade (
STABLE/IMMUTABLE) e comportamento surpreendente do planner no Postgres.
Adoção e preocupações com o ecossistema
- Organizações frequentemente priorizam confiabilidade e conhecimento compartilhado em vez de melhorias incrementais de sintaxe.
- LLMs que geram SQL reduzem a dor do SQL verboso e podem diminuir o incentivo para adotar camadas como PRQL.
- A agnosticidade em relação ao banco de dados é questionada; muitos argumentam que ajustar para um mecanismo específico (por exemplo, Postgres, Oracle) importa mais.
DSLs relacionados e direções futuras
- São feitas comparações com Ecto, EdgeQL, jq, awk, Kusto, Malloy e outros esforços de DSL/semântica sobre SQL.
- Alguns veem o Postgres como um host promissor para múltiplas DSLs embutidas via extensões.
HN Meta: estilo e UX
- Um subthread separado explica o texto cinza do HN para posts de texto e comentários com downvotes como um de-emphasis intencional, além de observações sobre usernames verdes e limiares de downvote.