Barrapunto

MongoDB (from "humongous") is a scalable, high-performance, open source, document-oriented database.

Si tu base de datos no és document-oriented olvídate de Mongo.

http://wiki.apache.org/cassandra/ [apache.org]:
Cassandra is a highly scalable, eventually consistent, distributed, structured key-value store

¿Tu base de datos ustiliza pares clave-valor o es una base de datos convencional?

Pero... ¿Estás seguro que el rendimiento que te da un postgres no te es suficiente?

Tirar por un nosql, puede hacer el desarrollo de nueva funcionalidad más tedioso, sobretodo si no lo conoces.

¿Más importante que tirar por nosql... estás seguro que vas a tener tanta demanda?

Si no es indiscrepcción, ¿de que versa el proyecto?

Salvo que estés montando un nuevo Google, Facebook o similar, no entiendo cuál es el "tema de la escalabilidad".

Y si estuvieras montando algo que necesitara eso, no lo preguntarías aquí.

Ergo no sabes ni lo que necesitas. Mi consejo: Pregunta "¿Qué debería usar para almacenar datos para un proyecto como XXX?" o mejor aún "¿Qué software/librerías/bases de datos usásteis en proyectos como XXX?".

O aún mejor, dale tu trabajo a alguien que se lo merezca.

Aqui tienes una pequenia comparativa de diferentes BBDD NoSQL: Cassandra vs MongoDB vs CouchDB vs Redis [barrapunto.com]

En cuanto a cual usar, depende muchisimo de lo que necesitas, te recomiendo que mires dos o tres y hagas un prototipo con cada una a ver si cumplen tus requisitos, por mi parte te puedo hacer las siguientes recomendaciones:

Si no necesitas orientacion a documentos, Membase esta muy bien (mientras los indices te quepan en memoria) y lo de poder actualizarla en caliente y el cliente web son grandes bazas. Tengo una instancia en el portatil con 25 millones de registros (de un par de pruebas que hice) y se mantiene tranquilamente en las 5K operaciones por segundo.

Si necesitas transacciones, puedes mirar tambien Redis, eso y la posibilidad de usarlo como mensajeria (permite definir topics y hacer publish/subscribe) la hacen muy interesante, pero los datos te tienen que caber en memoria. En mi empresa tenemos un par de aplicaciones con Redis, precisamente por esas dos cosas (transacciones y pub/sub).

Otra con la que solo he jugado un poco pero que tambien recomendaria echarle un vistazo es CouchDB, tiene muy buena pinta (pero como digo, solo he jugado un poco, nada serio).

De todas formas, no deseches MongoDB tan rapido, algun equipo de mi empresa la ha usado y en general estan muy contentos (aunque me han dicho que cosas como el autosharding dan algunos problemas).

Lo que si que lleva razón la gente es que mysql te va a ser suficiente. Los servidores ya andan por 24GB de memoria y por si no te bastasen cosa que dudo, hay mil técnicas de escalar sql.
Esa no es razón para usar mongobd, como tampoco para no hacerlo. Ambas te funcionaran perfectamente, con sus manias particulares de cada una.
Mi esperiencia es que llevo usando mongo en produccion desde hace años en sitios de alta carga y no me ha dado más problemas que mysql pero tampoco menos.
MongoDB es la bd no sql más cercana a una relacional. Yo la elegi precisamente por eso, por que al ser tan parecida a mysql me simplificaba la portabilidad.
Si quieres usarla a modo relacional, tan solo create clases usando el habitual patron de diseño de abstraccion de datos que te oblige a meter todos los valores del objeto y ya está.
MongoDB es entre 10 y 100 veces más rápida y potente que mysql o postgre en pruebas reales hechas por mi. Haz siempre los test tu. No se porque la gente mira benchmarks trucadisimos con lo facil que es montar una prueba real parecida a lo que será tu aplicacion. Y según lo que te salga pues ya decides.

Que sea tan brutalmente rápida esta muy bien, pero ten en cuenta que esa velocidad se paga y mucho en no tener transacciones ni integridad referencial. Esto es lo único importante que debes valorar, el resto, que es document-oriented, inmadura, son...
Mongodb te obliga a hacer siempre busquedas simples. Esto es lo que yo amo de mongodb, porque le impide al programador meter la query kilometrica en la aplicación que es por donde siempre vienen los problemas despues, cuando la bbdd es pequeña bien y un año despues cuando crece pues el marron para otro.
Pero a veces apetece meter una join infernal que sabes que solo se ejecutará una vez al año y con mongo no podras.
Monta las clases abstractas tales que te permitan conmutar entre una y otra, y ya decidiras. Asi de paso tu código será mas estructurado y robusto. Las tablas peligrosas, sobre mysql con transacciones y el resto a mongo. O mongo como capa de cache.
Un consejo, desactiva el javascript de mongo, se purista y ten cuidado porque mongo distingue letras y numeros, sql no. Algun susto me he llevado yo por no hacer el cast.

Hola. Recuerdo que estoy ya se preguntó hace tiempo en barrapunto. Busca a ver si todavía están las respuestas por ahí.

Respecto a Drupal solo decir que admite MariaDB sin problemas:
http://drupal.org/requirements#database [drupal.org]

Ni de coña pincho en un enlace acortado.

A saber donde acabo.

Si en algún momento apuntó a un goatse, ahora apunta a MySQL [mysql.com].

Programar bases de datos con consultas SQL es mucho más sencillo que otras opciones. Y además hay bases de datos para dar y elegir, con sus librerías clientes y enlaces en lenguajes desde el C hasta el Python y Ruby, pasando por pascal, java y C++. Si es una cosa simple, con SQlite puedes hacer maravillas

Si utilizas noSQL, te complicas la vida. Osea, que salvo que tu sistema necesite altas velocidades por tener miles y miles de consultas simultáneas y necesitar una respuesta casi instantánea, vaya, eres facebook, google o algo así, usar noSQL es matar moscas a cañonazos.