Esta pergunta exige uma resposta muito ampla a ser respondida em todos os aspectos. Existem muito bem certas especificações que podem tornar um sistema superior a outro para um caso de uso especial, mas eu quero cobrir o básico aqui.

Vou lidar inteiramente com o Solr como um exemplo para vários mecanismos de busca que funcionam mais ou menos da mesma maneira.

Quero começar com alguns fatos concretos:

• 
  Você não pode confiar no Solr/Lucene como um banco de dados seguro. Há uma lista de fatos, mas eles consistem principalmente em opções de recuperação ausentes, falta de transações ácidas, possíveis complicações etc. Se você decidir usar o solr, precisará preencher seu índice de outra fonte, como uma tabela SQL. Na verdade, o solr é perfeito para armazenar documentos que incluem dados de várias tabelas e relações, que de outra forma exigiriam a construção de junções complexas.
  
• 
  Solr/Lucene fornece análise de texto/lematização/pontuação de pesquisa de texto completo/funções de imprecisão impressionantes. Coisas que você simplesmente não pode fazer com o MySQL. Na verdade, a pesquisa de texto completo no MySql é limitada ao MyIsam e a pontuação é muito trivial e limitada. Ponderar campos, aumentar documentos em determinadas métricas, pontuar resultados com base na proximidade da frase, corresponder à precisão etc. é um trabalho muito difícil e quase impossível.
  
• 
  No Solr/Lucene você tem documentos. Você não pode realmente armazenar relações e processos. Bem, é claro que você pode indexar as chaves de outros documentos dentro de um campo multivalorado de algum documento, dessa forma, você pode armazenar relações 1:n e fazer as duas coisas para obter n:n, mas sua sobrecarga de dados. Não me entenda mal, é perfeitamente bom e eficiente para muitos propósitos (por exemplo, para algum catálogo de produtos em que você deseja armazenar os distribuidores de produtos e deseja pesquisar apenas peças disponíveis em determinados distribuidores ou algo assim). Mas você chega ao fim das possibilidades com TEM / HAS NOT. Você quase não pode fazer algo como "obter todos os produtos que estão disponíveis em pelo menos 3 distribuidores".
  
• 
  O Solr/Lucene tem recursos de facetação muito bons e análise de pós-pesquisa. Por exemplo:Após uma pesquisa muito ampla que teve 40.000 ocorrências, você pode exibir que obteria apenas 3 ocorrências se refinasse sua pesquisa para a combinação de ter esse campo esse valor e esse campo esse valor. Coisas que precisam de consultas adicionais no MySQL são feitas de forma eficiente e conveniente.
  

Então, vamos resumir

• 
  O poder do Lucene é a pesquisa/análise de texto. Também é incrivelmente rápido por causa da estrutura do índice reverso. Você pode realmente fazer muito pós-processamento e satisfazer outras necessidades. Embora seja orientado a documentos e não tenha "consulta de grafos" como os armazenamentos triplos fazem com SPARQL, as relações básicas N:M são possíveis de armazenar e consultar. Se o seu aplicativo está focado na pesquisa de texto, você deve definitivamente optar pelo Solr/Lucene se não tiver boas razões, como consultas de filtro de intervalo multidimensionais muito complexas, para fazer o contrário.
  
• 
  Se você não tem pesquisa de texto, mas sim algo onde você pode apontar e clicar em algo, mas não inserir texto, os bons e velhos bancos de dados relacionais são provavelmente o melhor caminho a percorrer.