Show HN: PRQL en PostgreSQL

Artículo original ↗ Discusión en Hacker News ↗

Una nueva extensión de PostgreSQL trae PRQL, un lenguaje de consultas canalizado que compila a SQL, lo que provoca un debate sobre si merece la pena adoptar DSLs de mayor nivel cuando SQL ya es ubicuo y potente. Quienes lo apoyan sostienen que la sintaxis funcional y componible de PRQL, su mejor potencial de autocompletado y su concisión para patrones analíticos complejos pueden mejorar la experiencia de desarrollo, especialmente para no expertos. Los escépticos responden que añade otra capa de abstracción, corre el riesgo de ocultar malentendidos de rendimiento y afronta barreras estructurales de adopción debido a las herramientas SQL existentes, la formación y las diferencias entre bases de datos.

Qué es PRQL y cómo funciona

  • PRQL se presenta como un lenguaje de consultas de mayor nivel y más regular que compila a SQL.
  • No es un ORM y no añade capacidades más allá de SQL; en gran medida es azúcar sintáctico con un estilo funcional / de canalización.
  • La extensión de Postgres está construida sobre pgrx y actualmente solo admite Mac/Linux porque pgrx no tiene soporte para Windows.

Motivaciones: DX, legibilidad, autocompletado

  • Sus defensores ponen el énfasis en la experiencia de desarrollo: expresar consultas analíticas más rápido, pensar de forma más funcional y usar una sintaxis canalizada “from-first”.
  • El autocompletado y la comprobación de tipos son puntos de venta clave; el orden SELECT-antes-de-FROM de SQL se considera incómodo para las herramientas.
  • Algunos lo ven como una forma más clara de pensar en transformaciones/álgebra relacional, especialmente para análisis complejos y EDA.

Escepticismo: SQL basta / costes de abstracción

  • Muchos sostienen que SQL es rico, ubicuo, está bien documentado y se soporta en todas partes; añadir otra capa aumenta la complejidad, el coste de aprendizaje y el potencial de confusión.
  • Algunos sienten que PRQL no resuelve la parte más difícil de SQL: pensar en conjuntos/términos relacionales. Principalmente ordena la sintaxis.
  • Preocupa que otra abstracción oculte implicaciones de rendimiento, especialmente en torno a las elecciones de join/filter/order.

Debate de ejemplo: “Longest Track Per Album”

  • Un debate central: ¿es PRQL materialmente más simple para consultas “top N por grupo”?
  • El hilo muestra varias soluciones SQL (DISTINCT ON específico de Postgres, funciones de ventana, QUALIFY, subconsultas) y señala que este patrón no es trivial pero sí bien conocido.
  • Algunos admiten que no pueden escribir de memoria el SQL canónico; otros dicen que cualquier usuario moderadamente experimentado de SQL puede hacerlo.

Componibilidad, depuración y herramientas

  • Algunos critican la falta de componibilidad de SQL; otros responden que CTE, vistas y funciones ya proporcionan composición.
  • La depurabilidad de procedimientos/funciones almacenados se considera ampliamente dolorosa.
  • Hay discusión sobre inlining de funciones, volatilidad (STABLE/IMMUTABLE) y comportamiento sorprendente del planner en Postgres.

Adopción y preocupaciones del ecosistema

  • Las organizaciones suelen priorizar la fiabilidad y el conocimiento compartido por encima de mejoras incrementales de sintaxis.
  • Los LLM que generan SQL reducen el dolor del SQL verboso y pueden disminuir el incentivo para adoptar capas tipo PRQL.
  • Se cuestiona la agnosticidad de bases de datos; muchos argumentan que afinar para un motor específico (por ejemplo, Postgres, Oracle) importa más.

DSLs relacionados y direcciones futuras

  • Se hacen comparaciones con Ecto, EdgeQL, jq, awk, Kusto, Malloy y otros esfuerzos de DSL/semántica sobre SQL.
  • Algunos ven a Postgres como un anfitrión prometedor para múltiples DSL integrados mediante extensiones.

Meta de HN: estilo y UX

  • Un subhilo aparte explica que el texto gris de HN para publicaciones de texto y comentarios con votos negativos es una desatención intencional, además de notas sobre nombres de usuario en verde y umbrales de votos negativos.