Postgres → ClickHouse: cuándo migrar no es traición

Aparece seguido en los titulares: "migramos de Postgres a ClickHouse y mejoramos performance y escala". Y la reacción típica del que recién arranca es "entonces Postgres es peor". No. Postgres no cambió — el caso de uso cambió.

Dos herramientas, dos trabajos

Postgres es una base transaccional (OLTP): escribes y lees filas, con consistencia fuerte, para la operación del día a día. ClickHouse es analítica (OLAP): está diseñada para escanear miles de millones de filas y agregarlas rápido.

Cuando tu producto empieza a hacer analytics pesado — dashboards sobre eventos, métricas en tiempo real, reportes sobre históricos enormes — Postgres no se "rompe", pero empieza a sufrir en un trabajo para el que no fue hecho.

La señal de que llegó el momento

No migres por moda. Las señales reales:

• Queries analíticas que tardan segundos y crecen con los datos.
• Índices que ocupan más que la tabla y aún así no alcanzan.
• Un data team peleando contra la base de la app en vez de tener su propio store.

Ahí una base columnar como ClickHouse (u otra OLAP) deja de ser un lujo y pasa a ser la decisión correcta.

El error opuesto

Tan malo como quedarse con Postgres por miedo es migrar todo a ClickHouse por entusiasmo. ClickHouse es incómoda para updates frecuentes y transacciones — justo lo que Postgres hace bien. La mayoría de los sistemas maduros terminan con las dos: Postgres para la operación, una OLAP para el análisis.

El punto de Anku

"¿Qué base uso?" es la pregunta equivocada. La correcta es "¿qué trabajo tiene que hacer esta parte del sistema?". La herramienta sale de la respuesta, no al revés. Entender el trade-off entre OLTP y OLAP — y saber cuándo tener las dos — es arquitectura de backend, no configuración.