Like many startups, they seem to have gone with the simplest solution that worked for the size of the data and the nature of their initial queries at the time; and then were surprised when the solution started to bog down once the size of the data grew beyond their estimates. This happens quite often in small businesses that still use spreadsheets to manage their data instead of a relational database. Once your data reaches a certain size or the scope of your queries expands significantly, the old solution may no longer work properly.
When I was developing my own database engine, I found it really hard to find reliable benchmarks for other systems. Each benchmark can be affected by a hundred different factors like configuration settings, indexes, or query plans. Like this blogger, I had to run a bunch of different kinds of queries using a variety of data sets against other DBs like Postgres, MySQL, and SQL Server before I could determine that my own solution was faster in most instances. I tried to make the competition as fast as possible by creating indexes and tweaking settings. Even then, I had to wonder if I was missing some important setting in each of those other DBs that made my benchmark tests 'unfair'.