REFERENCE ARCHITECTURE · DIGITAL NATIVES & SAAS
Embedded Analytics Built for Tenants, Scale and Speed.
Deliver secure dashboards and contextual insights inside digital products with tenant-aware ingestion, analytical serving and targeted caching. Avoid making primary transactional databases carry unlimited multi-user analytical workloads.
For SaaS engineering leaders · product platform teams · data platform engineers. Stack: ClickHouse · Redis · PostgreSQL · MongoDB Community Server (source-available, SSPL)
THE CHALLENGE
Fast, Secure Analytics for Products That Never Stop Growing.
Customers expect dashboards and insights inside the product, not in a separate BI tool. As tenants, users and event volumes grow, analytical queries start competing with the transactional database that runs the product, cache strategies multiply, and a single missing tenant filter becomes a data-exposure incident. Embedded analytics needs its own serving design, with tenant boundaries, cost and latency measured from day one.
- Production database under strain — Reporting queries on PostgreSQL or MongoDB slow down the core product for every customer.
- Isolation by convention — Tenant filtering depends on every developer remembering a WHERE clause.
- Noisy neighbors — A few large tenants or heavy dashboards degrade performance for everyone else.
- Cost that grows faster than revenue — Storage and compute per tenant are unknown, so pricing and capacity planning are guesswork.
ARCHITECTURE OVERVIEW
A Dedicated Serving Path for Customer-Facing Analytics
Operational data and product events flow into an analytical store designed for tenant-aware queries. A single API layer owns authentication, authorization and tenant context, so dashboards never query data stores directly.
Figure 1. Embedded Analytics for SaaS reference architecture (conceptual). Color key: see How to read our diagrams.
Logical Data and Query Flow
- Ingest tenant dataApplication events and operational data are ingested through governed pipelines from PostgreSQL (or YugabyteDB, where used), MongoDB Community or event producers, for example through Apache Kafka.
- Serve analyticsClickHouse acts as analytical serving layer for product usage, billing analytics, campaign or customer insight queries; tenant keys and query security are mandatory.
- Cache where justifiedRedis supports bounded, invalidatable result caching and low-latency operational state where justified by measurements.
- Enforce at the APIAPI/BFF layer handles authentication, authorization, rate limits, tenant isolation and secure parameterized query access.
- Observe and testObservability captures p95/p99 tenant query latency, resource fairness, cardinality growth and unit cost; automated tests detect cross-tenant access.
Conceptual pattern. Connectors, licensed capabilities, versions, security policies and topology are validated in a project-specific architecture.
Last reviewed: — · Version scope: —
COMPONENT ROLES
Who Does What in the Stack
| Component | Classification | Role | Qualification |
|---|---|---|---|
| PostgreSQL | Independent OSS support | Transactional product data (system of record) | Analytical load moved off the primary; replicas or CDC used for extraction |
| YugabyteDB (optional alternative to PostgreSQL) | Independent OSS support | Transactional product data (system of record) where the product must accept writes in several zones or regions, or has outgrown one PostgreSQL primary | Chosen only after compatibility testing against YSQL; PostgreSQL remains the default where one primary meets scale and recovery objectives; extraction for analytics designed and tested per release |
| MongoDB Community Server (source-available, SSPL) | Independent community support | Document-based product data (system of record) | Change streams or batch extraction designed per collection |
| Event producers & pipelines (for example Apache Kafka) | Customer-owned or separately selected; Apache Kafka available with independent OSS support | Deliver product events and changes with tenant identifiers | Every record carries a validated tenant key |
| ClickHouse | Partner-led or ClickHouse OSS route | Analytical serving for usage, billing, campaign and customer insights | Tenant-aware schema, sorting keys and query controls are mandatory |
| Redis | Strategic partner | Bounded, invalidatable result cache and low-latency operational state | Used only where measurements justify it; tenant-scoped cache keys |
| API / BFF layer | Customer-owned | Authentication, authorization, rate limits, tenant context, parameterized queries | The only path from dashboards to data stores |
Links: ClickHouse partner · ClickHouse OSS · Redis · PostgreSQL · YugabyteDB · MongoDB Community · Apache Kafka
DESIGN TRADEOFFS
Decisions That Balance Isolation, Speed and Cost
| Decision | Options | Choose based on | Validate with |
|---|---|---|---|
| Tenancy model | Shared tables with tenant key · Database per tenant · Dedicated cluster for large tenants | Number and size distribution of tenants, contractual isolation requirements, operational overhead | Isolation tests, per-tenant cost, operational load of schema changes |
| Tenant enforcement | Enforced in API only · API plus database-level row policies and per-tenant users or settings | Risk tolerance, defense-in-depth requirements | Automated cross-tenant access tests on every release |
| Data freshness | Streaming ingestion (for example Apache Kafka) · Micro-batch · Scheduled batch | What users expect to be live versus daily | Ingest-to-display lag measured per dashboard |
| Pre-aggregation | Raw events only · Materialized views / rollups for common query shapes | Query concurrency, dashboard shapes, storage budget | p95/p99 latency on known query shapes; storage growth |
| Result caching | No cache · Redis cache with TTL and event-based invalidation | Repeat-query rate, freshness tolerance, cost of recomputation | Hit rate, stale-result rate, latency with and without cache |
| Fairness controls | Global limits · Per-tenant quotas, rate limits and query complexity limits | Tenant size variance, noisy-neighbor risk | Load test with mixed large and small tenants |
| Operational database scale-out | Single PostgreSQL primary with replicas · YugabyteDB distributed SQL across zones or regions | Write growth, need to keep accepting writes through a zone failure, regional data placement, application compatibility, operating model | Compatibility test against YSQL; node and zone failure tests; write latency between regions measured in a PoC |
- The primary transactional database is not an unlimited reporting engine.
- Redis is not a durable substitute for PostgreSQL or MongoDB; cached results must be safe to discard.
- Dashboards and embedded components never receive direct database credentials.
Running ClickHouse already?
Choose the support route that fits: partner-led or independent ClickHouse OSS engineering.
SECURITY & RESILIENCE
Tenant Isolation You Can Test
Tenant isolation
Tenant context comes from the authenticated session, never from a client-supplied parameter. Apply defense in depth with database-level controls where supported.
Authentication & authorization
Centralize sign-in, roles and per-tenant permissions in the API layer, integrated with your identity provider.
Safe query access
Parameterized, allow-listed query shapes only. No free-form SQL from the browser.
Encryption & secrets
Encrypt traffic between services and data at rest where supported. Rotate service credentials through your secrets manager.
Recovery without silent loss
Define RPO/RTO for ingestion, the analytical store and the cache separately. Make ingestion replayable so data can be rebuilt after a failure.
Observability & audit
Track per-tenant latency, errors, resource use and cost, and log data access with tenant identifiers for audit.
PROOF & OUTCOMES
Acceptance Tests Before Customers See a Chart
Every engagement agrees acceptance tests with your team and runs them against representative tenants and query shapes.
Acceptance Tests
| Acceptance category | Sample test |
|---|---|
| Tenant isolation | Cross-tenant access attempt never returns data outside tenant context |
| Concurrency | Test growing concurrent dashboards and known query shapes |
| Freshness | Measure ingest-to-display lag; distinguish live and cached data |
| Operational cost | Per-tenant storage/compute cost at representative retention |
| Resilience | Recover after ingest/serving component failure without silent data loss |
Measurement Plan
| Metric | How it is measured | Target |
|---|---|---|
| Concurrent tenants | Number of tenants and concurrent dashboard sessions sustained in a load test | Forecast peak plus agreed headroom |
| Chart latency | p95 / p99 chart query latency per tenant size band | Agreed in PoC acceptance criteria |
| Unit infrastructure cost | Storage and compute cost per tenant, or per active user, at representative retention | Assessed through workload and cost modeling |
| Isolation tests | Pass rate of automated cross-tenant tests in CI and production checks | 100% pass required for release |
| Fairness | Latency impact on small tenants while large tenants run heavy queries | Agreed tolerance |
What You Receive
- Tenant-aware data model and query design
- Automated isolation test suite
- Load-test and latency results for agreed query shapes
- Per-tenant cost model
- Runbooks for ingestion replay, scaling and recovery
Embedded Analytics for SaaS FAQs
Why not run customer dashboards on our PostgreSQL or MongoDB database?
Transactional databases are optimized for the product’s reads and writes. Heavy, many-user analytical queries compete with that workload and can slow the whole product. A dedicated analytical serving layer, fed by replicas, change data capture or event pipelines, protects the product and scales analytics separately.
How is tenant isolation enforced?
Tenant context is derived from the authenticated session in the API layer, and every query is parameterized with it. Where the database supports it, row-level policies and per-tenant users or settings add defense in depth. Automated tests attempt cross-tenant access on every release.
Do we always need Redis?
No. Redis is added for bounded, invalidatable result caching or low-latency operational state when measurements show it helps. Many dashboards are served directly from the analytical store, especially with pre-aggregated views.
Is MongoDB Community Server open source?
MongoDB Community Server is source-available under the Server Side Public License (SSPL), which is not an OSI-approved open-source license. Bassirah provides independent engineering support for it; this does not imply MongoDB endorsement or vendor support rights.
How do we keep analytics costs predictable as we grow?
By measuring per-tenant storage and compute at representative retention, applying partitioning and retention policies, shaping common queries into pre-aggregations and setting per-tenant quotas. We build a cost model you can use for capacity planning and pricing decisions.
Related Pages
Book an Embedded Analytics Workshop.
Bring your tenancy model, query shapes and growth plan. We will design the serving path, isolation controls and a cost model you can test.