Short answer: within a single database, the secondary will apply changes in the same commit/LSN order as the primary, but a readable secondary can lag—so your query might not see the most recent commits yet. There’s no cross-database ordering guarantee.

Synchronous commit: a primary commit isn’t acknowledged until the log block is hardened on the synchronous secondary. This preserves commit order, but the secondary still has to redo those log records before they’re visible to reads, so you can be milliseconds–seconds behind.

Asynchronous commit: the secondary can lag arbitrarily; visibility is eventually consistent, but the redo still follows LSN order.

Readable secondaries use snapshot isolation, so any single query sees a transactionally consistent point-in-time view up to the last redone LSN; it won’t see “reordered” data, just possibly older data.

Parallel redo (newer versions) replays independent transactions concurrently but preserves required dependencies/ordering; waits occur if one record must be redone before another.

If you absolutely require up-to-the-latest, strictly ordered visibility for consumers, read from the primary (or gate reads on the secondary until it has redone to the LSN/commit time you require).