With that little information from the OP the answer is probably: Use ES or if it's a small side project use your DB's included full text search if it's good enough.
You can go far using purely Postgres full text search. I ported a site from Solr to PG full text because of strange syncing issues and it was just as fast.
Afterwards I never really saw the point of any of the search systems other than elastic search because the streaming capabilities that it gives you.
I don't have a lot of experience with PG full text search in production or a bigger scale. I'd just suspected that it doesn't perform that well if you need a lot of filters, range queries etc? Maybe someone with more experience can chime in.
At work we just materialize the data from PG into ES and take advantage of the powerful ES queries and redundancy. Scaling up by just adding nodes is easier.
For our use case we don't really need a strict verification. Everything that should go to ES is put in a queue (using DB triggers) and then sent off to ES. If something should cause errors we'd see that by observing the error rate on ES ingest I assume.
Depends on the use case. We use it alongside Cassandra and MySQL, but we also deal with tens of billions of records. If you just have a webblog, you could just use elastic.
Afterwards I never really saw the point of any of the search systems other than elastic search because the streaming capabilities that it gives you.