> it's very simple data. Mainly a series of messages, displayed in chronological order. That's one of the most straightforward possible things to optimize.

When a company grows and add features that customers need, the data model has to grow with it. Queries necessarily become more complex.

I used to work at a big video sharing site. I wasn't there in the beginning, but I imagine the initial profile pages had code like

    SELECT * FROM user_videos WHERE user_id = ?

So then the simple query became

    SELECT * FROM user_videos WHERE user_id = ? AND privacy = ?

And then the query suddenly became much more convoluted. We started loading all of a users' videos in memory, then in-memory filtering, returning only the videos the viewer had access to (slow for users with thousands of videos).

Then some users came along with 30,000 videos and we had to abandon the in-memory filtering because we were getting OOMs, so we developed a hybrid system that could run queries either in-memory or in the DB depending on volume.

This is a trivial example (there are much more painful examples of data model bloat) but it illustrates the point: if you think it should be easy, you probably have an innacurate mental model of what needs to happen behind the scenes.