Сергей

1. В Redis лучше представлена работа с коллекциями. Простой пример — инкрементальный счётчик. Вы делаете incrby/hincrby для любого ключа, не заботясь о его наличие в хранилище. В Postgres аналогичная функциональность на основе последовательностей (nextval('foo')) подразумевает, что вы уже создали последовательность 'foo' ранее. Это подталкивает вас на написание процедур, которые перед попыткой изменить счётчик, сначала проверяют его наличие, при необходимости создают его и только потом изменяют. Больше ручной работы.

2. Структуры данных в Redis оптимизированы либо под быстрый поик О(1), либо под компактность и приемлемую произволительность O(N), O(log(N)). Практически всегда получается обходиться простыми или вложенными хеш-таблицами с О(1) или О(n). В Postgres вы практически всегда пользуетесь той или иной разновидностью B/R-tree, GiST/GIN индексов со сложностью O(log(N)(+N)). До версии 8.4, индексы типа HASH в Postgres имели практически схожую с B-tree скорость поиска, поэтому их применение не имело никакого смысла. Сейчас, в версии 9.1, смысла стало больше, но не намного — HASH индексы не поддерживают Write-Ahead Log и при сбоях требуют ручной переиндексации:
"Hash index operations are not presently WAL-logged, so hash indexes might need to be rebuilt with REINDEX after a database crash. They are also not replicated over streaming or file-based replication. For these reasons, hash index use is presently discouraged." http://www.postgresql.org/docs/9.1/static/indexes-types.html

У себя в проектах, я использую и Redis, и Postgres. Первый — как эффективную систему для сбора онлайн-статистики (счетчики-лайки, различные метрики), а второй — как хранилище для пользовательских аккаунтов и контента с его мета-информацией. При этом, наметилась тенденция переносить контент на HBase, оставляя для Postgres только задачи по ACID-обслуживанию операций с пользовательскими аккаунтами.

пробовал extjs, dojo и backbone + jquery
первые два сильно отличаются от последнего в назначении.
Они не предназначены для создания сайтов в привычном представлении, а для создания оконных приложений в браузере. Фреймворки для создания толстого клиента системы. При том с dojo у меня постоянно возникали проблемы.
Проблема, которая больше всего запомнилась — странный набор storage. Есть хранилища, которые держат данные в клиенте, загрузив единожды, и есть несколько, которые запрашивают данные с сервера. Из тех, что работают по запросу, одно хранилище было read-only, а второе требовало REST на стороне вебсервера

В последнем проекте использую backbone — удобная и гибкая штука. Его достаточно чтобы создавать одностраничные сайты, но нет виджетов интерфейса, как будет выглядеть сайт остается полностью на твое усмотрение.

В любом случае плата за всю эту роскошь — огромное количество js кода.

Если опыта нет, то вы с веротностью 100% наступите на грабли, сядете в лужу и вам придётся всё переписывать. Если бы опыт хайлоада был, то вероятность была бы меньше, но всё равно большая.
Это нужно принять как есть. Что бы вы ни делали, если у вашего проекта всё будет хорошо, то в плане нагрузки вы многое сделаете неправильно.

Поэтому пишите на питоне, а когда напишете всю логику и устаканите архитектуру, то спокойно переписывайте на плюсы (да. на плюсы. чтобы написать всё на си, у вас уйдёт намного больше времени, поэтому используйте всё-таки плюсы)

ищите ppa в которых уже кто-то собрал launchpad.net/ubuntu/+ppas
а дальше add-apt-repository

Как вариант, можно поиграться с запросом, который отдает данные Сфинксу на индексацию — в нем сразу удалять пробелы и тире именно в этом поле с помощью REPLACE.