Comparativa

Teradata vs PostgreSQL y MySQL: diferencias clave

Si ya sabés SQL en PostgreSQL o MySQL, no partís de cero para aprender Teradata: el SELECT, el JOIN y el GROUP BY son, en esencia, los mismos. Lo que cambia de fondo es cómo cada motor organiza los datos por dentro y qué implica eso para el rendimiento y el diseño de tablas. Esta comparación no busca decir que uno es "mejor" que otro — son herramientas para problemas distintos.

Arquitectura: monolítico vs MPP

PostgreSQL y MySQL son motores de arquitectura monolítica (o cliente-servidor tradicional): en su forma más común corren como un único proceso (o un conjunto de procesos coordinados) sobre una única máquina, con un único disco y un único CPU compartido por todas las consultas. Se puede escalar verticalmente (más RAM, más CPU) o mediante réplicas de lectura, pero el motor en sí no reparte una tabla entre múltiples nodos de forma nativa.

Teradata, en cambio, nació para ser MPP (Massively Parallel Processing): cada tabla se reparte físicamente entre decenas o cientos de AMPs, cada uno con su propio disco y CPU, coordinados por un PE (Parsing Engine) que distribuye el trabajo y junta los resultados. Para más detalle, ver cómo funciona la arquitectura MPP de Teradata.

Tabla comparativa

Aspecto	Teradata	PostgreSQL / MySQL
Arquitectura	MPP, shared-nothing (AMPs)	Monolítica / cliente-servidor
Distribución de filas	Por hash del Primary Index	No aplica por defecto (particionado opcional)
Escalado	Horizontal (agregar AMPs/nodos)	Principalmente vertical, o réplicas de lectura
Filtrar sobre funciones de ventana	`QUALIFY` (nativo)	Subconsulta o CTE envolvente
Caso de uso típico	Data warehousing, analítica sobre volúmenes muy grandes	Aplicaciones transaccionales (OLTP), analítica de tamaño moderado
Costo / operación	Licenciamiento empresarial, infraestructura dedicada	Open source, bajo costo de entrada

Lo que ya sabés se traslada directo

La sintaxis base de SQL —SELECT, WHERE, GROUP BY, HAVING, ORDER BY, los distintos tipos de JOIN, subconsultas y CTEs con WITH— es prácticamente idéntica entre los tres motores, porque todos siguen (con variaciones) el estándar SQL. Por ejemplo, esta consulta corre igual en Teradata, PostgreSQL o MySQL:

SELECT department, ROUND(AVG(salary), 2) AS salario_medio, COUNT(*) AS n_empleados
FROM employees
GROUP BY department
HAVING COUNT(*) > 3
ORDER BY salario_medio DESC;

Lo específico de Teradata

1. El Primary Index no es solo una clave

En PostgreSQL o MySQL definís una PRIMARY KEY pensando en unicidad e integridad. En Teradata, el Primary Index (PI) además decide en qué AMP física vive cada fila:

CREATE TABLE orders (
    order_id    INTEGER,
    customer_id INTEGER,
    order_date  DATE
)
PRIMARY INDEX (customer_id);

Elegir mal el PI (por ejemplo, una columna con pocos valores distintos) puede generar skew: AMPs sobrecargados mientras otros están ociosos. Es una decisión de diseño que no tiene equivalente directo en un motor monolítico.

2. QUALIFY: filtrar sobre una función de ventana sin subconsulta

Esta es probablemente la diferencia sintáctica más útil del día a día. En PostgreSQL o MySQL, para quedarte con "el pedido más reciente de cada cliente" tenés que envolver la función de ventana en una subconsulta o CTE:

-- PostgreSQL / MySQL: hace falta un CTE + filtro externo
WITH ranked AS (
  SELECT o.*, ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY order_date DESC) AS rn
  FROM orders o
)
SELECT * FROM ranked WHERE rn = 1;

En Teradata, QUALIFY te permite filtrar directamente sobre el resultado de la función de ventana, sin la subconsulta extra:

-- Teradata: QUALIFY filtra sobre la ventana en la misma consulta
SELECT o.*,
       ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY order_date DESC) AS rn
FROM orders o
QUALIFY ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY order_date DESC) = 1;

Profundizamos esto con más ejemplos en QUALIFY y funciones de ventana en Teradata.

3. Tipos de datos y funciones propias

Teradata tiene tipos y funciones propias que no siempre coinciden 1 a 1 con PostgreSQL o MySQL (por ejemplo, formas específicas de manejar fechas, casteos implícitos más permisivos entre texto y fecha en comparaciones BETWEEN, y utilidades como SEL como alias histórico de SELECT). No son barreras grandes, pero conviene tenerlas presentes al migrar consultas entre motores.

¿Cuándo conviene cada uno?

Teradata tiene sentido cuando el volumen de datos es realmente grande (cientos de millones o miles de millones de filas), las cargas son mayormente analíticas, y la organización ya invierte en infraestructura de data warehouse dedicada.
PostgreSQL o MySQL son la elección natural para aplicaciones transaccionales (OLTP), volúmenes moderados, o cuando el costo y la simplicidad operativa pesan más que la escala masiva.
En la práctica, muchas empresas usan ambos: un motor transaccional para la aplicación y Teradata (u otro MPP) como warehouse analítico alimentado por ese sistema transaccional.

Si ya sabés SQL, el salto es corto

La curva de aprendizaje real está en entender la arquitectura MPP y las particularidades como QUALIFY y el Primary Index — no en reaprender SQL desde cero. El dojo está pensado justamente para eso: parte de fundamentos y en pocos niveles llega a las funciones de ventana y al diseño físico específico de Teradata.

Practicá las diferencias reales con ejercicios interactivos. Dojo completo por 5 USD.

Probar demo