PGSimCity llama la atención al instante: convierte los componentes internos de PostgreSQL en una ciudad 3D que se abre en el navegador. Clientes, backends, shared buffers, WAL, checkpoints, autovacuum, replicación y bloat dejan de ser cajas en un diagrama y pasan a moverse en pantalla.

Internals de PostgreSQL mostrados como una ciudad open source en el navegador

Eso no significa que haya que creerle a ciegas. El README advierte que es un prototipo, que puede contener errores en la simulación y en las explicaciones, y que es un modelo, no un emulador. No corre código fuente de PostgreSQL en el navegador; los números están escalados para que una persona pueda observarlos. Esa honestidad es parte de su valor.

La demo vive en GitHub Pages y el repositorio NikolayS/PGSimCity está bajo Apache-2.0. El package metadata ya marca versión 0.6.0, aunque el README todavía habla como un prototipo v0.1. Más que una contradicción grave, eso muestra un proyecto moviéndose rápido tras su llegada a Hacker News.

Al revisar el repo tenía 62 stars, 2 forks y 2 issues abiertos. Los commits del 27 de julio ya añadían mejoras como seguir una consulta por la ciudad y hacer más visibles las salidas de cada modo. También lo probé localmente: npm install, npm run typecheck y npm run build pasaron con Node 20.20.2. El stack es pequeño: three.js r185, TypeScript, Vite y three como única dependencia de runtime.

Lo mejor de PGSimCity es que ofrece una primera imagen mental. Muchos backend developers escriben SQL todos los días sin ver qué hacen sus cargas a WAL, buffers o autovacuum. Un modelo visual puede preparar el terreno antes de leer la documentación. No sustituye a los docs ni a un DBA, pero hace que las piezas dejen de flotar en abstracto.

El hilo de Hacker News tenía 411 points y 41 comments. La reacción fue positiva, pero con crítica útil: demasiado ruido de interfaz, controles de cámara mejorables, falta de narrativa y necesidad de un recorrido más lento de una query. Esa última idea apunta a una evolución clara: no solo una ciudad bonita, sino una clase interactiva que sabe qué está intentando aprender el usuario.

El gran riesgo es la precisión. Una visualización interactiva convence más que un diagrama estático. Si enseña mal, el error se recuerda como experiencia. Por eso la invitación del autor a que expertos de PostgreSQL abran issues o pull requests no es decorativa. Es lo que separa una demo brillante de una herramienta educativa confiable.

El ángulo de AI-assisted development también importa, pero no debería comerse la historia. El autor dijo en HN que el trabajo nació de un prompt y de curiosidad por Opus 5, con ayuda intensa de modelos. Lo importante es lo que pase después: los coding agents pueden producir prototipos ambiciosos; la revisión abierta decide si se vuelven conocimiento útil.

Vale la pena probarlo si usas PostgreSQL, enseñas bases de datos o mantienes herramientas de infraestructura. Conviene tener cuidado si buscas una autoridad para ajustar producción. Para eso siguen mandando la documentación oficial, las métricas, los logs y la experiencia de Postgres.

La señal más amplia va más allá de PostgreSQL. Kubernetes, compiladores, motores de almacenamiento, CPUs y runtimes tienen el mismo problema: los diagramas simples se quedan cortos y el código fuente abruma. Los modelos explorables pueden ocupar ese espacio, siempre que se revisen como software y no se consuman como infografías bonitas.