> Use Postgres for Fulltext Search instead of Elastic.
Yea, that's not quite the same. Im going to make the argument that a well tuned search platform along side your data storage is probably one of the most useful things you can have. It's one of the first places where you will be "let down" by the Postgres solution.
As a document store, a queue, Postgres will do the job up to a point. When and where it breaks down in one of these ancillary roles you're likely to have the resource to support more systems, or a more "focused" tool.
I think that's true of most of the examples. There are times you will want/need to break out. When you do, it should be apparent and compelling to do so. Whether it's Redis, RabbitMQ(or another queue option), or Elastic you should have a clue as to what and why you need to break out.
Many/most applications don't have those needs. Then again, I'm also a fan of using JSONB for details in fewer tables over overly normalized structures. It varies.
> Use Postgres for Fulltext Search instead of Elastic.
Yea, that's not quite the same. Im going to make the argument that a well tuned search platform along side your data storage is probably one of the most useful things you can have. It's one of the first places where you will be "let down" by the Postgres solution.
As a document store, a queue, Postgres will do the job up to a point. When and where it breaks down in one of these ancillary roles you're likely to have the resource to support more systems, or a more "focused" tool.