What about the cost of running a separate service like ElasticSearch for a small startup. It should be easy to swap out PG text search with a more mature solution later on as you scale.
I think if you are concerned with swapping out to a different system as you scale you should use a "search as a service" company and then bring it in-house if the cost becomes too much.
The interface provided by a "search as a service" company is going to be a lot more similar to elasticsearch/solr than it is to postgres, so it would be a much easier switch.
If you want to switch from PG full-text search to something else, you'll essentially have to start from square one because all of the ways you are interacting with your search mechanism (defining, inserting, updating, querying, retrieving documents) are completely different between PG and all the other search programs.
A blog post like this makes it all seem so easy, but I assure you maintaining these long queries, dealing with the extra load on your database, preventing XSS and just overall making administering your database a little more difficult also has a real cost.
Especially with cloud hosting providers, were more memory gets expensive, I would recommend to go with native C/C++ applications like Postgres/MySQL/SphinxSearch/SQLite-FTS. (add Lucene based Solr and ElasticSearch to the list if memory is cheap)
