PostgreSQL vs MySQL vs SQL Server para analítica

Para trabajo de analítica, PostgreSQL es la opción gratuita con más funciones, SQL Server es la elección natural en empresas que usan Microsoft y Power BI, y MySQL es una base de datos sólida y muy común en hosting que con más frecuencia es el origen de tus datos que el lugar donde los analizas. Las tres hablan SQL estándar, así que lo que aprendes sirve en todas; las diferencias aparecen en las funciones analíticas, las herramientas, las licencias y en cómo encajan con tu stack de BI.

Comparación rápida

Las ediciones, los límites y los precios cambian entre versiones, así que confirma los detalles actuales en las páginas oficiales de PostgreSQL, MySQL y Microsoft SQL Server antes de decidirte.

PostgreSQL: la navaja suiza del analista

PostgreSQL tiene fama de respetar los estándares y de ofrecer un conjunto profundo de funciones analíticas. Para BI destacan varias:

• La cláusula FILTER para agregados condicionales: count(*) filter (where status = 'returned') es más limpio que un CASE dentro de COUNT.
• DISTINCT ON para quedarte con la fila más reciente de cada cliente en una sola línea.
• Agregados de conjunto ordenado como percentile_cont(0.5) within group (order by amount) para calcular medianas.
• Vistas materializadas para guardar el resultado de una consulta pesada y refrescarlo cuando quieras.
• Extensiones como PostGIS para análisis geográfico y complementos para series de tiempo.
• Soporte JSONB, muy útil cuando los datos de una app llegan en JSON.

Muchos warehouses en la nube y herramientas toman prestada la sintaxis de PostgreSQL, y dbt tiene un adaptador maduro para PostgreSQL, así que es un excelente lugar para aprender. Si estás armando proyectos de SQL para tu portafolio, PostgreSQL es una gran opción por defecto.

MySQL: está en todas partes, pero es menos analítico

MySQL mueve una gran parte de los sitios y aplicaciones web, incluidas muchas instalaciones de WordPress y tiendas en línea. Como analista, muchas veces vas a leer desde MySQL en lugar de construir la analítica dentro de él. Desde la versión 8.0 soporta funciones de ventana y CTE, lo que cerró la brecha más grande, pero quedan algunas limitaciones para análisis pesado:

• No tiene FULL OUTER JOIN; tienes que combinar un LEFT JOIN y un RIGHT JOIN con UNION.
• No tiene un agregado integrado para la mediana ni para percentiles.
• Ofrece menos opciones para escaneos analíticos grandes que los motores con almacenamiento columnar.

Aun así, MySQL funciona muy bien para reportes pequeños y medianos. Si la tienda en línea o el CRM de tu empresa corre en MySQL, un patrón común es replicarlo a un warehouse y ejecutar allí los reportes pesados. MariaDB, un fork comunitario de MySQL, se comporta de forma parecida en la mayoría de las consultas de un analista.

SQL Server: la casa del BI de Microsoft

SQL Server usa T-SQL y se integra estrechamente con el resto del ecosistema de Microsoft: Power BI, Excel, Azure, Microsoft Fabric y herramientas como SQL Server Management Studio. Sus fortalezas para analítica incluyen:

• Índices columnstore que comprimen los datos y aceleran las agregaciones grandes, ideales para tablas de hechos.
• T-SQL muy completo, con funciones de ventana, PIVOT y funciones más nuevas como DATETRUNC y GREATEST en versiones recientes.
• Herramientas conocidas para empresas que ya usan Windows, Active Directory y Microsoft 365.
• Un camino fácil hacia Azure SQL y Fabric, que comparten gran parte del mismo T-SQL.

Microsoft ofrece una edición Developer gratuita para desarrollo y pruebas (no para producción) y una edición Express gratuita con límites de recursos. Las licencias de producción Standard y Enterprise representan un costo importante, así que revisa siempre la información de licencias vigente de Microsoft. Para conectarlo a tus reportes, lee SQL para Power BI.

La misma pregunta en tres dialectos

Este es el mismo reporte en cada base de datos: ingresos mensuales de los 5 mejores meses. Observa cómo cambian el truncado de fechas y el límite de filas.

PostgreSQL

select date_trunc('month', order_date)::date as month,
       sum(amount) as revenue
from orders
group by 1
order by revenue desc
limit 5;

MySQL

select date_format(order_date, '%Y-%m-01') as month,
       sum(amount) as revenue
from orders
group by month
order by revenue desc
limit 5;

SQL Server

select top 5
       datefromparts(year(order_date), month(order_date), 1) as month,
       sum(amount) as revenue
from orders
group by datefromparts(year(order_date), month(order_date), 1)
order by revenue desc;

La lógica es idéntica; solo cambia la sintaxis de fechas y de límites. Por eso las habilidades de SQL se trasladan con facilidad de un motor a otro.

Fundamentos de rendimiento que aplican a las tres

Uses el motor que uses, los mismos hábitos mantienen rápidas las consultas analíticas:

• Indexa las columnas por las que filtras y unes, como fechas y llaves foráneas. En SQL Server, considera un índice columnstore agrupado en las tablas de hechos grandes.
• Selecciona solo las columnas que necesitas en lugar de SELECT *, sobre todo cuando Power BI importa el resultado.
• Lee el plan de ejecución con EXPLAIN (PostgreSQL y MySQL) o con el plan de ejecución real en SQL Server Management Studio para ver dónde se va el tiempo.
• Preagrega los reportes pesados en tablas resumen o vistas materializadas que se refrescan según un horario, en vez de recalcular millones de filas con cada clic en el dashboard.
• Evita correr reportes grandes sobre una base de producción ocupada; usa una réplica de lectura o una base de reportes separada siempre que puedas.

Cómo elegir según tu stack de BI

Cómo se conecta cada una a las herramientas de BI

Las tres se conectan a Power BI, Tableau, Looker Studio y la mayoría de las herramientas de BI, pero la experiencia cambia. SQL Server tiene el soporte nativo más profundo en las herramientas de Microsoft. PostgreSQL se conecta bien con casi todas, aunque algunos conectores necesitan instalar un driver primero. Los conectores de MySQL también suelen requerir un driver aparte. Revisa la documentación del conector de tu herramienta para saber si solo permite importar datos o también consultas en vivo con tu base de datos.

A mayor escala, muchos equipos mueven la analítica a un data warehouse en la nube y dejan estas bases para las aplicaciones. La comparación de data warehouses en la nube explica cuándo conviene dar ese paso.

¿Cuál deberías elegir?

• Si estás aprendiendo SQL desde cero: PostgreSQL. Es gratis, estándar y está lleno de funciones analíticas.
• Si tu empresa trabaja con Microsoft: SQL Server (o Azure SQL / Fabric) para la experiencia más fluida con Power BI.
• Si tus datos viven en una web o una app: probablemente sea MySQL; aprende a consultarlo y luego decide dónde analizar.
• Si eres un pequeño negocio con poco presupuesto: PostgreSQL, instalado por ti o mediante un servicio administrado en la nube.

Próximos pasos

Instala PostgreSQL y SQL Server Developer (o ejecútalos en Docker), carga el mismo dataset de ejemplo en ambos y reescribe cinco de tus consultas favoritas en cada dialecto. Anota cada diferencia de sintaxis en una hoja de referencia. Después conecta Power BI a los dos y compara la experiencia de conexión. Al terminar ese ejercicio te sentirás cómodo en cualquiera de las tres y podrás explicar sus ventajas y desventajas en una entrevista.

Mira: lecciones en video

▶

▶

Preguntas frecuentes