¿Cuándo sacas un análisis de SQL y lo llevas a Python?

Quédate en SQL para filtrar, unir y agregar, porque el trabajo ocurre junto a los datos y escala sin moverlos. Pásate a Python cuando necesites modelado estadístico, iteración o simulación, procesamiento complejo de texto o cadenas, llamadas a una API externa o gráficos reproducibles. Una regla útil: agrega primero en SQL y luego trae el resultado más pequeño a Python para las partes en las que SQL es malo.

Mi opción por defecto es SQL para todo lo que sea filtrar, unir o agregar, porque el cálculo ocurre donde viven los datos y no estoy moviendo gigabytes por la red para hacer un group by que el almacén habría resuelto en segundos. Me paso a Python cuando la tarea es algo en lo que SQL es genuinamente malo: ajustar un modelo, ejecutar una simulación, parsear texto sucio, llamar a una API externa o producir gráficos que quiero regenerar idénticos. La regla que sigo es agregar primero. Traer el resultado resumido, quizá cincuenta mil filas, no los veinte millones en crudo, algo que he visto hacer a gente que luego se pregunta por qué se le murió el kernel. El otro factor es la mantenibilidad. Si este análisis lo va a reejecutar otra persona cada mes, SQL en un modelo con control de versiones y tests gana a un cuaderno que depende del entorno de una sola persona. Si es una exploración puntual, un cuaderno está perfectamente bien y se escribe más rápido.