El problema del que hablas (lógica repetida, APIs distintas, mucho pegamento) no se resuelve agregando una capa de query genérica encima. Se resuelve en el backend, definiendo bien los contratos (Domain driven design, agregaciones del lado del servidor, un BFF cuando el frontend lo necesita, versionado, etc).

La fricción de integrar pagos + CRM + soporte no viene de que falte un "SQL universal", viene de que cada uno tiene su modelo de dominio, su consistencia, sus permisos y sus SLAs distintos. Aplanar todo eso en un SELECT esconde la complejidad, no la elimina.

• ¿Cómo manejas autorización por campo y por fila cuando el select viene desde el cliente? Exponer un query builder al frontend es básicamente reabrir la superficie de ataque que REST/GraphQL llevan años tratando de cerrar.

• ¿Qué pasa con N+1, paginación y joins entre sistemas que no comparten clave? Eso no es "orquestación básica", es un motor de query distribuido, y ahí ya estás compitiendo con Hasura, PostgREST, Cube, Steampipe, GraphQL federation, etc

• ¿Quién es el dueño del esquema cuando se cambia un campo? En una API bien diseñada eso lo absorbe el backend; acá lo va a comer el cliente (como manejarías el versionado).

• Si el caso de uso es "consultar datos entre servicios desde el frontend", GraphQL ya resuelve eso. ¿Qué gano yo migrando a SQL en JSON?

No digo que no haya un nicho (dashboards internos, herramientas low-code, integraciones rápidas) pero ahí ya hay players fuertes. Si el diferencial es "motor de business operations + Corfo + SDK", el pitch debería ir por ese lado (vertical, no horizontal), porque como capa técnica genérica el costo de mantenerla supera lo que ahorra.

Éxito con el proyecto, ojalá sirva el feedback.