> Насколько мне известно на уровне строк назначать права доступа мы не можем,

Штатными средствами PostgreSQL - нет.

> значит схема с двумя таблицами не подходит по определению.

Таблиц будет немного больше двух. ;) Посмотрите в форуме "Проектирование...", там эта тема часто обсуждается.

> Первое, что приходит в голову, это создавать схему для каждого клиента и
> ограничивать его в пределах этой схемы.
> Собственно вопрос - насколько разумно это решение с точки зрения
> масштабируемости

Я бы назвал это решение плохим даже не рассматривая масштабируемость: не все СУБД поддерживают namespace (в смысле схемы), а ориентироваться на фичу конкретной СУБД без веских на то оснований бессмысленно.

> Учитывая сказанное в первом посте, а также то, что сохранность данных критична,

Денежный эквивалент у Вашего критерия "критичности сохранности данных" есть?

> будет ли правильнее организовать их в одну структуру, или же стоит создавать
> отдельную структуру данных (если не схему, то базу) для каждого клиента?

Странная постановка вопроса. Вы что хотите в результате получить? Базы данных с независимым содержимым для каждого клиента и синхронизацией части содержимого хм... сложным, в общем, образом, или все-таки разделить доступ к одним и тем же данным?

> система - это хостинг collaboration, crm и финансовых инструментов для
> компаний, занимающихся оффшорным программированием

Вы меня не поняли. Я просил привести денежный эквивалент стоимости данных (приблизительно). Отсюда, собственно, абсолютно логично формулируются требования к надежности, а отсюда, в свою очередь, к СУБД и прочим деталям.

> цель - разделить доступ на уровне субд

Так я и предложил посмотреть на раздел форума "Проектирование баз данных". Такие вопросы часто возникают и еще чаще обсуждаются. Ответ на Ваш вопрос там есть.

> извините, я ошибся - мне перехотелось хранить данные каждой компании в
> раздельных структурах, когда я представил себе, какие акробатические
> упражнения придется выполнять, чтобы эффективно получать, к примеру,
> выборку всех клиентов, имеющих задолженность по оплате сервиса

На мой взгляд, это совершенно разные задачи: расчет стоимости сервисов для клиентов и базы данных для клиентов. Если, конечно, Вы не пишете Абсолютно Все Умеющее Приложение, которое считает загрузку сервера каждым клиентом, его траффик и пр., и пр., и пр.