Bonne intuition. Une base transactionnelle n'est pas faite pour des données d'événements en append-only à ce volume : les lectures deviennent très lentes dès que les lignes s'accumulent. C'est exactement le rôle des moteurs OLAP.

• Conçus pour les événements. Stockage en colonnes, partitionnement et cache : ingérer des millions de lignes ne coûte presque rien.
• Rapides en lecture. Les agrégations sur des tables énormes restent rapides, donc le volume de stockage et le temps de requête ne sont plus un sujet.

Stocke tout, et ne te soucie plus du volume ni de la latence des requêtes.

Pars sur ClickHouse. Leur cloud managé est la solution la plus simple, mais c'est surdimensionné et cher à ce stade. ClickHouse est open source : loue un serveur basique chez un hébergeur qui ne facture que ce que tu consommes, et installe ClickHouse dessus.

Ensuite, trois briques :

• Modélise les événements séparément de ta base applicative. Un modèle DocumentEvent dédié pointe vers la connexion ClickHouse : tu écris des requêtes façon Eloquent pour les stats, sans jamais toucher ta base principale.
• Bufferise côté client. Regroupe les événements dans un buffer JavaScript dans le navigateur, puis envoie-les par batchs vers un seul endpoint, plutôt que d'envoyer une requête à chaque mouvement de souris.
• Ingère en asynchrone. Cet endpoint se contente d'accepter le batch et de répondre OK immédiatement. Un job en queue le convertit ensuite au format ClickHouse et l'insère.

Place la lecture derrière un service de stats qui interroge ClickHouse directement. Côté lecteur, l'écriture est instantanée, et tes dashboards lisent directement depuis le moteur OLAP.