—/ Thoughts
Scaling Embedded Analytics for Enterprise SaaS
The Docebo case study with AWS QuickSight. On multi-region architecture, managing 40,000 dashboards with a team of four, and why Day 2 operations matter more than Day 1.
An AI-led conversation — a format I chose to keep things honest and to the point.
Developing an embedded analytics solution for a global leader like Docebo is a massive undertaking. With over 4,000 customers and 50,000 users, why did you settle on AWS QuickSight as the core engine, and what was the high-level architectural goal?
In the enterprise LMS space, data isn't just a "nice-to-have" — it's the backbone of ROI for our customers. We needed a solution that could scale horizontally without forcing us to manage the underlying infrastructure of a traditional BI tool.
The goal was to provide a seamless, "native-feeling" experience where administrators could track enrollment trends and course completions in real-time. We chose QuickSight because of its serverless nature, its robust API ecosystem, and its ability to handle multi-tenant isolation at a massive scale. We didn't just want to embed a chart; we wanted to build a sophisticated analytics platform inside our SaaS.
An analytics platform, not just embedded charts. Important distinction.
Handling 4,000+ customers globally introduces significant challenges regarding data residency and service limits. How did you structure the AWS footprint to support this?
This was one of our most critical architectural decisions. To respect global data residency requirements and bypass the technical limits of a single AWS account — such as namespaces capacity or API throttling — we implemented a Multi-Region and Multi-Account deployment.
We distributed the workload across several AWS regions, ensuring that a customer's learning data stays within their regulated geography. By using a multi-account strategy, we isolated failure domains and scaled beyond standard service quotas. It essentially turned our analytics layer into a distributed system that mirrors the global footprint of the Docebo platform itself.
Data segregation is a non-negotiable for enterprise SaaS. How did you ensure security while distributing over 40,000 standard dashboards?
Security and segregation were baked into the "adapter" logic of our integration. We utilize Row-Level Security and dynamic namespaces to ensure that even though we are running a massive fleet of 40,000+ standard dashboards, no customer can ever see another's data.
Every request is authenticated and authorized through our application layer before a signed QuickSight URL is generated. This ensures that the enterprise-grade security Docebo is known for remains intact, even as we move millions of rows of learning data through the analytics pipeline.
40,000 dashboards with zero data leakage. That's the kind of number that makes security auditors nervous — and impressed.
You managed to build this with a lean team of only four developers. How did you automate the operational overhead of managing such a vast number of assets?
Efficiency came through automation and internal tooling. We couldn't have managed this manually. We built a custom Backoffice Application that acts as our control plane. It manages the entire promotion lifecycle of a dashboard — from the Development environment, through Staging, and finally into Production.
The heavy lifting is handled by AWS Step Functions. We orchestrated complex deployment workflows that automate the creation of data sets, the analysis of templates, and the final publishing of dashboards. This "Infrastructure as Code" approach for BI allowed our small team to act like a much larger department. We aren't just "dashboard creators"; we are "automation engineers" for data.
Beyond standard reports, you've introduced customization and AI. How are you balancing ease of use with advanced capabilities?
We offer a tiered experience. Most users start with our library of out-of-the-box dashboards for immediate insights. However, for power users, we allow them to create custom dashboards — picking widgets from a predefined library or building entirely new visualizations from scratch.
On the AI front, we've integrated QuickSight Q for natural language querying, but we also added custom layers to make the "conversation" with data more intuitive for the learning domain. A user can ask, "Which department had the lowest completion rate last quarter?" and get an instant visual answer. It's about reducing the friction between a question and a business decision.
This project was showcased at AWS Re:Invent 2024 and the AWS London Summit 2025. Looking back, what is the biggest takeaway for other EMs building similar SaaS solutions?
The success of this project — which positioned Docebo as one of the most significant QuickSight customers in Europe — wasn't just about the tech stack. It was about pragmatic scaling.
By choosing a serverless, API-first BI tool and investing heavily in deployment automation early on, we avoided the "operational trap" of hiring 20 people to maintain a legacy BI server. My advice to other EMs is: focus on the "Day 2" operations before you write the first line of code. Build the automation to manage 40,000 dashboards, and managing the first 10 becomes trivial.
Day 2 before Day 1. Counterintuitive, but clearly effective at this scale.
Focus on the Day 2 operations before you write the first line of code. Build the automation to manage 40,000 dashboards, and managing the first 10 becomes trivial.