Un desarrollador crea con IA la CLI Terox en un par de días para consultar 128 shards de PostgreSQL a la vez

Cuando se tienen un centenar de shards de PostgreSQL, una pregunta tan sencilla como «¿En cuál está este registro?» se convierte en una odisea: localizar el host, recordar el puerto y la base de datos, abrir psql, ejecutar la consulta y pasar al siguiente. Un desarrollador backend que antes trabajaba como DBA se cansó de soportarlo. Con ayuda de la IA, creó Terox en un par de días: una CLI interactiva para clústeres distribuidos en shards.

Qué problema resuelve

En psql y pgAdmin, la unidad de trabajo es una conexión. En un sistema distribuido en shards, es todo un conjunto de conexiones. Un bucle de bash alrededor de psql sirve para una tarea puntual, pero se queda corto como herramienta de uso diario: carece de límites de concurrencia, cancelación de consultas, registro de errores por shard y protecciones frente al acceso accidental a producción.

Terox introduce entidades de nivel superior: servicio → almacenamiento → uno, varios o todos los shards. Los hosts y las bases de datos se definen mediante plantillas; por ejemplo, pgbouncer-shop-rs{p1:03}.example.net se expande en 128 direcciones. Una consulta dirigida a all se ejecuta en todos los shards, los resultados se combinan en una sola tabla con una columna shard y los errores se muestran por separado.

Cómo funciona en la práctica

El comando \find items item_id = 424242 recorre los shards, indica que el registro se encontró en shard_37 y cambia automáticamente el contexto a ese shard. No hace falta copiar el host ni adivinar dónde está.

La implementación interna está cuidada. El parámetro fanout_concurrency impide que el cliente lance consultas contra los 128 shards a la vez. El pool de conexiones de cada shard se crea bajo demanda, cada shard tiene su propio plazo límite y Ctrl+C cancela las consultas en ejecución. Las lecturas se realizan dentro de una transacción READ ONLY real de PostgreSQL, sin depender del análisis del texto SQL. La escritura debe habilitarse explícitamente con \write on y se desactiva al cambiar de contexto.

También incluye funciones específicas de diagnóstico (\activity, \blockers, \longtx, \sizes, \diff, \doctor) y un linter que detecta DELETE sin WHERE o NOT IN con valores que pueden ser NULL.

Migraciones para casos excepcionales

El autor subraya que las migraciones habituales se ejecutan junto con el despliegue. Terox está pensado para excepciones en tablas grandes y con mucha carga. Sin la opción --allowed, el comando \migrate funciona como dry-run. Admite ejecuciones canary, lotes y --resume, y una suma de comprobación impide continuar el despliegue con un archivo modificado.

No existe una transacción común a los 128 servidores, por lo que algunos shards pueden haber confirmado ya los cambios. El informe muestra explícitamente la aplicación parcial y las migraciones deben ser idempotentes. Para CREATE INDEX CONCURRENTLY y VACUUM, que no pueden envolverse en una transacción con SET LOCAL, Terox advierte de la ejecución sin protección y exige una confirmación adicional en producción.

Qué nos dice sobre el vibe coding

El proceso consistió en describir el problema, encontrar un modelo mínimo de comportamiento, obtener una implementación de la IA, comprobarla manualmente y con pruebas, y convertir cada caso límite en una nueva prueba. Así surgieron el cierre de los pools al salir, un historial sin contraseñas y las pruebas de condiciones de carrera.

La principal conclusión del autor: la IA implementa una idea equivocada con la misma rapidez y pulcritud, y lo hace en doce archivos a la vez. Por eso conviene definir primero los invariantes: no quedan conexiones abiertas al salir, PostgreSQL garantiza el acceso de solo lectura, el cambio de contexto desactiva la escritura y un fallo parcial no se presenta como un éxito. Así, la conversación con la IA se convierte en trabajo de ingeniería.

Limitaciones

El análisis estático de Terox es heurístico. Los límites de seguridad siguen dependiendo de los permisos del rol, las transacciones READ ONLY, TLS y los tiempos de espera. La herramienta no sustituye la monitorización, las copias de seguridad ni la comprensión de los planes de consulta, y tampoco corrige la arquitectura de sharding.

La conclusión práctica: si se trabaja habitualmente con decenas de bases de datos, conviene convertir ese bucle en una herramienta que recuerde las reglas. Y al trabajar con IA, empezar por los invariantes antes que por el código.