It seems like NoSQL could be left behind except for the .001% of use cases that actually require it and can't be easily replaced with extensions or (hopefully) automatable configurations of Postgres, but it would require application-level abstractions, and the database community doesn't value those enough, as evidenced by SQLAlchemy [1] not being highlighted on the homepage of every RDBMS project because of the awesome power and flexibility it gives the developer.
Specifically, a JSON column should be used to store everything other than primary keys and foreign keys, and views and indexes should be automatically created based on the schema defined in the application (i.e., get the schema from the ORM at deploy time and post the data to a schema/migration management system) using something like https://github.com/mwhite/JSONAlchemy
It is entirely possible to implement the CouchDB or MongoDB API on top of Postgres JSON, for instance.
Specifically, a JSON column should be used to store everything other than primary keys and foreign keys, and views and indexes should be automatically created based on the schema defined in the application (i.e., get the schema from the ORM at deploy time and post the data to a schema/migration management system) using something like https://github.com/mwhite/JSONAlchemy
It is entirely possible to implement the CouchDB or MongoDB API on top of Postgres JSON, for instance.
[1] http://www.sqlalchemy.org/