These are the main in-product dashboard Options when embedding analytics in your application:

1. Tinybird (real-time analytics APIs for custom dashboards)
2. Embedded BI Tools (Looker, Power BI, Tableau, Metabase)
3. Apache Superset (open source business intelligence)
4. Cube (semantic layer with pre-aggregations and caching)
5. Amazon QuickSight (AWS embedded analytics)
6. Retool (low-code internal tools platform)
7. Custom dashboards (APIs + charting libraries)

In-product dashboards are analytics panels embedded within applications showing metrics and visualizations without requiring users to leave for external BI tools. Microsoft defines embedded analytics as integrating analytical content from separate platforms within applications, portals, or websites—delivering customer analytics, operational dashboards, or self-service exploration contextually within your product.

They solve user experience problems through integrated analytics. For many teams, they also create new technical problems when embedded BI architectures don't match product requirements.

Here's what actually happens: You need analytics embedded in your application. You evaluate embedded BI solutions because they promise quick integration—pre-built visualizations, filtering, drill-down capabilities, and permission models from established vendors.

So you implement embedded dashboards. Configure signed embedding with Looker, JWT-based iframes with Metabase, or Power BI Embedded with service principal profiles. Set up row-level security filtering data by tenant. Design authentication flows where your backend generates signed tokens with user claims and expiration. Integrate visualizations into your application UI.

Six months later, you have embedded analytics displaying charts and metrics. You also discover several painful realities:

Performance unpredictability—embedded BI query latency depends on BI tool optimization and data model design, often delivering 2-5 second p95 response times versus sub-second product expectations.

Multi-tenant complexity—row-level security through locked parameters or RLS rules becomes brittle at scale; tenant isolation requires careful token claims, workspace separation, or namespace management.

Limited customization—embedded iframes constrain UI/UX control; theming and styling limitations make analytics feel like "another app" versus native product experience.

Concurrency costs—thousands of users opening dashboards simultaneously creates query storms; embedded BI pricing (per user, per query, per capacity) accumulates unexpectedly.

Caching complexity—pre-aggregations and caching require configuring BI tool features versus product-level API caching strategies.

Real-time limitations—scheduled refreshes (hourly, daily) don't match user expectations for continuously updated metrics reflecting recent events.

Someone asks: "Why does the dashboard load slowly when we have 1000 concurrent users?" or "Can we show metrics updated every second, not every hour?" The answer reveals what embedded BI actually provides—visualization tools, not real-time analytics serving infrastructure.

The uncomfortable reality: most teams building in-product dashboards don't need embedded BI tools—they need real-time analytics APIs serving pre-aggregated data at scale.

This article explores in-product dashboard alternatives—when embedded BI tools solve visualization versus when custom architectures optimize for serving, when semantic layers provide caching versus when real-time platforms eliminate pre-aggregation complexity, and when your actual requirement is analytics APIs rather than embedding existing BI.

1. Tinybird: When Your In-Product Dashboard Problem Is Really an Analytics Serving Problem

Let's start with the fundamental question: are you building in-product dashboards because you need to embed existing BI tools, or because you need to serve analytics at scale within your application?

Most teams considering embedded dashboards have confused visualization integration with analytics serving—they need real-time APIs, not iframe embedding.

The embedded BI versus serving APIs distinction

Here's the pattern: Your team needs analytics in your application. You evaluate embedded BI because it promises quick integration—existing visualization tools embedded through iframes with signed tokens.

That's true for basic embedding. Embedded BI handles charts and filtering.

What it doesn't solve for product-quality analytics:

Sub-second serving latency—embedded BI queries execute through BI tool infrastructure with variable p95 latencies (2-8 seconds) versus consistent sub-100ms API responses.

Real-time data freshness—BI tools refresh on schedules (hourly, 15-minute intervals) versus streaming ingestion making data queryable in milliseconds.

Custom UI control—embedded iframes constrain styling and interactions versus native React/Vue components with complete UX control.

Scalable multi-tenancy—RLS through locked parameters or workspace isolation becomes complex versus API authentication with tenant filtering at query execution.

Predictable costs—per-user or per-capacity BI pricing accumulates with concurrent users versus consumption-based API serving optimized for high-frequency access.

Pre-aggregation orchestration—configuring BI tool caching and pre-computations versus platform managing incremental materialized views automatically.

Embedded BI provides visualization embedding. It doesn't provide real-time analytics serving optimized for product workloads.

One team described their experience: "We embedded Looker dashboards with signed embedding. Performance was acceptable until we hit 500 concurrent users—p95 latency spiked to 8 seconds and costs exploded.

We needed analytics APIs serving pre-aggregated data, not embedded BI queries." This shift toward real-time analytics is also critical for data-intensive applications and Internet of Things (IoT) products that require live, in-app visualization from continuous event streams.

How Tinybird actually solves in-product analytics

Tinybird is a real-time analytics platform that provides APIs serving pre-aggregated data for custom dashboards—the backend powering product analytics without embedded BI complexity.

You stream events from streaming data sources such as Kafka, webhooks, databases, or applications. Tinybird ingests them continuously with schema validation. You write SQL defining metrics and aggregations. Those queries become production APIs with sub-100ms latency serving thousands of concurrent requests.

No embedded BI infrastructure. Build custom dashboards with React, Vue, or any framework consuming JSON APIs versus iframe embedding—perfect for powering real-time personalization in customer-facing analytics.

Sub-100ms API low latency. Columnar storage and incremental materialized views deliver consistent performance regardless of concurrent users.

Real-time data freshness. Streaming ingestion makes events queryable in milliseconds versus scheduled BI refreshes.

Native multi-tenancy. API authentication with tenant filtering at query execution versus complex RLS configuration in BI tools.

Incremental materialized views. Pre-aggregations update automatically as data arrives without manual BI tool pre-computation configuration.

Consumption-based pricing. Optimized for high-frequency API calls versus per-user or per-capacity BI licensing.

One team migrated from Power BI Embedded: "Power BI Embedded worked for initial prototype but couldn't scale to production requirements—latency, costs, and real-time freshness. Tinybird APIs power our custom dashboards with sub-100ms responses serving 10,000 concurrent users. We control UI completely and costs are predictable."

The architectural difference

Embedded BI approach: Integrate existing BI tools (Looker, Metabase, Power BI) through signed iframes or embedding SDKs. Visualization handled by BI; performance, multi-tenancy, and caching depend on BI tool architecture.

Tinybird approach: Real-time analytics APIs serving pre-aggregated data to custom dashboards. Complete UI control, sub-100ms serving, streaming freshness, and automatic materialized view management.

This matters because time to production-quality dashboards is measured in weeks versus months, and operational burden is API consumption versus BI tool configuration and embedding complexity.

When Tinybird Makes Sense vs. Embedded BI Alternatives

Consider Tinybird instead of embedded BI when:

• Your goal is custom product dashboards with native UI control versus embedding existing BI tools
• Sub-second latency with predictable performance for thousands of concurrent users is requirement
• Real-time data freshness (seconds, not hours) matters for product experience
• Multi-tenant serving at scale requires API-first architecture versus BI RLS complexity
• Cost predictability for high-frequency access versus per-user or per-capacity BI pricing

Tinybird might not fit if:

• Your requirement is embedding existing BI dashboards already used internally versus building custom analytics
• Low concurrency internal tools where BI tool performance suffices
• BI tool features (complex visualizations, report builders) matter more than serving performance
• Existing BI investments make migration costs prohibitive

If your competitive advantage requires product-quality analytics serving, real-time data platforms deliver better results.

2. Embedded BI Tools: Looker, Power BI, Tableau, Metabase

Embedded BI tools represent the most common approach for in-product dashboards—integrating existing business intelligence platforms through embedding mechanisms.

What embedded BI tools provide

Major BI platforms offer embedding capabilities with different approaches:

Looker Signed Embedding creates browser sessions for users authenticated in your app—no separate Looker login required with signed URLs and user attributes.

Power BI Embedded provides "app owns data" pattern where application controls access through service principal profiles and RLS, supporting massive scale (100,000+ users).

Tableau Connected Apps uses JWT authentication with specific claims (sub, aud, jti, exp) and 10-minute maximum token expiration for security.

Metabase offers JWT-based guest embedding with locked parameters filtering data by tenant—simpler model with limitations on row-level security and session tracking.

The embedded BI trade-offs

Embedded BI as in-product dashboard solution provides visualization features with performance and customization limitations:

Quick visualization integration—pre-built charts, filters, drill-down capabilities without custom development.

Performance variability—query latency depends on BI tool optimization, semantic layer design, and underlying data warehouse (2-8 second p95 common).

Limited UI control—iframe embedding constrains styling, theming, and UX integration making analytics feel separate from product.

Multi-tenant complexity—RLS configuration, workspace isolation, or namespace management becomes brittle with thousands of tenants.

Scheduled refresh limitations—hourly or 15-minute data updates versus real-time streaming freshness.

Licensing costs—per-user, per-capacity, or per-query pricing accumulates with product usage growth.

When embedded BI makes sense for in-product dashboards

Choose embedded BI tools when:

• Existing BI investment—already using Looker, Power BI, or Tableau internally and want to expose same dashboards
• Complex visualizations—BI tool charting capabilities exceed custom development investment
• Low concurrency—internal tools or limited user bases where performance suffices
• Rapid prototyping—embedding existing dashboards faster than building custom analytics

Embedded BI solves visualization integration. It doesn't optimize for real-time serving at scale—that's where API-first platforms differentiate.

3. Apache Superset: Open Source Business Intelligence

Apache Superset provides open source embedded analytics alternative—self-hosted BI platform with embedding capabilities.

What Superset provides for embedded dashboards

Superset delivers open source BI with embedding options:

Dashboard embedding through SDK or direct links with authentication integration.

Row-level security based on filters assigned to tables and roles as SQL clauses.

Customizable visualizations with extensive chart types and plugin architecture.

SQL Lab for ad-hoc querying and exploration.

No licensing costs—open source Apache 2.0 license versus commercial BI subscriptions.

The self-hosted operational reality

Superset as embedded BI alternative provides open source flexibility with operational responsibility:

Self-managed deployment—infrastructure, scaling, monitoring, and upgrades versus managed BI services.

Limited embedding security—direct links can be accessible to anyone knowing URL; requires careful security design.

RLS configuration complexity—SQL-based filters per table/role become difficult to maintain at scale.

Performance depends on backend—Superset queries underlying databases; optimization requires warehouse tuning.

Community support—active community but no enterprise SLAs versus vendor support.

When Superset makes sense for in-product dashboards

Choose Apache Superset when:

• Open source flexibility and cost optimization versus commercial BI licensing
• Self-hosting acceptable with infrastructure expertise available
• Customization requirements exceed commercial BI capabilities
• Low to medium scale—internal tools or moderate concurrent users

Superset solves open source BI embedding. It doesn't eliminate serving performance optimization or real-time freshness challenges.

4. Cube: Semantic Layer with Pre-Aggregations and Caching

Cube represents semantic layer approach—data modeling and caching infrastructure powering embedded analytics.

What Cube provides as in-product dashboard foundation

Cube delivers headless analytics with pre-computation and caching:

Semantic layer defining metrics, dimensions, and relationships in code (JavaScript/YAML).

Pre-aggregations condensing source data by orders of magnitude—similar to projections that optimize query access paths—queries served from pre-computed datasets when possible.

Multi-level caching with in-memory L1 cache (based on generated SQL) and pre-aggregation L2 cache.

Aggregate awareness analyzing queries and choosing optimal pre-aggregation automatically.

API-first architecture exposing REST and GraphQL endpoints versus BI tool embedding.

Multi-tenant support with data isolation through security contexts.

The pre-aggregation orchestration complexity

Cube as foundation for in-product dashboards provides caching infrastructure with configuration requirements:

Pre-aggregation design—defining which aggregations to maintain based on query patterns and filter combinations.

Refresh strategies—scheduling pre-aggregation updates balancing freshness versus compute costs.

Coverage planning—queries not matching pre-aggregations fall back to source databases with variable latency.

Semantic modeling—maintaining metric definitions, relationships, and transformations as code.

Infrastructure operations—self-hosted deployments require managing Cube instances, databases, and cache layers.

When Cube makes sense for in-product dashboards

Choose Cube when:

• Semantic layer defining metrics centrally provides value across multiple consumption patterns
• Pre-aggregation strategy can cover majority of dashboard query patterns
• API-first architecture enables custom dashboard development versus embedded BI
• Infrastructure expertise available to operate semantic layer platform

Cube solves caching and semantic modeling. It doesn't eliminate the need for real-time ingestion or replace purpose-built analytics platforms.

5. Amazon QuickSight: AWS Embedded Analytics

Amazon QuickSight provides AWS-native embedded analytics with namespace-based multi-tenancy.

What QuickSight provides for AWS ecosystems

QuickSight delivers managed embedded BI within AWS:

Embedded dashboards through QuickSight Embedding SDK with session management.

Namespace isolation separating user groups and identities for multi-tenant applications.

ML insights with anomaly detection and forecasting integrated into dashboards.

SPICE in-memory engine accelerating queries versus direct database access.

AWS integration native connectivity to S3, Athena, Redshift, RDS, and other AWS services.

Per-session pricing or capacity-based subscriptions versus per-user licensing.

The AWS ecosystem coupling

QuickSight as embedded analytics solution optimizes AWS environments with cloud-specific limitations:

AWS-centric—designed for AWS services; multi-cloud or on-premises deployments less natural.

Namespace model—isolates identities but assets (datasets, dashboards) require separate permission management.

SPICE refresh—in-memory cache requires scheduled refreshes; near real-time requires frequent updates.

Customization limits—embedded SDK provides controls but less flexibility than custom dashboards.

When QuickSight makes sense for in-product dashboards

Choose Amazon QuickSight when:

• AWS commitment makes native integration valuable for existing AWS data infrastructure
• Namespace-based multi-tenancy aligns with your application architecture
• Managed service within AWS simplifies operations versus self-hosted alternatives
• ML insights provide value for anomaly detection or forecasting in dashboards

QuickSight solves AWS-native embedded analytics. It doesn't optimize for real-time serving or multi-cloud flexibility.

6. Retool: Low-Code Internal Tools Platform

Retool provides low-code platform for building internal dashboards and tools—different pattern than user-facing product analytics.

What Retool provides for dashboard building

Retool delivers rapid development for internal analytics:

Visual builder with drag-and-drop components connecting to databases and APIs.

Pre-built components (tables, charts, forms) accelerating dashboard creation.

Database integrations connecting directly to PostgreSQL, MySQL, MongoDB, and APIs.

JavaScript customization for logic and transformations beyond visual builder.

User management with SSO and granular permissions for internal teams.

The internal versus product analytics distinction

Retool as dashboard solution optimizes internal tools over product analytics:

Internal focus—designed for employee-facing tools versus customer-facing embedded analytics at scale.

Performance expectations—tolerable latency for internal users versus product-quality requirements for external users.

Limited embedding—primarily standalone tools versus deeply integrated product experiences.

Per-user pricing—cost model suitable for employee counts versus thousands or millions of product users.

When Retool makes sense for dashboards

Choose Retool when:

• Internal operations dashboards for employees versus customer-facing product analytics
• Rapid development and low-code approach accelerates internal tool creation
• Database connectivity to existing systems without custom API development
• Limited user counts—employee-facing tools versus product user scale

Retool solves internal tooling. It's not designed for product-embedded analytics serving thousands of external users.

7. Custom Dashboards: APIs + Charting Libraries

Custom dashboard development with backend APIs and frontend charting libraries represents maximum control approach.

What custom development provides

Building dashboards from scratch delivers complete flexibility:

Total UI control—React, Vue, Angular, or any framework with native product integration.

API design—endpoints optimized specifically for dashboard requirements (pre-aggregated, paginated, cached).

Charting libraries—Chart.js, D3.js, Recharts, Plotly, or any visualization library matching needs.

Multi-tenant architecture—API authentication and tenant filtering designed for your specific requirements.

Performance optimization—caching strategies, CDN delivery, and service worker patterns custom to workload.

Cost control—infrastructure costs directly managed versus BI tool licensing.

The engineering investment reality

Custom dashboards provide flexibility with development burden:

Backend API development—building query endpoints, aggregation logic, caching, and monitoring.

Frontend components—creating charts, filters, drill-down interactions, and responsive layouts.

Data pipeline maintenance—ETL processes, materialized views, and pre-aggregation orchestration.

Operational complexity—managing infrastructure, scaling, monitoring, and incident response.

Feature development time—months to build what embedded BI provides in weeks for basic needs.

When custom dashboards make sense

Choose custom dashboard development when:

• Complete control over UX, performance, and architecture justifies engineering investment
• Product differentiation through analytics UX provides competitive advantage
• Unique requirements—patterns or features unavailable in existing BI tools
• Engineering resources available to build and maintain dashboard infrastructure

Custom development solves maximum flexibility. It requires significant engineering investment versus leveraging platforms or embedded BI.

Decision Framework: Choosing the Right In-Product Dashboard Approach

Start with user requirements

Product-quality analytics serving? Tinybird provides APIs for custom dashboards with real-time freshness and sub-100ms latency.

Existing BI reuse? Embedded BI tools (Looker, Power BI, Metabase) integrate existing dashboards quickly.

Semantic layer needed? Cube provides caching and metrics layer for multiple consumption patterns.

Internal operations tools? Retool accelerates low-code development for employee-facing dashboards.

AWS ecosystem? QuickSight integrates natively with AWS services.

Maximum control? Custom APIs plus charting libraries provide flexibility with engineering investment.

Evaluate performance requirements

Sub-second latency critical? API-first platforms (Tinybird, custom APIs) optimize serving versus BI tool query execution.

Real-time freshness needed? Streaming platforms (Tinybird) versus scheduled BI refreshes (hourly, 15-minute).

High concurrency? API serving architectures scale better than embedded BI query concurrency.

Acceptable latency? Embedded BI (2-5 seconds p95) sufficient for some internal or low-traffic use cases.

Consider operational capabilities

Engineering resources available? Custom development or self-hosted options (Superset, Cube) leverage existing expertise.

Prefer managed services? Embedded BI or platforms (Tinybird, QuickSight) reduce operational burden.

Multi-tenant scale? API authentication and tenant filtering versus BI RLS configuration complexity.

Cost structure? Per-user BI pricing versus consumption-based API serving versus infrastructure costs.

Calculate total cost honestly

Include:

BI tool licensing (per-user, per-capacity, per-query) or platform subscriptions (Tinybird, Cube Cloud).

Engineering time for custom development, BI configuration, or API integration.

Infrastructure costs for self-hosted options or backend services.

Opportunity cost of dashboard engineering versus product feature development.

A platform costing 2x an embedded BI license might deliver 10x better performance with 1/4 the engineering effort—dramatically lower total cost.

Frequently Asked Questions (FAQs)

What's the main difference between embedded BI and custom dashboards?

Embedded BI (Looker, Power BI, Metabase) integrates existing BI tools through iframes or SDKs—quick visualization with limited UI control and variable performance. Custom dashboards build from scratch with APIs and charting libraries—complete control with engineering investment. Tinybird provides middle ground—API-first platform powering custom dashboards without building backend infrastructure.

How do I handle multi-tenancy in embedded analytics?

Row-level security (RLS) filters data by tenant through BI tool configuration or database policies. Workspace isolation separates tenants into different BI environments. API-based filtering applies tenant context at query execution. For scale, API architecture (Tinybird) handles multi-tenancy more naturally than configuring RLS across thousands of tenants.

Can embedded BI handle real-time data?

Limited—most BI tools refresh on schedules (hourly, 15-minute intervals, some offer streaming connectors with delays). For true real-time (second-level freshness), streaming platforms ingesting from Kafka/webhooks (Tinybird) or custom architectures with materialized views deliver better results.

What about costs for embedded dashboards at scale?

Embedded BI pricing (per-user $15-50/month, per-capacity $1000s/month, or per-query) accumulates with product growth. API-based platforms (Tinybird) use consumption-based pricing optimized for high-frequency access. Custom infrastructure has infrastructure costs plus engineering salaries. Calculate based on concurrent users, query frequency, and engineering time requirements.

Should I use Cube or Tinybird for in-product analytics?

Cube provides semantic layer with pre-aggregations and caching—you build query APIs and manage infrastructure. Tinybird provides complete analytics platform with streaming ingestion, materialized views, and instant APIs without infrastructure operations. Choose Cube for semantic layer needs with engineering resources; choose Tinybird for complete platform eliminating infrastructure work.

How do I secure embedded dashboards?

Signed embedding (JWT tokens with user claims and short expiration). Row-level security filtering data by authenticated user/tenant. API authentication with tenant context in requests. Never expose BI credentials client-side or pass sensitive data in URL parameters. Token rotation, HTTPS, and CSP policies are minimum security requirements.

What charting library should I use for custom dashboards?

Chart.js for simple, lightweight charts. D3.js for maximum customization and complex visualizations. Recharts for React applications with declarative approach. Plotly for interactive scientific visualizations. Apache ECharts for feature-rich enterprise dashboards. Choice depends on framework (React, Vue, vanilla JS), visualization complexity, and performance requirements.

Most teams building in-product dashboards discover they're solving different problems.

The question isn't "which embedded BI tool is easiest to integrate?" The question is "do I need to embed existing BI or serve analytics at product-quality scale?"

If your requirement is embedding existing BI dashboards:

Looker, Power BI, Tableau for enterprise BI reuse. Metabase for simpler embedding. Superset for open source flexibility. QuickSight for AWS ecosystems.

If your requirement is internal operations tools:

Retool accelerates low-code development for employee-facing dashboards versus building custom or embedding BI.

If your requirement is semantic layer and caching:

Cube provides metrics layer with pre-aggregations and API endpoints requiring infrastructure management.

If your requirement is product-quality analytics serving with real-time data, custom UI, and predictable performance:

Tinybird solves complete analytics delivery—streaming ingestion, SQL transformations, instant APIs, sub-100ms serving at scale—powering custom dashboards without embedded BI limitations or custom infrastructure complexity.

For maximum control:

Custom APIs plus charting libraries provide flexibility with significant engineering investment in backend infrastructure, data pipelines, and frontend development.

The right in-product dashboard approach isn't the quickest BI integration or most customizable framework. It's matching your actual requirements—visualization reuse, semantic modeling, real-time serving, UI control—with approaches purpose-built for those patterns.

Choose based on what users actually need: if it's embedding existing BI quickly, embedded tools work. If it's product-quality analytics with real-time freshness and scale, API-first platforms deliver better results. Don't confuse visualization integration with analytics serving—they're different problems requiring different solutions.

Remember that in-product dashboards are user-facing product features with expectations matching your application—sub-second responses, real-time data, native UX integration. Evaluate solutions against product requirements, not just BI feature lists.