Data Engineer - Infra - Data & Statistics - Metabase PostgreSQL & AWS

Une dizaine de dashboard Metabase sont embed (view, filter & export - no edit) dans notre SaaS, utilisé à travers 3000 comptes sur des centaines de millions de data points.

Metabase est relié à des db PostgreSQL elles mêmes reliées à la db de production en MySQL

Le tout, sur AWS et relié à du code en NodeJS / Typescript

Aujourd'hui, notre capacité à mettre à jour les statistiques et à afficher les données rapidement aux utilisateurs devient de plus en plus difficile.

*Objectifs*
- Évaluer la scalabilité et fiabilité de notre configuration actuelle Metabase.
- Identifier les limites et opportunités clairement, afin d'aider à la décision à court, moyen et long terme.
- Améliorer la vitesse d'affichage (<3s idéalement)
- Si possible, réaliser les développements nécessaire et/ou accompagner l'équipe dans ces développements

*Questions principales actuelles*
Notre architecture actuelle (Metabase + base de données) peut-elle évoluer sans risque avec la multiplication des tableaux de bord clients ?
Y a-t-il un risque de dégradation des performances ou de surcharge de la base de données de production ?
Notre modèle d’isolation des données est-il conforme et sécurisé pour un usage client ?
Quelle serait la meilleure configuration (infrastructure + cache + modélisation des données) à moyen/long terme ?

*Environnement*
Outil BI : Metabase (self host sur ECS Fargate... Possible de passer en Cloud si besoin)
Version de Metabase : 1.52.x -> Possible d'upgrade (nous aimerions le faire dans le futur)
Base de données principale pour les stats : PostgreSQL
Base de donnée de production pour le reste : MySQL
Infra : AWS (Dont CloudWatch)

*Livrables attendus*
Revue d’architecture
Audit de performance et de sécurité
Rapport (PDF ou Notion) comprenant :
- Diagnostic et risques prioritaires
- Recommandations d’architecture
- Quick wins activables à court terme Vs moyen & long terme

Si possible :
- Accompagnement au développement ou développement

----

*Informations techniques complémentaires* :

PostgreSQL: AWS RDS PostgreSQL 15.x
Instance de type db.m6g.large (ou équivalent) : 2 vCPU + 8–16 Go RAM + stockage GP3.

Taille db actuelle: ≈ 300–400 GB (avant archiving), croissance ~10–20 GB / mois.

Schéma: OLTP + analytique mélangé (beaucoup d’historique + tables événementielles).

Datalake: Aucun aujourd’hui.

Topologie réseau: out dans le même VPC / sous-réseaux privés.

Backups PostgreSQL: Automatiques AWS + possibilité de restauration snapshot.

Read-replica: Possible via RDS mais pas encore activé.

Connexion DB: Un utilisateur unique Metabase avec permissions en lecture.

Collections / permissions: Oui : isolation par collection (espace client) + règles de permissions par type d’utilisateur.

Filtres dynamiques: Oui : variables SQL, field filters, quelques vues côté DB.

Cache Metabase: Cache activé, TTL standard Metabase.
Stockage local (pas Redis).

Instances Metabase: 1 instance derrière un load balancer mais sans scaling horizontal automatique.

Containerisation: Oui, Docker sur ECS Fargate.

Sessions utilisateurs: Expiration standard Metabase.

Modèle d’isolation: Colonne date et SCHOOL_ID ou équivalent dans toutes les tables → filtrage applicatif via Metabase + permissions des collections.

RLS PostgreSQL: Pas encore mis en place.

Privilèges DB Metabase: SELECT uniquement.

Chiffrement: TLS actif entre ECS ↔ RDS.
Storage RDS chiffré par AWS.

Plusieurs tables très volumineuses comparées à d'autres.

ETL actuel: Jobs Node.js / Knex / Lambda / cron.