Cuando una consulta SQL omite la cláusula ORDER BY, el estándar no define un orden concreto: cada motor decide. En la práctica, confiar en ese orden implícito para paginar resultados con LIMIT y OFFSET es una estrategia frágil que puede romperse con operaciones rutinarias como inserciones, borrados, actualizaciones o un VACUUM.
En PostgreSQL, una consulta SELECT sin ORDER BY tiende a devolver las filas en el orden de inserción original, pero esa apariencia no es una garantía. Tras un DELETE seguido de un INSERT, el orden cambia; tras un UPDATE —que internamente equivale a un DELETE más un INSERT— la fila modificada se reubica al final. El comportamiento puede verse alterado además por VACUUM, por los índices utilizados o por otras operaciones internas del motor.
En MySQL, con un esquema análogo, la consulta sin ORDER BY devuelve los registros ordenados por la clave primaria, no por la inserción. Este orden se mantiene estable tras borrar y reinsertar filas, y también tras un UPDATE. La diferencia es relevante para diseñar paginación determinista.
La conclusión operativa es clara: para paginar de forma fiable y reproducible entre páginas sucesivas, los desarrolladores deben incluir siempre una cláusula ORDER BY explícita basada en columnas con valores únicos (por ejemplo, la clave primaria o una columna timestamp con tiebreaker). El orden implícito del motor solo sirve como observación de comportamiento interno y nunca como contrato de aplicación.