For internet user facing full-text search I would always prefer to use a separate tool and not a SQL database, because<p>- the fulltext tool, can and should hold only 'active' data<p>- as it has only active data, data size is usually much much smaller<p>- as data size is smaller, it better fits in RAM<p>- as data size is smaller, it can be probably run on poorer HW the full ACID db<p>- as the indexed data are mostly read-only, the VM where it runs can be relatively easily cloned (never seen a corruption till now)<p>- as FTS tools are usually schema-less, there is no outage during schema changes (compared to doing changes in ACID db)<p>- as the indexed data are mostly read-only, the can be easily backup-ed<p>- as the backups are smaller, restoring a backup can be very fast<p>- and there is no such thing as database upgrade outage, you just spin a new version, feed it with new data and than change the backends<p>- functionality and extensibility<p>There is probably more, but if one doesn't needs to do a fulltext search on whole database (and you usually don't), than its IMHO better to use separate tool, that doesn't comes with all the ACID constraints.
Probably only downside is that you need to format data for the FTS and index them, but if you want run a serious full-text search, you will have to take almost the same steps in the database.<p>On a 15y old side project, I use SOLR for full-text search, serving 20-30k/request per day on a cheap VM, and PostgreSQL is used as primary data source.
The PostgreSQL has had several longer outages - during major upgrades, because of disk corruption, because of failed schema migrations, because of 'problems' between the chair and keyboard etc...
During that outages the full-text search always worked - it didn't had most recent data, but most users probably never noticed.