Isn't a database supposed to return rows in a consistent order?

No — SQL tables represent unordered sets by definition. A database is free to return rows in whatever order is convenient (often related to physical storage or the query plan it picked), and that order can change between runs, especially after inserts, updates, vacuums, or just a different query plan being chosen.

Why did it seem consistent before, then suddenly wasn't?

Small tables often happen to return rows in insertion order by coincidence, because the query planner doesn't bother reordering when there's nothing to gain. As a table grows or gets touched by writes/maintenance, that coincidental stability can disappear with no code change on your end at all.

Is this the AI's fault?

Partly — a query with LIMIT and no ORDER BY is a common thing to write without thinking, because it usually happens to work. The fix is a one-line addition to the query, and worth calling out explicitly if you notice the AI omitting it.

Does adding ORDER BY always fully fix it?

It fixes the ordering, but only if the ORDER BY column has unique values for every row you care about. If you sort by a date and multiple rows share the exact same timestamp, ties among those rows can still be arbitrary — add a unique tiebreaker column (like id) as a secondary sort key.

Is this different from the AI just being non-deterministic itself?

Yes — model output can vary between runs for its own reasons (how it phrases things, which tool it picks), but a database returning different rows for the identical SQL text is a separate, purely mechanical issue that has nothing to do with the AI's reasoning.

AI Database Gives Different Answers Each Time | Why

You ask "show me the 10 most recent signups." You ask again five minutes later, same words, same data — and the list is different. Not wrong, exactly, just... not the same 10 rows, with no error and no obvious reason why.

This usually isn't the AI being flaky. It's a missing ORDER BY on a query that has a LIMIT, and it's one of the more counterintuitive things about SQL for anyone who hasn't hit it before.

Tables are sets, not lists

A relational database table doesn't have an inherent order. Conceptually it's a set of rows, and unless a query explicitly asks for an order (ORDER BY), the database is free to return rows in whatever sequence is convenient for it at that moment — often tied to how the query planner decided to execute things, or the physical order data happens to sit in on disk.

SELECT * FROM signups LIMIT 10 without an ORDER BY says "give me any 10 rows," not "give me the 10 most recent." If the AI wrote that query intending "most recent" but forgot the sort, the database isn't malfunctioning when it hands back a different 10 rows next time — it's doing exactly what was asked, which just wasn't quite what was meant.

Why it feels newly broken even though nothing changed

Small, mostly-static tables often happen to return rows in something like insertion order, simply because the query planner has no reason to do anything fancier. That coincidental stability creates a false sense that the query is sorted, right up until:

The table grows past some size where the planner picks a different execution strategy
Rows get updated, deleted, or the table gets vacuumed/reorganized
The exact same query just gets planned slightly differently on a given run

None of those require any change to your prompt, your AI client, or your gateway. The query was always missing its ORDER BY — the table was just quiet enough, for a while, that it didn't matter.

The fix

Anywhere a question implies an order — "most recent," "top 10," "highest value," "first 5" — the query needs an explicit ORDER BY matching that intent, and the LIMIT should come after it:

SELECT * FROM signups
ORDER BY created_at DESC
LIMIT 10

If you're not writing the SQL yourself, the useful move is naming the intent clearly in the question — "the 10 most recently created signups, newest first" — which gives the AI an explicit ordering to translate into ORDER BY, rather than leaving "recent" as something it has to infer belongs in the query at all.

The tiebreaker case that still bites you

Even with an ORDER BY, ties can reintroduce the same problem on a smaller scale. If ten rows share the exact same created_at timestamp (bulk imports and seed data do this constantly), the order among those ten is still unspecified, and can still shift between runs. Add a secondary sort key that's guaranteed unique — typically the primary key — to fully pin it down:

ORDER BY created_at DESC, id DESC
LIMIT 10

How to tell this apart from an actually-wrong answer

This is specifically about which rows you get shifting, with the right number of rows and no error — different from a JOIN inflating the total count, and different from a business-definition trap that gives a consistently wrong number every time. If two runs of "top 10" return 10 different-but-plausible rows rather than a wrong count or an error, missing ORDER BY is the first thing to check.

Read-only MCP gateway: mcpserver.design.

Related reading: