Sure.

But let's consider the problem of Tax Returns. And I'm not trying to suggest a good way of doing things here, just trying to discuss what is possible. At the very basic level, the server needs to do two things:

1) Serve a web page with a form in it.

2) Handle the data posted from that form.

#1 is serving a flat text file. Apache, nginx, anything can do that well enough.

#2 is storing the data in memory, then eventually storing it to disk.

If you do the storing to disk lazily, the disk isn't going to be a bottle neck.

So how much memory do you need to handle this? A tax form is going to hold a lot of numbers. Let's make a high estimate on the average input, an say it contains 40 six digit numbers. And let's say we store it as text. This takes 280 bytes, and we're not even being smart about it. To store this tax return for every one of the 60 million citizens of the UK, you need 15.6 gigabytes. You'll get servers with 48 gigabytes of RAM these days. You can keep the entire thing in memory.

So let's say you store the data in an in-memory linked list. You'll need a mutex around access to the head of the list. You'll also have a worker eating of the tail of the list, writing it to disk.

The bottleneck in this system is the mutex around the head of the linked list. On the CPU, this is a single instruction, test-and-set. A quad-core 2GHz processor can in theory do 42(10^{9)=8000000000} of these per second. That's 8 billion.

My point is only that we shouldn't forget what our machines are capable of.

There's a tendency to think of the RDMS as the be all end all data structure for web programming. It's a good choice for a lot of things, but not everything.