PostgreSQL por dentro, en modo visual

Si usas PostgreSQL a diario, seguramente ya sabes hacer consultas, crear índices y ajustar algunos parámetros. Pero hay una diferencia grande entre usar la base y entender qué pasa cuando una query entra, cómo se reparte en memoria y por qué a veces el disco termina siendo el cuello de botella. Ahí es donde una herramienta como PGSimCity sirve mucho más que una demo bonita.

PGSimCity, inspirado en How PostgreSQL Works, te deja ver el recorrido de una consulta como si observaras una ciudad en miniatura. No estás mirando un diagrama estático ni una lista de conceptos sueltos. Estás siguiendo el movimiento de la query, los buffers, el planner, el executor y el almacenamiento con una lógica visual que ayuda a explicar internals de PostgreSQL sin perderte en teoría.

Qué problema resuelve PGSimCity

La mayoría aprende PostgreSQL desde afuera: conectas la app, ejecutas SQL, ves resultados y, si algo falla, miras logs o EXPLAIN. Eso alcanza para operar. Pero cuando necesitas responder por qué una consulta tarda 800 ms en staging y 40 ms en local, o por qué el consumo de memoria sube cuando aumentas concurrencia, necesitas entender el sistema por dentro.

PGSimCity te ayuda justo en ese punto. No reemplaza la documentación ni las herramientas de profiling, pero sí convierte conceptos abstractos en algo que puedes seguir con la vista. Para devs que están empezando con bases de datos más serias, o para equipos que ya tienen producción y quieren explicar mejor qué está pasando, esa capa visual baja bastante la fricción.

La utilidad real no está en “ver bonito”. Está en que puedes explicar con más claridad cómo viaja una consulta por el stack de PostgreSQL. En lugar de decir “la base está lenta”, puedes decir “el planner eligió este plan, el executor leyó más páginas de las esperadas y el acceso terminó pegándole al almacenamiento”. Esa diferencia cambia la conversación técnica.

Cuándo te sirve de verdad

Te sirve si estás revisando performance, enseñando bases de datos en un equipo o preparando a alguien que viene de frameworks y no de sistemas. También sirve si ya sabes lo básico de PostgreSQL pero nunca has conectado bien la relación entre CPU, memoria compartida y disco.

Por ejemplo, si una consulta con un JOIN empieza a degradarse cuando crece la tabla, la demo te ayuda a visualizar que no todo ocurre en una sola capa. Hay planificación, ejecución, lectura de páginas, uso de buffers y, si no alcanza lo que está en memoria, acceso a almacenamiento. Eso te obliga a pensar en el flujo completo.

Y eso es útil en Latinoamérica también, donde muchas veces trabajamos con equipos pequeños y no siempre hay un DBA dedicado. Cuando tú mismo tienes que diagnosticar, una herramienta visual te da contexto rápido sin obligarte a leer 20 páginas antes de entender lo básico.

Cómo leer PostgreSQL como un sistema, no como una caja negra

PostgreSQL no es solo “una base de datos relacional”. Es un sistema con varias capas: parser, planner, executor, memoria compartida, procesos backend, WAL, buffers y almacenamiento físico. Si lo miras como caja negra, cada problema parece distinto. Si lo miras como sistema, empiezas a ver patrones.

La idea de PGSimCity es mostrar ese sistema en movimiento. La query no aparece mágicamente en un resultado final. Primero se interpreta, luego se planifica, después se ejecuta y finalmente toca memoria o disco según lo que esté disponible. Esa secuencia importa porque cada etapa puede ser la fuente del problema.

Cuando entiendes el recorrido, también entiendes mejor qué herramientas usar. EXPLAIN (ANALYZE, BUFFERS) no es solo una salida técnica más. Es una forma de confirmar qué parte del flujo está costando más. La visualización te prepara para leer ese tipo de datos con menos fricción.

Del SQL al plan de ejecución

El primer paso es el parser, que toma tu SQL y lo convierte en una estructura interna. Luego viene el planner, que decide cómo ejecutar la consulta. Aquí PostgreSQL compara alternativas: usar un índice, hacer un sequential scan, ordenar antes o después, cambiar el orden de los joins.

Ese punto es crítico porque muchas veces el error no está en la query escrita por el dev, sino en la decisión que tomó el planner con la información disponible. Si las estadísticas están desactualizadas o el volumen cambió, el plan puede ser menos eficiente de lo esperado.

Para profundizar con fuentes oficiales, vale la pena revisar la documentación de EXPLAIN en PostgreSQL: https://www.postgresql.org/docs/current/using-explain.html. Ahí ves cómo interpretar el plan y por qué no conviene adivinar.

Del plan a la ejecución real

Una vez elegido el plan, entra el executor. Aquí PostgreSQL empieza a mover datos reales. Ya no hablamos de una idea teórica de la consulta, sino de leer páginas, comparar filas, aplicar filtros y devolver resultados.

Si el plan dice que va a tocar pocas filas pero termina leyendo miles, ahí aparece el costo real. En una interfaz visual como PGSimCity eso se entiende más rápido porque ves el movimiento, no solo el output final. Para un equipo de producto o backend, esa diferencia ayuda a explicar por qué una query “simple” puede terminar siendo cara.

También entra en juego la memoria compartida, que PostgreSQL usa para coordinar trabajo entre procesos. No es memoria infinita ni magia. Tiene límites y reglas. Por eso el comportamiento cambia tanto cuando ajustas parámetros como shared_buffers o cuando la carga concurrente sube.

Memoria, buffers y por qué el disco no debería ser tu primera opción

En PostgreSQL, la memoria es parte central del rendimiento. No es solo RAM disponible en el servidor. Hay memoria compartida, memoria por proceso y estructuras internas que determinan si una consulta trabaja con datos ya cargados o si tiene que ir a disco.

La parte visual de PGSimCity ayuda mucho aquí porque te permite imaginar el tránsito entre buffers y almacenamiento. Si una página ya está en buffer cache, el acceso es más rápido. Si no está, hay que traerla desde el storage. Ese salto suele ser el que pega fuerte en latencia.

También conviene separar conceptos que a veces se mezclan en conversaciones de equipo. shared_buffers no es lo mismo que toda la RAM del sistema, y el comportamiento de work_mem no se parece al de maintenance_work_mem. Cada parámetro afecta una parte distinta del trabajo.

Qué pasa con shared_buffers

shared_buffers es una zona de memoria compartida que PostgreSQL usa para cachear páginas de datos. No significa que todo se quede ahí, pero sí que una parte importante de las lecturas puede resolverse sin tocar el disco. El tamaño ideal depende del servidor, la carga y el resto del stack.

Si lo configuras a ciegas, puedes terminar con una idea falsa de mejora. Más memoria no siempre equivale a mejor rendimiento. En algunos escenarios, aumentar demasiado un buffer sin observar el patrón real de acceso no cambia nada o incluso complica el comportamiento general del sistema.

PGSimCity te ayuda a visualizar esa idea porque muestra que la memoria es un punto de paso, no un destino final. La consulta entra, consume recursos, mueve páginas y luego sigue su camino. Ver eso de forma simple hace más fácil explicar por qué una lectura repetida suele ser más barata que la primera.

work_mem y operaciones que crecen rápido

work_mem suele ser uno de los parámetros más mal entendidos. No es memoria total para toda la base. Es memoria por operación, y eso cambia todo cuando tienes varios joins, sorts o hashes en una misma consulta.

Por ejemplo, si una consulta hace sort y hash join al mismo tiempo, cada operación puede consumir su propia cuota. Con varios usuarios conectados, el consumo total puede subir rápido. Por eso no conviene subir work_mem solo porque una query aislada se siente lenta.

La visualización ayuda a explicar este tipo de casos porque puedes asociar cada etapa con un tipo de consumo. No todo es lectura de disco. A veces el problema es que la consulta se vuelve pesada por el trabajo temporal que hace en memoria antes de devolver resultados.

Almacenamiento, páginas y el costo de salir a disco

Si la memoria es el espacio de trabajo, el almacenamiento es la fuente de verdad. PostgreSQL organiza los datos en páginas, y esas páginas se leen o escriben según lo que la consulta necesita. Cuando una operación no puede resolverse con lo que ya está en memoria, entra el acceso físico al storage.

Ese detalle importa mucho en producción. Una consulta que parece rápida con datos pequeños puede volverse lenta cuando la tabla crece porque el patrón de acceso ya no cabe cómodo en memoria. En visualizaciones como PGSimCity, ese salto se entiende mejor que en una charla abstracta sobre I/O.

También es útil para hablar de escrituras. No todo en PostgreSQL es lectura. Hay cambios que necesitan pasar por WAL, sincronización y persistencia. Si vas a explicar por qué un insert masivo o un batch de updates pega en el sistema, conviene pensar en el camino completo.

Páginas, filas y acceso físico

PostgreSQL trabaja con páginas de tamaño fijo, normalmente de 8 KB. Eso significa que no lee “la tabla” como una sola cosa, sino bloques. Las filas viven dentro de esas páginas y el motor decide cuántas necesita tocar para responder a una consulta.

Cuando haces un sequential scan, PostgreSQL recorre páginas una por una. Cuando usas un índice, puede saltar a ubicaciones más precisas, aunque eso no garantiza que el acceso sea barato si luego tiene que ir a muchas páginas distintas. La eficiencia depende del patrón de lectura.

En la práctica, esto explica por qué dos queries con el mismo WHERE pueden comportarse distinto. Si una filtra por una columna bien indexada y la otra obliga a leer demasiadas páginas, el costo cambia de forma notable. Aquí el enfoque visual sirve para no perderte en definiciones sueltas.

WAL y persistencia

El Write-Ahead Log, o WAL, es una pieza clave para entender consistencia y recuperación. Antes de que ciertos cambios se consideren seguros, PostgreSQL registra la información necesaria para poder rehacer o recuperar el estado si algo falla.

No necesitas memorizar cada detalle para aprovechar una visualización como PGSimCity, pero sí entender la idea general: escribir en PostgreSQL no es solo mover datos a una tabla. Hay un flujo de persistencia detrás que protege la integridad del sistema.

La documentación oficial del WAL es una buena referencia si quieres ir más allá: https://www.postgresql.org/docs/current/wal-intro.html. Ahí puedes contrastar la explicación visual con el comportamiento real documentado por el proyecto.

Cómo usar esta visualización para aprender y enseñar

PGSimCity no es solo útil para quien depura rendimiento. También sirve como herramienta de enseñanza. Si tienes que explicar PostgreSQL a un equipo de frontend, a alguien de producto o a devs junior, una visualización cambia la conversación porque aterriza conceptos que suelen sonar demasiado teóricos.

Una buena forma de usarlo es combinar la demo con consultas reales. No te quedes solo con mirar el flujo. Toma una query de tu proyecto, revisa el plan, identifica si el problema está en lectura, memoria o almacenamiento, y luego intenta relacionarlo con lo que ves en la visualización.

Eso convierte la herramienta en una especie de laboratorio. No sustituye el monitoreo ni el análisis con métricas, pero sí te da un mapa mental más claro. Y ese mapa vale mucho cuando tienes que decidir si el problema se arregla con índices, con parámetros, con reescritura de SQL o con otra estrategia.

Un flujo práctico para aprender

1. Elige una query real de tu aplicación, no un ejemplo inventado.
2. Ejecuta EXPLAIN (ANALYZE, BUFFERS) y guarda el resultado.
3. Identifica si el costo está en scans, joins, sorts o lecturas de páginas.
4. Compara eso con la parte visual de la demo para ubicar el recorrido.
5. Ajusta una sola variable a la vez, por ejemplo un índice o un filtro.
6. Vuelve a medir y revisa si bajaron las lecturas o el tiempo total.

Ese método evita conclusiones rápidas. En vez de asumir que “PostgreSQL está lento”, separas el problema por capas. Y eso te da conversaciones más útiles con tu equipo.

Qué no deberías esperar de la demo

No deberías esperar precisión de benchmarking. PGSimCity no reemplaza pg_stat_statements, EXPLAIN, auto_explain ni métricas de infraestructura. Su valor está en la comprensión, no en la medición fina.

Tampoco deberías usarla como excusa para ignorar la documentación. Si quieres ajustar parámetros o entender mejor el comportamiento de buffers, la fuente oficial sigue siendo la referencia principal. La demo te prepara para leer esa documentación con más contexto.

Piensa en ella como una capa pedagógica. Cuando ya entiendes el flujo, te resulta más fácil discutir con criterio si un problema viene del planner, del executor, de la memoria o del almacenamiento. Y eso, en un equipo real, ahorra tiempo.

Tabla resumen

Cierre: por qué vale la pena mirarlo con calma

Si ya usas PostgreSQL, probablemente no necesitas otra explicación genérica de qué es una base de datos relacional. Lo que sí necesitas, cuando el sistema crece, es una forma más clara de ver qué pasa adentro cuando una consulta entra, se planifica, consume memoria y termina tocando almacenamiento.

Ahí PGSimCity aporta valor. No porque sea una animación curiosa, sino porque convierte internals en algo que puedes seguir paso a paso. Para aprender, para enseñar y para diagnosticar, esa claridad te ahorra tiempo.

Si trabajas con PostgreSQL en un equipo pequeño o mediano, vale la pena usar este tipo de recurso junto con métricas reales. Así no te quedas en intuición. Pasas a entender el sistema con más precisión y con mejores argumentos técnicos.