Looking at the list from an SQL Server RDBMS view:

Search: I agree that there are products that are much better than the built in FT-engine in SQL Server, but if your FT needs are simple (simple stemming and ranking) then the built in is good enough. I have played a little bit with Apache Solr and it does have a LOT mure functionality (better stemming, faceting, ranking, typing correction, suggestions etc) than SQL Server FT, but it takes a lot more time to configure (xml files, xml files, xml files). Then there is the issue of keeping an external FT engine in sync with the RDBMS.

Times series/high frequency logging: Definately not a job for a RDBMS. Sure you can get decent perfomance for the actual logging for a small number of tags, but when it comes to reading this data and performing calculations on them, performance goes down the drain. A product like OSIsoft PI can easily store 10, even 100 of thousands of values a second on reasonable hardware. It is designed for this purpose only, and it does it well.

Storing large amouns of unstructede data: Agreed. Not something a RDBMS can do well.

ACL: This is actually a bit funny. We implemented ACL (groups and accounts synced from AD with FIM every five minutes) on our internally developed document management system (running SQL Server 2005) about nine months ago.

The requirements: A user should be able to grant or deny permissions (read, write, read ACL, write ACL) to multiple groups or users on any case, document or file (not a real file, just our internal representation of a file). A document belong to a case, and a file to a revision on a document. Permissions should be inherited from case to document to file if the "inherit permissions" on the document or file is set. Both direct and indirect group memberships should work. The hardest part: Performance from a user view must not be affected, and the ACL inheritance from case to document to file should be done instantly.

An ACL change on a case can propagate to as much as 50.000 documents and a few houndred thousand files. How can this be done without affecting performance (again, from a user view). We didn't want the user to wait until the ACL had propagated to all objects that inherit from this object. Have you ever tried making a change to a root folder with thousands of subfolders and files in Windows? Takes forever.

The solution: We decided to use Service Broker. When ACL on a case is modified we simply send a message with the case id (or document id) to a Service Broker service. The message is processed and document ACLs to be updated are split in to batches of 100 docs. When a batch of document ACLs are modified more messages are send and processed to update ACL on the files. This solved the user performance problem and the "instantly" requirement was good enough. Propagating ACL to 50.000 documents and files only take a few seconds.