Il est possible d'avoir de grosses base de données sans consommer beaucoup de ram.

C'est la taille du cache, la complexité ds requêtes et le nombre de requêtes en // qui va déterminer la consommation mémoire de MySQL.

Pour Firefox, je suppose que si ils retirent la compatibilité avec les PC sans SSE2, c'est simplement pour limiter les tests à faire et que le parc de CPU sans SSE2 qui utilise Firefox est très faible (les derniers processeurs à ne pas intégrer le SSE2, c'est le Pentium III Tualatin à 1400 Mhz (Pentium III 1400S, sortie en janvier 2002)

Il est possible d'avoir de grosses base de données sans consommer beaucoup de ram.
C'est la taille du cache, la complexité ds requêtes et le nombre de requêtes en // qui va déterminer la consommation mémoire de MySQL.

Pour les BDD Relationnelles & ACID (typiquement Oracle DB), il est généralement plus efficace de mettre le cache au niveau de la base de données qu'au niveau du filesystem, le moteur SGBD étant en général plus compétent pour gérer les blocs chauds.
J'ai rarement vu des bases de Prod Oracle conséquentes avec moins de 4 Go de SGA, donc 64 bits indispensable.

(...)
Je crois que la plus grosse BDD qu'on aie en cache RAM doit faire 200-300Go (la BDD fait quelques To de mémoire, beaucoup d'ORM dedans)

Au boulot, la plus grosse base fat environ 15  To sur disque (la partie données uniquement, donc il y a en plus OS / binaires / journaux log) et la base Oracle associé a une SGA de 450 Go, le tout sur du power avec 512 Go de Ram.
C'est pour de l'ERP, et pas du "en mémoire" qui devrait à terme probablement remplacer ce qui tourne actuellement sur les unix power / superdome en base de données.

Sinon pour revenir à la question de base et comme dit par d'autres, l'espace d'adressage plat me semble le plus intéressant pour ne plus avoir de 32b à moins de besoin très spécifiques.