Hay una operación que los sistemas reales necesitan constantemente y que ninguna de las tres instrucciones anteriores resuelve: "inserta esta fila si no existe, y actualízala si ya existe".

Sincronizar el catálogo con el fichero que envía un proveedor cada semana: unos artículos ya están dados de alta y solo cambian de precio, otros son nuevos. Registrar el stock recibido de una referencia que quizá aún no existe. Guardar la puntuación de una reseña que el cliente puede haber escrito hace meses. Dar de alta un cliente que tal vez ya se registró. En los cuatro casos, la respuesta a "¿INSERT o UPDATE?" es depende de lo que haya en la tabla, y no lo sabes hasta que miras.

La solución que todo el mundo escribe la primera vez —mirar y luego decidir— es incorrecta, y lo es de una forma que no se manifiesta en desarrollo y sí en producción. Esta lección empieza explicando por qué, y sigue con las dos herramientas que PostgreSQL ofrece para resolverlo en una sola sentencia atómica: INSERT ... ON CONFLICT, su solución propia desde la versión 9.5, y MERGE, la del estándar SQL, disponible desde PostgreSQL 15.

1. El problema: insertar o actualizar según lo que haya
2. Por qué la solución ingenua es incorrecta
3. INSERT ... ON CONFLICT: la sintaxis
4. DO NOTHING y DO UPDATE SET
5. El destino del conflicto y por qué exige una restricción única
6. La pseudotabla EXCLUDED y el patrón de acumulación
7. WHERE en el DO UPDATE: actualizar solo si algo cambia
8. RETURNING con upsert, y cómo saber si fue alta o modificación
9. MERGE: el upsert del estándar SQL
10. ON CONFLICT frente a MERGE
11. Soporte por motor
12. Tres casos de TiendaVerde
13. Errores Comunes y Consejos
14. Ejercicios
15. Conclusión

Huerta del Turia (proveedor 1) manda cada lunes un fichero con su catálogo actualizado. Esta semana trae cinco referencias:

Cuatro ya están en el catálogo (con otros precios); el quinto es nuevo. Y ni siquiera todos los que están cambian: el arroz sigue a 3,90 € y 2,10 €.

Con lo que sabes hasta ahora, tendrías que separar el fichero a mano en dos grupos y escribir un INSERT para uno y un UPDATE para el otro. Es tedioso, y con quinientas referencias es directamente inviable. Lo que necesitas es una sentencia que decida por sí sola, fila a fila.

Eso es un UPSERT: update + insert.

La primera idea de cualquiera, y la que escriben la mayoría de las aplicaciones:

Funciona perfectamente… mientras seas la única persona conectada. En cuanto hay dos procesos trabajando a la vez, aparece una condición de carrera:

Las dos sesiones miran, las dos ven que no existe, las dos deciden insertar. La primera lo consigue; la segunda revienta. Y hay una variante peor: si no hubiera restricción única, la segunda inserción tendría éxito y acabarías con dos filas duplicadas sin ningún error.

El intervalo entre el SELECT y el INSERT puede parecer minúsculo —milisegundos—, pero en un sistema que procesa miles de operaciones por minuto esa ventana se cruza constantemente. No es un caso raro: es un caso garantizado. La regla general que hay detrás:

Comprobar y luego actuar en dos sentencias separadas nunca es seguro frente a la concurrencia. Entre la comprobación y la acción, el mundo ha podido cambiar.

Las tres formas de resolverlo, de peor a mejor:

Por qué la tercera opción es segura. Cuando PostgreSQL ejecuta un INSERT ... ON CONFLICT, la comprobación y la escritura ocurren dentro de la misma operación, con el bloqueo de fila e índice adecuado: no hay ventana entre "mirar" y "actuar". El mecanismo completo —qué se bloquea, durante cuánto tiempo y qué ven las demás sesiones— es el módulo 9. Aquí basta con saber que una sentencia es atómica y dos no lo son.

Se lee literalmente: "inserta esto; si choca con la unicidad de estas columnas, no hagas nada / o haz este UPDATE en su lugar".

Empecemos por el caso que no necesita nada nuevo, porque TiendaVerde ya tiene la restricción: clientes.email es UNIQUE.

(Los tres ejemplos de este apartado se ejecutan en orden sobre la base recién recargada. Fíjate en los id: el motivo de que salgan los que salen se explica al final.)

Cero filas insertadas, cero errores. El cliente ya existía con ese email, así que la sentencia se ha limitado a no hacer nada.

Intacto: sigue en Valencia y con su fecha de registro original.

DO NOTHING es ideal para datos maestros reejecutables: semillas de desarrollo, catálogos de referencia, cargas iniciales. Convierte un script frágil en uno idempotente (05-03).

La ciudad ha pasado de Valencia a Alicante, y fecha_registro no ha cambiado: solo se actualiza lo que aparece en el SET. Es exactamente lo que queremos — la fecha de alta original de un cliente no debe reescribirse porque nos manden sus datos otra vez.

Y con un email nuevo, la misma sentencia inserta:

La misma sentencia ha insertado en un caso y actualizado en el otro, sin que tú hayas tenido que decidir nada. Eso es el upsert.

Por qué el id es 18 y no 16. TiendaVerde tiene 15 clientes y su secuencia quedó en 15 tras el setval del script. Pero un upsert que acaba en conflicto también consume un valor de la secuencia: PostgreSQL construye la fila completa —evaluando todos los DEFAULT, incluido nextval— antes de comprobar el índice único. Los dos ejemplos anteriores sobre Lucía se llevaron el 16 y el 17, y Aitor ha recibido el 18.

Es coherente con lo que viste en 05-02: las secuencias no se deshacen. Consecuencia práctica: en una tabla con upserts frecuentes, los id tienen huecos grandes y no cuentan filas. Si eso te importa, revisa el tipo: un INTEGER se agota en 2 147 483 647, y con upserts masivos eso llega antes de lo que parece. BIGINT es la respuesta habitual.

El ON CONFLICT (...) no es decorativo: le dice a PostgreSQL qué conflicto debe interceptar. Y solo puede interceptar violaciones de una restricción UNIQUE, PRIMARY KEY o de un índice único.

Hay dos formas de indicarlo:

Si indicas columnas que no están cubiertas por ninguna restricción única, falla:

Y esto es una limitación de diseño, no un capricho. Para que PostgreSQL pueda decidir atómicamente "ya existe", necesita un índice único que se lo diga sin recorrer la tabla; sin él tendría que buscar, y volveríamos a la ventana de carrera del apartado 2.

Así que para sincronizar el catálogo por nombre hay que añadir la restricción:

Funciona porque los veinte nombres del catálogo son distintos. Y de paso ilustra algo que verás a fondo en 05-06: añadir un UNIQUE crea un índice por debajo, y ese índice es lo que hace posible el upsert (las estructuras y su coste, en el módulo 8).

Ahora sí:

Precio y coste actualizados; el stock sigue en 120 porque no está en el SET. Las 60 unidades del fichero se han ignorado, que en este caso es lo correcto: son unidades enviadas, no el stock total.

EXCLUDED es la clave de todo el mecanismo. Es una pseudotabla que contiene la fila que se intentó insertar y fue rechazada por el conflicto.

Dentro del DO UPDATE SET conviven dos mundos:

Con las dos puedes escribir cualquier regla de fusión:

Ese último es el patrón de acumulación, y es probablemente el uso más valioso del upsert. Registrar la recepción de mercancía es exactamente eso: "si el producto ya está dado de alta, súmale las unidades; si no, créalo con esas unidades".

Cinco filas: cuatro acumuladas y una creada. 120+60=180, 200+100=300, 300+200=500, 60+40=100, y los garbanzos entran con sus 140 unidades y el id 21.

Fíjate en un detalle revelador: los precios de las cuatro filas actualizadas siguen siendo los antiguos (12,50 €, 3,90 €, 1,95 €, 4,95 €), porque el SET solo toca stock. Solo la fila nueva ha estrenado el precio del fichero. El upsert te deja controlar campo a campo qué se fusiona y qué se conserva.

Y el aviso obligatorio, hermano del de UPDATE ... FROM (05-03):

⚠️ EXCLUDED no acumula entre tuplas de la misma sentencia. Si el fichero trajera dos veces el mismo nombre, PostgreSQL fallaría con ON CONFLICT DO UPDATE command cannot affect row a second time. No suma las dos: se niega. Deduplica el origen antes de hacer upsert.

Ese error es en realidad una buena noticia: el motor se niega a hacer algo ambiguo en lugar de inventarse un resultado. Compáralo con UPDATE ... FROM, que en la misma situación elige una coincidencia al azar sin avisar.

El DO UPDATE admite su propio WHERE, que decide si la actualización se aplica o se descarta:

Cuatro filas en lugar de cinco. El arroz integral venía con 3,90 € y 2,10 €, exactamente lo que ya tenía, así que el WHERE ha descartado su actualización y ni siquiera aparece en el RETURNING.

Por qué merece la pena esa línea de más:

Fíjate en el uso de IS DISTINCT FROM en lugar de <>. Es directamente 04-03: si productos.coste fuera NULL, la comparación productos.coste <> EXCLUDED.coste daría UNKNOWN, el WHERE la descartaría y el coste nunca se actualizaría. IS DISTINCT FROM trata dos nulos como iguales y un nulo frente a un valor como distintos, que es lo que aquí necesitamos. Es uno de los sitios donde aquella lección se cobra la deuda.

RETURNING funciona igual que en INSERT y UPDATE: devuelve las filas afectadas, ya sean insertadas o actualizadas. Lo que no te dice de forma directa es cuál fue cuál.

Existe un truco muy extendido basado en la columna de sistema xmax (ejemplo sobre la base recién recargada):

Lucía se ha actualizado (false), Marisol se ha creado (true) — con el id 17, porque el intento fallido sobre Lucía se llevó el 16.

Cómo funciona. xmax es una columna oculta que PostgreSQL usa internamente para el control de versiones: guarda el identificador de la transacción que borró o bloqueó la fila. En una fila recién insertada vale 0; en una actualizada dentro del upsert, no.

⚠️ Úsalo con reservas. xmax es un detalle de implementación, no una interfaz documentada. Puede cambiar entre versiones, y hay situaciones (filas bloqueadas por otras transacciones, SELECT ... FOR UPDATE previos) en las que un xmax distinto de cero no significa lo que crees. Sirve perfectamente para depurar y para un informe interno; no construyas lógica de negocio crítica sobre él.

Y una limitación que sí importa: con DO NOTHING, las filas en conflicto no aparecen en el RETURNING en absoluto. Solo verás las que realmente se insertaron:

Una de las dos. Si necesitas saber también qué se ignoró, DO NOTHING no te lo va a decir.

ON CONFLICT es una extensión de PostgreSQL. El estándar SQL:2003 define para lo mismo la instrucción MERGE, que PostgreSQL incorporó en la versión 15.

La lógica es la de un JOIN: se emparejan destino y origen por la condición del ON, y para cada fila se ejecuta la primera cláusula WHEN que se cumpla.

El origen puede ser una tabla, una consulta o una lista de valores. Para el caso de TiendaVerde, lo natural es una tabla de staging con el contenido del fichero del proveedor:

Ese COPY a una tabla de staging seguido de una fusión hacia la tabla definitiva es el patrón profesional de integración de datos que anunciaba 05-02.

Y ahora el mismo caso del apartado 7, resuelto con MERGE:

Cuatro filas afectadas: tres actualizaciones (aceite, tomate y kombucha) y una inserción (garbanzos). El arroz no cumple la condición del WHEN MATCHED y, al no haber más cláusulas aplicables, se queda como está.

Fíjate en el zumo de naranja (17): es de Huerta del Turia pero no venía en el fichero, y ha quedado intacto. Ni ON CONFLICT ni este MERGE hacen nada con las filas del destino que el origen no menciona. Si el criterio de negocio fuera "lo que no está en el fichero se descataloga", harían falta dos operaciones… o una cláusula WHEN NOT MATCHED BY SOURCE, que PostgreSQL 16 todavía no tiene (llegó en la 17).

Varias condiciones y DELETE. Este MERGE sincroniza el catálogo y además descataloga lo que el proveedor manda a precio 0:

Tres reglas distintas en una sentencia, evaluadas en orden: la primera que se cumpla gana. Con ON CONFLICT esto no se puede expresar; harían falta varias sentencias.

Esa tercera limitación es contraintuitiva y conviene retenerla: la instrucción estándar es menos robusta frente a la concurrencia que la extensión propietaria, porque ON CONFLICT se apoya directamente en el índice único y MERGE no lo exige.

Cuándo usar cada uno:

• ON CONFLICT cuando el caso sea el clásico "insertar o actualizar" sobre una clave única, cuando haya concurrencia real, o cuando necesites RETURNING. Es el 90 % de los casos.
• MERGE cuando necesites varias reglas (actualizar unos, borrar otros, insertar los demás), cuando el emparejamiento no sea por una clave única, cuando el origen sea una consulta compleja, o cuando el código deba ser portable a Oracle o SQL Server.

SQLite ofrece además INSERT OR REPLACE INTO ..., que mucha gente usa creyendo que es un upsert. No lo es, y la diferencia es grave:

Aplicado a TiendaVerde sería una catástrofe silenciosa: un INSERT OR REPLACE sobre productos borraría la fila, y con ella se irían en cascada todas sus reseñas (resenas.producto_id es ON DELETE CASCADE). El "upsert" habría destruido datos de otra tabla sin mencionarla.

La regla: en SQLite usa ON CONFLICT ... DO UPDATE, nunca INSERT OR REPLACE, salvo que el borrado-y-recreación sea exactamente lo que quieres.

Resuelto en los apartados 7 y 9, de las dos formas. Requiere la restricción uq_productos_nombre para la versión con ON CONFLICT; el MERGE funcionaría igual sin ella.

Resuelto en el apartado 6 con el patrón de acumulación SET stock = productos.stock + EXCLUDED.stock. Es el caso donde el upsert brilla: una sola sentencia procesa un albarán entero, dé de alta referencias nuevas o sume a las existentes.

Una versión más completa, que además actualiza el precio de compra y anota la fecha de alta solo en las referencias nuevas:

Cuatro acumulaciones y un alta. Y observa la columna fecha_alta: las cuatro existentes conservan la suya (2025) y solo la nueva estrena la de hoy, porque fecha_alta no aparece en el SET. Esa asimetría —unos campos se fusionan y otros solo se rellenan al crear— es justo lo que hace útil el DO UPDATE frente a un REPLACE.

Fíjate también en que el origen es un SELECT, no un VALUES. INSERT ... SELECT ... ON CONFLICT combina lo de 05-02 con lo de esta lección, y es la forma habitual de procesar una tabla de staging entera.

Un cliente vuelve a valorar un producto que ya había reseñado. La regla de negocio: una reseña por cliente y producto, y la última sustituye a la anterior.

Hoy resenas no impide duplicados, así que primero hay que declarar esa regla:

Funciona porque las doce reseñas actuales tienen pares (producto_id, cliente_id) distintos. Si hubiera duplicados, el ALTER TABLE fallaría — que es exactamente lo que debe hacer.

Ahora el upsert. El cliente 6 (Pau Llorens Vidal) había puesto un 2 a la Kombucha; le han cambiado la receta y quiere subirlo a 4:

Misma fila (id 6), contenido nuevo. Y con un cliente que nunca ha reseñado ese producto, la misma sentencia crea la reseña:

El id es 14 y no 13 por lo mismo del apartado 4: el upsert anterior, que acabó en DO UPDATE, ya se había llevado el 13 de la secuencia.

Y el efecto sobre la valoración del producto:

De un 2 solitario a una media de 4,50 con dos reseñas. La Kombucha deja de ser el peor producto del catálogo.

Recuerda deshacer los ejemplos. Las dos restricciones de esta lección (uq_productos_nombre y uq_resenas_producto_cliente) no forman parte del esquema del curso. Quítalas con ALTER TABLE ... DROP CONSTRAINT ... o, más simple, recarga tiendaverde.sql. La sintaxis completa de ALTER TABLE es la próxima lección.

• Resolver el upsert con SELECT + INSERT/UPDATE. Condición de carrera garantizada bajo concurrencia. Una sentencia es atómica; dos no.
• Usar ON CONFLICT sobre columnas sin restricción única. there is no unique or exclusion constraint matching the ON CONFLICT specification. El índice único es el mecanismo, no un requisito burocrático.
• Olvidar el prefijo EXCLUDED. en el DO UPDATE. SET precio = precio es una asignación circular: la fila se queda como estaba y no da error.
• Traer el mismo valor de clave dos veces en la misma sentencia. cannot affect row a second time. Deduplica el origen antes.
• Comparar con <> en lugar de IS DISTINCT FROM en el WHERE del DO UPDATE. Con un NULL de por medio la comparación da UNKNOWN y la fila nunca se actualiza (04-03).
• Esperar que DO NOTHING te informe de lo ignorado. No aparece en el RETURNING. Si necesitas saberlo, usa DO UPDATE con WHERE.
• Construir lógica de negocio sobre xmax = 0. Es un detalle de implementación. Vale para depurar; no para facturar.
• Creer que el upsert actualiza también lo que el origen no menciona. No lo hace. Las filas del destino ausentes del fichero quedan intactas.
• Usar INSERT OR REPLACE en SQLite creyendo que es un upsert. Borra y recrea: pierde columnas, cambia el rowid y dispara las cascadas de borrado.
• Suponer que MERGE es seguro frente a la concurrencia. No lo es en PostgreSQL 16: puede fallar con clave duplicada. ON CONFLICT sí lo es.
• Consejo: para un albarán o un fichero, carga a una tabla de staging y fusiona desde ahí. COPY + INSERT ... SELECT ... ON CONFLICT (o MERGE) es el patrón profesional de integración.
• Consejo: decide campo a campo qué se fusiona. precio sí, fecha_alta no, stock acumulando. Esa granularidad es todo el valor del DO UPDATE.
• Consejo: pon siempre el WHERE ... IS DISTINCT FROM en el DO UPDATE. Menos escrituras, menos bloqueos, auditoría honesta y un RETURNING que dice la verdad.

Trabaja sobre la base recién recargada, dentro de BEGIN … ROLLBACK.

TiendaVerde recibe un fichero de altas y bajas de clientes procedente de una campaña de marketing:

Escribe una sola sentencia que dé de alta a los que no existan y actualice la ciudad de los que sí, con estas reglas:

1. fecha_registro debe ser 2026-03-02 para los nuevos y no debe modificarse en los existentes.
2. La ciudad solo debe actualizarse si realmente cambia.
3. El resultado debe indicar, por fila, si fue alta o modificación.

Después responde: ¿cuántas filas devuelve el RETURNING y por qué?

Resuelve el mismo caso del ejercicio 1 con MERGE, cargando antes los datos en una tabla temporal clientes_campana. Después compara las dos soluciones respondiendo a estas preguntas:

1. ¿Qué diferencia hay en la salida de psql?
2. ¿Cuál de las dos es segura si dos procesos ejecutan la campaña a la vez?
3. ¿Cuál escribirías si además hubiera que desactivar a los clientes que no aparecen en el fichero? ¿Se puede hacer en PostgreSQL 16?

Un compañero quiere sincronizar el catálogo y escribe esto:

Tiene tres errores distintos. Encuéntralos, explica el síntoma de cada uno y reescribe la sentencia correctamente, indicando qué tendría que estar declarado en el esquema para que funcione y qué resultado daría.

Solución 1

Cuatro filas, y no es casualidad que salgan las cuatro:

Si el fichero hubiera traído a Lucía con su ciudad actual (Valencia), el WHERE ... IS DISTINCT FROM habría descartado esa actualización y el RETURNING habría devuelto tres filas.

Las tres decisiones del enunciado:

1. fecha_registro fuera del SET. Aparece en el INSERT (para los nuevos) pero no en el DO UPDATE, así que los existentes conservan la suya: 2025-01-10 y 2025-03-21. Es el mismo principio que con fecha_alta en 12.2.
2. WHERE clientes.ciudad IS DISTINCT FROM EXCLUDED.ciudad, no <>: si algún cliente tuviera la ciudad a NULL (la columna lo admite), <> daría UNKNOWN y jamás se actualizaría.
3. (xmax = 0) AS alta_nueva, con la reserva del apartado 8: sirve para el informe de la campaña, no para lógica crítica.

Solución 2

Resultado idéntico en el contenido, con un detalle revelador en los id: aquí son 16 y 17, no 18 y 19 como con ON CONFLICT. El motivo es que MERGE solo evalúa los DEFAULT de las filas que realmente inserta, mientras que el upsert los evalúa también en las que acaban en conflicto. MERGE desperdicia menos valores de secuencia. (Con todo, no cuentes con id consecutivos en ninguno de los dos: las secuencias tienen huecos por diseño.)

Las tres respuestas:

1. La salida. MERGE 4 frente a INSERT 0 4, y sobre todo: el MERGE de PostgreSQL 16 no admite RETURNING, así que hay que consultar después para ver qué ha pasado — y esa consulta ya no puede distinguir altas de modificaciones. Es la pérdida más notable al cambiar de instrucción.

2. Concurrencia. La segura es ON CONFLICT. Si dos procesos lanzan la campaña a la vez, el MERGE puede fallar con duplicate key value violates unique constraint "clientes_email_key", porque su emparejamiento no se apoya en el índice único de la misma forma. ON CONFLICT está diseñado precisamente para ese escenario.

3. Desactivar a los ausentes. Sería el trabajo de una cláusula WHEN NOT MATCHED BY SOURCE THEN UPDATE SET ..., que PostgreSQL 16 no tiene (llegó en la 17). En la 16 hay que hacerlo en dos sentencias dentro de la misma transacción: el MERGE (o el upsert) y después un UPDATE ... WHERE email NOT IN (SELECT email FROM clientes_campana). Ojo con ese NOT IN y los nulos: 04-02 lo advirtió, y aquí clientes_campana.email es PRIMARY KEY, así que es seguro. Además, clientes no tiene columna de baja, así que en TiendaVerde la operación ni siquiera sería expresable sin un ALTER TABLE previo — próxima lección.

Solución 3

Los tres errores:

Hay un cuarto detalle que no es un error de sintaxis pero sí de criterio: SET stock = stock + EXCLUDED.stock funciona porque stock sin cualificar se resuelve a la fila existente, pero es ambiguo de leer. Escribe siempre productos.stock + EXCLUDED.stock.

Qué haría falta en el esquema. Para emparejar por nombre hace falta la restricción del apartado 5:

La versión corregida, con el origen deduplicado (nos quedamos con el último envío de la miel, el de 10,50 €, y sumamos las dos cantidades: 40 + 25 = 65):

Los dos productos existían (ids 3 y 4, de BioSierra Ibérica): la miel pasa de 9,75 € a 10,50 € y de 80 a 145 unidades (80 + 65); la pasta pasa de 2,80 € a 2,95 € y de 150 a 230 unidades (150 + 80).

Y la lección de fondo del ejercicio: de los tres errores, dos no producen ningún mensaje. El ON CONFLICT (id) habría duplicado el catálogo en silencio y el SET precio = precio habría dejado los precios sin tocar sin que nadie se enterara. Solo el tercero —el duplicado en el origen— provoca un error visible. Un upsert mal escrito falla callado mucho más a menudo que ruidosamente, y por eso hay que comprobar el RETURNING fila a fila la primera vez que se pone en producción.

El upsert resuelve la operación que faltaba:

• El problema: "inserta si no existe, actualiza si existe", omnipresente en sincronización de catálogos, recepción de mercancía, altas de cliente y valoraciones.
• La solución ingenua es incorrecta: SELECT y luego decidir abre una condición de carrera entre la comprobación y la escritura. Dos sesiones ven "no existe" y las dos insertan. Una sentencia es atómica; dos no.
• INSERT ... ON CONFLICT, con sus dos acciones: DO NOTHING (ideal para datos maestros reejecutables, INSERT 0 0 sin error) y DO UPDATE SET (el upsert propiamente dicho).
• El destino del conflicto, por columna o por ON CONSTRAINT, y por qué exige una restricción única: sin el índice, PostgreSQL no podría decidir atómicamente y volvería la ventana de carrera.
• EXCLUDED, la pseudotabla con la fila propuesta, frente a tabla.columna con la fila existente. De ahí salen todos los patrones: quedarse con el nuevo, conservar el viejo, GREATEST, y sobre todo acumular (stock = productos.stock + EXCLUDED.stock). Y su límite: el mismo valor de clave dos veces en una sentencia falla, hay que deduplicar el origen.
• WHERE en el DO UPDATE con IS DISTINCT FROM (04-03) para no escribir cuando nada cambia: menos escrituras, menos bloqueos, auditoría honesta.
• RETURNING con upsert, y el truco de xmax = 0 para distinguir alta de modificación, con sus reservas.
• MERGE, el estándar SQL:2003 disponible desde PostgreSQL 15: WHEN MATCHED / WHEN NOT MATCHED, varias condiciones evaluadas en orden y la capacidad de borrar. Con sus tres limitaciones en PostgreSQL 16: sin RETURNING, sin WHEN NOT MATCHED BY SOURCE, y no inmune a la concurrencia.
• Cuándo usar cada uno: ON CONFLICT para el caso clásico con concurrencia real; MERGE para reglas múltiples, emparejamientos sin clave única y portabilidad.
• El soporte por motor, y el aviso sobre INSERT OR REPLACE de SQLite, que borra y recrea la fila: pierde columnas, cambia el rowid y dispara las cascadas de borrado.

Con esto has cerrado el DML: sabes crear, leer, insertar, modificar, borrar y fusionar. Todo ello sobre un esquema que hasta ahora ha sido inmutable: el mismo que creaste en 05-01 y que no has vuelto a tocar. Pero los esquemas cambian. Hace falta una columna nueva, un tipo se queda corto, una restricción llega tarde, un nombre resulta ser un error. En la última lección del módulo, Modificando el esquema: ALTER TABLE y migraciones seguras, aprenderás todas las operaciones de ALTER TABLE y —lo que de verdad separa una migración inocua de una caída de producción— cuáles bloquean la tabla y cuáles no, el patrón expand/contract para cambiar un esquema sin parar el servicio, y por qué ningún cambio de estructura debería escribirse jamás a mano en una consola de producción.