The relational model defines a relation's body as an unordered set of tuples over a heading of named attributes. Why is neither row order nor column position part of a relation, and what goes wrong in production when application code assumes rows come back in the order they were stored?

## Why the model refuses to define order A relation has a heading and a body, and both are sets. Because a set has no order, three familiar notions simply do not exist in the model: - there is no first, last or n-th tuple; - there is no column 1 or column 3, only attributes addressed by name; - there is no identity for a tuple beyond its values, which is exactly why keys have to be declared rather than assumed. This is a deliberate omission, not an oversight. By withholding order from the logical value, the model frees every implementation to store and retrieve data however it likes. Anything the model guarantees is a promise the engine must keep forever; anything it withholds is room the engine can use to go faster. ## What the engine does with that freedom In a running system the physical arrangement of rows is in constant motion: - an update may not fit in place, so the row is written elsewhere and the original slot freed; - space from deleted rows is reused by later inserts, so new data can appear physically 'before' old data; - background maintenance - reorganisation, compaction, defragmentation, table rewrites during schema changes - relocates rows wholesale; - the optimiser may satisfy the same query by a sequential scan today and an index traversal tomorrow, purely because statistics or data volume changed, and the two produce entirely different orders; - parallel execution splits a scan across workers whose output interleaves nondeterministically; - hash-based joins and aggregations emit rows in hash-bucket order, effectively arbitrary and sensitive to memory settings and spilling. None of these is a bug. All of them are permitted precisely because the model never promised order. ## How the assumption fails in production The symptoms are recognisable, and they are why this is a senior-level question. **Intermittent, deploy-free breakage.** A report that always listed the newest entry first starts listing something else after a bulk load. Nobody changed the code. The plan changed, or the table was rewritten. **Pagination that skips and repeats.** If pages are cut out of a result whose order is not total, rows can appear on two pages or on none. This also happens with an ordering that is specified but not unique: ties may break differently between executions, so the boundary between pages shifts. **Wrong 'first' or 'latest' rows.** Taking one row from an unordered result to represent 'the current record' returns an arbitrary member of the set. It is right most of the time by luck, which is worse than being wrong reliably, because the failures are rare and data-dependent. **Positional coupling to attributes.** Consumers that read result columns by index, or that depend on the expansion order of a wildcard select, break when an attribute is added or the table is rewritten. The model's name-addressed attributes are the reason position was never safe to depend on. ## What to do instead Make ordering explicit in the query and make it **total**: order by attributes that genuinely encode the sequence you mean, and append a unique tiebreaker so no two tuples compare equal. If sequence matters to the business - the order lines were entered, the version history of a record - it must be an attribute you store, not something inferred from physical placement. A monotonically increasing surrogate key is an approximation only, and a weak one: values can be skipped, and concurrent transactions commit out of allocation order, so a higher key does not reliably mean 'later'. A timestamp needs a tiebreaker of its own. For stable paging, prefer continuing from the last seen key under a fixed total ordering rather than counting positions into the result, since positional offsets assume a stable arrangement between requests that no engine promises. And reference attributes by name everywhere, in queries and in result handling. ## The framing that lands in an interview Say it as a contract: a relation is a set, so ordering is not part of the data - it is something a query produces on request. Anything your code believes about order that the query did not state is an accidental dependency on today's physical layout, and physical layout is exactly what the engine reserves the right to change.