The bigness is important because you don't usually want the text of your SQL statements to be bigger than the data that's in the database.
SELECT employees.category AS Group,
count(employees.employeeID) as "Count",
sum(salary) AS Total,
sum(salary)/count(employees.employeeID) AS Average
FROM employees
INNER JOIN remuneration
ON employees.employeeID = remuneration.employeeID
WHERE employees.departmentID IN
(SELECT departmentID FROM departments WHERE location = 'North Office')
GROUP BY employees.category
HAVING "Count" > 2
ORDER BY employees.category;
Just trying to store that string in the smaller Arduinos looks like a bad idea, let alone the program which is capable of parsing it. Now you may say that you want a limited subset of SQL, without views, subqueries, grouping, sorting and column renaming. But if your subset is that limited, what can you do that you can't easily do with just reading a file? Do you even have a CREATE TABLE command in your plan?
OK, so you only have enough power for a Due and a keyboard and an LCD screen and you like typing SQL and you don't need it to be complex, because the SQL must fit on the screen and you like scrolling through 10 results line-by-line on a small LCD?
A quick Google search finds SQLite which claims to be able to run in "as little as 100KiB heap space". That's already bigger than all the SRAM the Due has, so it's not going to work.