I don't think worrying about database portability often makes much sense for projects with beyond the simplest access patterns and projects that one does not sh

I don't think worrying about database portability often makes much sense for projects with beyond the simplest access patterns and projects that one does not ship to a client, where one anticipates needing to support many possible databases that are supported on-site. Oftentimes, using features supported only by one or a few database management implementations can make things substantially easier. Ports are often difficult and risky without substantial continuous integration all along because of other quirks in the implementation regardless, both of any ORM layer and of the DBMS. One advantage of arrays can be performance: not having to locate several rows in another relation can be a time-saver; in this case it can act like a nicer denormalization. But, as array elements are not quite first class in SQL (as the manual notes) it doesn't work quite as smoothly if one plans to enrich their tags with a lot of meta-information or other relationships. In any case, I have used this strategy on an analytic-oriented system and it worked great: the queries were simple to read, performed well, and the representation of the row was convenient to use in client programs. I've also used hstore to convenient effect on more OLTP-oriented systems although it too is a Postgres-only (for now) data type extension.