Was a nice surprise to open the page and see my wife's photo headlining it!<p>I agree that there are some things SQL databases aren't suitable for, but it's very often the case that something that's too slow in SQL stops being too slow once you tweak the right thing. When that's possible (as I said, that's very often but not always), actually doing the tweak is much simpler than reimplementing the subset of a DBMS that you need, but learning enough about the DBMS to figure out what to tweak may not be.<p>Here are some things I haven't found a good SQL solution to:<p>* Inverted indices. Fortunately, this is a big enough use that a lot of SQL databases these days have a full-text search extension of some kind slapped on the side.<p>* Graph data. This is kind of the same problem; the issue is that you can store your RDF or whatever in a table with <i>subject</i>, <i>verb</i>, and <i>object</i> columns, but not only are N-way self-joins an awkward way to query it, the SQL optimizer isn't smart enough to figure out that some verbs are orders of magnitude more common than others, and it should plan accordingly. (Not in PostgreSQL or SQLite, anyway, and I don't think in MySQL either.)<p>* Data of many terabytes. Use Hadoop.