Tipos de datos: PostgreSQL contra SQL Server

1. Qué es

Si vienes de PostgreSQL y te toca trabajar en SQL Server, vas a escribir consultas que funcionan en los dos motores, no dan ningún error y devuelven números distintos.

Este es el informe más sencillo posible: stock medio y precio medio por categoría, sobre la misma Northwind cargada en los dos motores.

SELECT category_id,
       avg(units_in_stock)          AS stock_medio,
       CAST(avg(unit_price) AS int) AS precio_entero
FROM products
GROUP BY category_id
ORDER BY category_id;

Misma consulta, mismos datos, ningún error. El stock medio pierde los decimales en 6 de las 8 categorías y el precio sale distinto en 4. Dos comportamientos lo explican, y los dos se ven en este tema:

1. En SQL Server, el promedio de enteros es un entero: avg corta los decimales.
2. En SQL Server, convertir a int corta los decimales: no redondea.

Todas las salidas de este tema se ejecutaron en PostgreSQL 17 (Neon) y en Azure SQL Database.

2. Equivalencias de tipos

3. Ejemplos lado a lado

3.1 Convertir a entero: uno redondea, el otro corta

SELECT CAST(3.7 AS int), CAST(2.5 AS int), CAST(-3.7 AS int);

PostgreSQL redondea; SQL Server trunca: tira los decimales sin mirarlos. Con float coinciden, pero por motivos distintos: PostgreSQL redondea al par y SQL Server corta.

Es la diferencia que más dinero mueve, porque no avisa. Si una consulta convierte precios a entero, en SQL Server cada línea pierde hasta casi una unidad, siempre hacia abajo.

Cómo escribirlo para que dé lo mismo en los dos: redondea primero y convierte después.

CAST(ROUND(avg(unit_price), 0) AS int)

En SQL Server eso devuelve 38, 23, 25, 29, 20, 54, 32, 21, igual que PostgreSQL.

3.2 decimal sin (p,s): todos los decimales o ninguno

SELECT CAST('2.4445' AS decimal);

En PostgreSQL, CAST(x AS numeric) es la conversión más segura que hay. En SQL Server es la que más destruye. Lo que en tipos-de-datos-en-postgresql (sección 3.2: convertir texto a número conserva todos los decimales) es una buena práctica, en SQL Server es un error.

Regla para SQL Server: decimal siempre con (p,s).

decimal(10) sin escala sí coincide en los dos: escala 0, así que CAST(2.7 AS decimal(10)) da 3 en ambos.

3.3 ROUND no es la misma función

El desbordamiento es el más traicionero. 999.99 es un decimal(5,2), y SQL Server intenta guardar el resultado en ese mismo tipo. 1000.00 necesita 6 cifras y no cabe:

Msg 8115, Level 16, State 2
Arithmetic overflow error converting expression to data type numeric.

Pasa solo cuando el redondeo añade una cifra a la parte entera, así que puede funcionar meses y romperse con un dato nuevo. La salida es darle sitio antes de redondear: ROUND(CAST(999.99 AS decimal(7,2)), 0) → 1000.00.

3.4 Texto a número

Para revisar valores sin que falle la consulta, cada motor tiene su herramienta, y no hacen lo mismo:

-- SQL Server
SELECT x AS texto, TRY_CAST(x AS decimal(18,4)) AS convertido
FROM (VALUES ('2.7'), ('2.4445'), ('2,7834'), ('N/A'), (''), ('$2.70')) t(x);

texto   convertido
2.7     2.7000
2.4445  2.4445
2,7834  NULL
N/A     NULL
        NULL
$2.70   NULL

Cuidado con TRY_CAST: convierte los datos malos en NULL sin avisar, y sum ignora los NULL. Si lo usas en una carga, cuenta cuántos NULL salieron antes de dar el total por bueno.

3.5 División y promedios

La división entera es igual en los dos. El promedio no. En PostgreSQL, avg de enteros devuelve numeric; en SQL Server devuelve un entero, así que corta los decimales. Es la causa de la columna stock_medio de la sección 1.

Cómo escribirlo para que dé lo mismo: convierte antes de promediar.

avg(CAST(units_in_stock AS decimal(10,2)))

En SQL Server devuelve 46.583333, 42.250000, 29.692307…. Los 6 decimales son cosa de SQL Server; la parte importante, que no se pierda el promedio, ya coincide.

3.6 Texto

Tres notas:

• Mayúsculas: que 'ABC' = 'abc' dé iguales depende de la collation (las reglas de comparación de texto) de la base. La nuestra en Azure es SQL_Latin1_General_CP1_CI_AS, donde CI = case insensitive. Es la habitual en SQL Server, así que un WHERE que en PostgreSQL filtra, en SQL Server puede devolver filas de más.
• varchar sin longitud no da error en SQL Server: recorta sin avisar, a 30 caracteres en un CAST y a 1 en una variable. En PostgreSQL varchar sin longitud no tiene tope.
• Concatenar con NULL da NULL en los dos. concat() trata el NULL como texto vacío en los dos.

3.7 Booleanos: bit no es boolean

En SQL Server, bit es un número que solo vale 0 o 1. No se puede usar como condición: hay que compararlo. WHERE activo en PostgreSQL es WHERE activo = 1 en SQL Server.

3.8 Fechas

• datetime no guarda milisegundos exactos. Su precisión es de unos 3 milisegundos y redondea: .789 se convierte en .790. Por eso en SQL Server se usa datetime2.
• La fecha ambigua dio 10 de abril en los dos, pero depende de la configuración de cada servidor (idioma y formato de fecha). Escribe siempre las fechas como 'YYYY-MM-DD', que se lee igual en cualquier configuración.

3.9 Lo que sí coincide

No todo cambia. En estos casos los dos motores se comportan igual:

• Desbordamiento de enteros: 2147483647 + 1 da error en los dos (integer out of range / Arithmetic overflow error).
• División entera: 7/2 = 3.
• Coma flotante: 0.1 + 0.2 en 8 bytes da 0.30000000000000004 en los dos. En real cambia solo cómo se muestra: PostgreSQL enseña 0.3 y SQL Server 0.300000011920. Es el mismo valor aproximado.
• money: se recomienda evitarlo en los dos.

4. Errores comunes al pasar de PostgreSQL a SQL Server

1. CAST(x AS int) esperando que redondee. En SQL Server trunca. Escribe CAST(ROUND(x, 0) AS int).
2. CAST(x AS decimal) sin (p,s). En SQL Server son cero decimales.
3. avg sobre una columna entera. En SQL Server devuelve un entero. Convierte antes de promediar.
4. ROUND sin pensar en el tamaño del tipo. Puede desbordar cuando el redondeo añade una cifra.
5. varchar sin longitud. Recorta a 30 o a 1 sin avisar.
6. Comparar texto esperando que distinga mayúsculas. Con la collation habitual no las distingue.
7. Dar por bueno un total hecho con TRY_CAST. Los datos malos se volvieron NULL y no suman.
8. datetime para registrar momentos exactos. Usa datetime2.

5. Chuleta de traducción

6. Ejercicios

1. Sin ejecutarla, di qué devuelve cada motor: SELECT CAST(-3.7 AS int);
2. En SQL Server, SELECT avg(quantity) FROM order_details; devuelve 23. ¿Por qué no 23.81, y cómo lo arreglas?
3. Esta consulta funciona en SQL Server con casi todos los precios y falla con 999.99. ¿Por qué, y cómo la arreglas? sql SELECT ROUND(999.99, 0);
4. Una API manda el precio '2,7834'. Conviértelo a decimal en SQL Server sin que la consulta falle y sin perder el valor.

7. Pregunta de negocio

Te piden migrar a SQL Server el informe de la sección 1 (stock medio y precio medio entero por categoría), que hoy corre en PostgreSQL. El responsable de compras va a comparar las dos versiones. Reescríbelo para que SQL Server devuelva los mismos números y explica qué dos cambios hiciste y por qué.