Как мы настраивали PostgreSQL для использования в качестве кэша

Так ведь статья как раз про него "для чтения задали объем буферного кэша из расчета, что туда должны уместиться все данные".
Точнее про то, как можно (нужно) встроенный кеш использовать в своих целях.

Что именно смутило бы?

NORD имеет ряд специальных доработок, в основном в части информационной безопасности и удобства эксплуатации.

К примеру:
- Администратор может задавать и контролировать сложность паролей пользователей;
- Доступно хранение истории паролей с настраиваемой глубиной;
- Планировщик заданий с гибким расписанием и возможностью запуска в нескольких БД.

Эти решения в начале были в группах кандидатов, но отсеялись по ходу:

• Aerospike не подошел по лицензионной политике.

• KeyDB и RocksDB не использовали ранее, но варианты интересные. Но так как скорость не стояла во главе угла, надо было удержаться в рамках "не хуже CB" и желательно без экспериментов (критичный узел критичного продукта, короткие сроки).

• Tarantool хорош, мы его даже успешно тестировали. Но его выбор будет означать хоть и незначительный, но vendor-lock (все же это сервер приложений и под него нужна отдельная реализация серверной логики на стороне кластера TNT). Нам же хотелось получить абстрактный источник key-value данных, который на стороне приложения можно менять малой кровью через адаптеры.

У производства было сравнение на этапе аналитики по ТТХ разных альтернативных решений. Кроме ТТХ также рассматривался вопрос текущей доступности лицензирования. В статье затронули сравнение тестовых проговнов с Redis. Невозможно было включить все сравнения в 1 статью, не в этом задача была. Про то, что в чистом виде Postgres не везде подойдет в предлагаемой роли - безусловно, факт. Там есть какие вопросы порешать. Приведенный опыт больше подходит на успешный proof of concept. Если концепт подходящий, то дальше уже можно углубляться в поиски или реализацию движков хранения и прочие вопросы.