>> selecting everything without paginating but fetching just one row at a time in the application This is called an "unbuffered query". The problem usually isn

>> selecting everything without paginating but fetching just one row at a time in the application This is called an "unbuffered query". The problem usually isn't with the number of rows you're trying to read; it's about what the database must do on its end before it can know which rows to send first. ORDER BY being one example wherein, unless you have perfect indexes including the sorted column(s), the database has to generate the entire resultset before even sending the first row. That means writing potentially millions of rows' worth of information to memory or - more commonly at large sizes - to a temporary table on disk. Unbuffered queries are fairly rare in the "real world". While in theory it means you're parsing results faster and using less memory on the application side, it introduces difficulties like the fact you can't run a subsequent query until you've finished reading all rows from the original query. When an application is reading this many rows with a single query, it's usually an indication that the app is poorly written. Of course there are exceptions, though typically reserved for maintenance scripts, reporting, data migrations, etc.