Brex


Brex is an intelligent finance platform that combines corporate cards, spend management, expense tracking, business banking, and travel into a single product, serving over 35,000 companies globally. As Brex set out to redefine financial reporting for its customers, they needed a foundation that could power AI-native experiences with the accuracy, governance, and scale that finance teams demand.

<video controls width="100%" preload="metadata">
  <source src="https://staticassets.goldcast.io/organization/ec59e10f-fc8c-4594-950b-a2cd4d3aba9c/videos/8f54e8d0-c6f9-4adf-84d6-1daf5f6b9568_prod.mp4" type="video/mp4" />
</video>

### The Challenge: Moving Beyond Static Dashboards

Brex saw that financial reporting across the industry hadn't fundamentally changed in two decades. When a CFO asks "Why is marketing 23% over budget this quarter?", the dashboard shows the *what* but never the *why*. Getting a real answer typically requires filing a ticket, waiting for an analyst to write SQL, validating the output, and pasting results into a slide — a two-second question turning into a two-day project. Brex set out to eliminate that gap for every finance team using their platform.

This created several compounding problems Brex needed to solve:

- **Rigid dashboards, inflexible answers:** Pre-built dashboards are fast but only answer pre-defined questions. The moment a finance leader asks something new, the entire ad-hoc cycle restarts.
- **Bottlenecked data teams:** Analysts spend significant time on repetitive reporting requests instead of strategic work, while business users wait days for answers they need in real time.
- **No interpretation layer:** Charts present data but don't explain anomalies, surface historical context, or recommend what to look at next — the things a senior analyst would naturally do.
- **In-house AI prototype hit a wall:** Brex initially built a lightweight in-house agent on top of self-hosted open-source Cube Core. Maintaining the agent required heavy infrastructure overhead — blue-green deployments, on-call rotations, and reliability work. Their prompt layer ballooned to over 3,000 lines across four files, creating a maintenance treadmill where every new capability risked breaking another.

Brex needed a way to give every customer the equivalent of an embedded AI financial analyst — one that understood Brex-specific concepts like card programs, expense policies, entity structures, and approval workflows — without rebuilding the underlying analytics infrastructure from scratch.

### The Solution: An AI-Native Reporting Stack Powered by Cube

Brex built **Spaces**, an AI-powered workspace for finance teams that delivers insights in seconds rather than days. Underpinning Spaces is a deliberate architectural decision: invest in ontology and semantics before writing a single line of UI code.

After evaluating semantic layer providers including Cube, dbt Semantic Layer, and LookML against AI-readiness criteria, Brex chose Cube and ultimately migrated from their self-hosted open-source deployment to Cube Cloud. The decision came down to three factors: eliminating infrastructure overhead, replacing thousands of lines of brittle prompts with a managed agent, and — most importantly — evaluation results showing that Cube's cloud agent significantly outperformed their in-house agent on data consistency, tool usage, and answer quality.

Cube became the foundation of a three-layer context engineering approach:

1. **The proprietary semantic layer** encodes Brex's financial domain — what "spend" means, how departments roll up, how entity structures map to accounting hierarchies, how compliance thresholds are defined. This is what turns a generic SQL agent into a Brex financial analyst, and what makes Spaces a Brex product rather than a generic BI tool.
2. **Certified Queries** are pre-validated, analyst-approved SQL patterns the AI references for the most common financial questions. Cube's Certified Queries feature lets Brex curate gold-standard logic that the agent adapts from, rather than generating queries from scratch every time — dramatically reducing hallucinations and increasing trust.
3. **Agent Rules** shape behavior at the system level — when to flag anomalies, how to contextualize against historical patterns, how to format insights. Cube's Agent Rules are declarative instructions configured directly in Cube Cloud (with both *Always* rules that apply to every interaction and *Agent Requested* rules the agent invokes contextually). By moving to Cube Cloud, Brex replaced 3,000+ lines of custom prompts with roughly 10 Agent Rules unique to their business, letting Cube handle orchestration, querying, and chart generation.

To ship AI-native reporting to customers with confidence, Brex also built a robust evaluation system on top of Cube. **Online evaluators** run lightweight, deterministic checks for production edge cases — like distinguishing "my travel spend" from "the account's travel spend," or ensuring the agent discovers exact enum values before running SQL filters. **Offline evaluations** use LLMs as judges to score replays across answer quality, chart appropriateness, data consistency, insight relevance, and semantic layer usage. This continuous loop helped Brex raise their insight relevance score from the high 50s to nearly 90%.

<Testimonial />

### The Results: From Charts to Insights, From Days to Seconds

By building Spaces on Cube's semantic layer and AI-native infrastructure, Brex transformed financial reporting from a backward-looking artifact into a real-time analyst experience:

- **Two-day questions answered in two seconds:** Finance teams using Spaces no longer wait for analyst tickets to understand budget variances, spend anomalies, or compliance flags — they get explanations instantly, with charts, context, and recommended follow-ups.
- **Insights, not just data:** Spaces doesn't just visualize numbers — it surfaces anomalies, contextualizes results against history and benchmarks, and explains in natural language what happened, why it matters, and what to look at next.
- **Massive engineering simplification:** By moving from a self-managed open-source deployment with 3,000+ lines of prompt code to Cube Cloud, Brex eliminated infrastructure on-call burden and reduced their custom guidance to roughly 10 Agent Rules configured natively in Cube.
- **Higher answer quality, measurably:** Cube's managed agent outperformed Brex's in-house agent across data consistency, tool usage, and overall answer quality in head-to-head evaluations, while their evaluation system pushed insight relevance scores from the high 50s to nearly 90%.
- **A defensible, multi-tenant foundation:** Brex's investment in proprietary semantics, Certified Queries, and continuous evals creates a product moat that compounds over time — one that scales across thousands of customers, each with isolated data but a shared, governed model.
- **Conversational, refinement-friendly UX:** Internal user testing revealed customers don't want a single answer — they want to refine, filter by date, drill into segments, and compare periods. Cube's semantic layer supports this conversational pattern natively, making Spaces feel less like a dashboard and more like working with an analyst.

Brex's broader takeaway, applicable to any team building AI-native data products: ontology comes before UX, Certified Queries are how you earn trust, and evaluation systems are non-negotiable when customers make real financial decisions on your AI's output. As Brex puts it, the LLM is commodity — the context is the product.


Sign up Now

Brex built Spaces, an AI-powered finance workspace, on Cube's semantic layer. By replacing 3,000+ lines of in-house prompts with Cube Cloud's managed agent, Certified Queries, and Agent Rules, Brex turned two-day reporting requests into two-second insights for every customer.

How Brex built Spaces, an embedded AI financial analyst for 35,000+ customers, on Cube Cloud's universal semantic layer.

Replaced 3,000+ lines of in-house prompts with Cube Cloud — answers in seconds, not days

The future of reporting isn't a chart, it's an insight. Large language models are becoming a commodity — the LLM is the engine, but the semantic layer is the map. A well-modeled ontology is the difference between 'I don't understand that question' and a correct, contextualized answer with a chart and a clear explanation. Cube gives us the foundation to make that real for every customer.

Brex builds an embedded AI financial analyst for 35,000+ customers with Cube

Embedded Analytics

Build consistent, secure, and performant embedded analytics.

Drata


Drata provides an AI-native trust management platform, automating and centralizing governance, risk, compliance, and assurance for thousands of businesses globally, including a third of the cloud 100. As their customer base grew and their data platform matured, Drata needed to deliver real-time insights both internally to their teams and externally to their customers and partners.

### The Challenge: Scaling Analytics and Streamlining QBRs

Drata faced the critical challenge of scaling its analytics capabilities without scaling its team linearly (scaling without adding proportional headcount).

Drata's Customer Success Managers (CSMs) were burdened by time-consuming manual processes:

- __Manual QBR Generation:__ CSMs needed to create data-driven Quarterly Business Review (QBR) presentations for every major account, a process that typically took 2 to 3 hours per QBR. Multiplied across accounts, this resulted in CSMs spending 20 to 30 hours per quarter—almost a full work week—just building presentations.
- __Inconsistent Data:__ The manual process required CSMs to pull metrics from up to five different dashboards, calculate benchmarks by hand, and then format the data into slides and build a narrative. Disconnected data sources often resulted in inconsistent metrics, which eroded client trust.
- __Multi-Instance Management:__ Clients who manage 10 to 20 Drata client accounts (like Managed Security Service Providers) needed a unified dashboard. Previously, they had to log in and out of each account individually to check key metrics, which was exhausting and time-consuming.

### The Solution: AI-Driven Analytics
Drata adopted a dual approach to Cube, using one consistent semantic layer to power two distinct consumption patterns: structured API queries and AI-powered natural language integration. Cube became their single source of truth, providing a consistent, governed foundation for analytics that scales.
Crucially, the success of the AI-powered solution relied on Drata’s investment in an AI-focused semantic layer design. This involved ensuring clear, descriptive dimension and measure names, rich metadata, explicit relationships, and pre-calculating advanced metrics (like segment benchmarks).

> “__Cube becomes our single source of truth for metric definitions and powers everything from customer-facing dashboards to AI-driven quarterly business reviews.__ CSMs gain back dozens of hours each quarter and are equipped with everything they need to deliver intelligent storytelling, enabled by Cube’s semantic layer and agentic analytics. This represents a shift from static reporting to intelligent storytelling.”

— Anthony Cronander, Senior Analytics Engineer, Data

### The Results: Intelligent Storytelling and Time Savings
By leveraging [Cube](https://cube.dev/), Drata achieved significant operational improvements, transitioning from manual effort to automated, strategic insights:

- __Time Savings:__ CSMs get dozens of hours back in a quarter. The previous manual process consumed 20–30 hours per CSM per quarter
- __Shift in Output:__ The workflow creates a shift from static reporting to intelligent storytelling. Cube generates data-driven narratives and insights written in natural language, not just numbers
- __Strategy & Insight:__ Cube surfaces retention risks and expansion opportunities, comparing metrics to benchmarks and identifying outliers
- __Customer Trust:__ Context injection allows Cube AI to prioritize relevant metrics based on customer concerns. The resulting QBRs feel tailored, not templated, demonstrating deep knowledge of each account, which builds trust and guides the relationship to a strategic partnership
- __Scalability:__ Drata can build once and consume many ways (APIs, AI agents, embedded analytics) from a single rock-solid semantic foundation, ensuring consistency across all consumption layers


Drata scaled analytics using Cube’s AI-focused semantic layer as the single source of truth for metric definitions, saving CSMs dozens of hours quarterly and shifting customer success to intelligent storytelling.

CSMs gain back dozens of hours every quarter on QBR generation and customer-facing dashboards

Cube becomes our single source of truth for metric definitions and powers everything from customer-facing dashboards to AI-driven quarterly business reviews. CSMs gain back dozens of hours each quarter, enabled by Cube’s semantic layer and agentic analytics.

Drata scales data-driven decision-making with Cube's semantic layer and AI agents

Business Intelligence

Business Intelligence keeps your data in-sync

Webflow


Webflow is a Website Experience Platform (WXP) that empowers modern marketing teams to visually build, manage, and optimize stunning websites. Webflow’s site builder, CMS, and optimization tools put the power of code in a visual-first front end—where marketing and design can self-serve and engineering can extend with custom code. Webflow has over 300,000 customers in 200+ countries.

Webflow faced a growing need to streamline its data infrastructure. As the company scaled, it became essential to provide consistent data access and interpretation across both engineering and non-engineering teams inside and outside the organization, while maintaining a high level of performance and security. Rocio Delgado, Senior Engineering Manager‬, shares Webflow’s story.

## The Challenge of Providing Consistent, Scalable Access for Internal and External Use Cases
Before Cube Cloud, Webflow's engineering team contended with the challenge of providing scalable, centralized data access, not only for the product they were building but also for various internal analytics. [Webflow’s site usage dashboard](https://help.webflow.com/hc/en-us/articles/33961410031507-Bandwidth-overview) is a customer-facing Analytics dashboard that provides information about bandwidth usage and high-bandwidth pages and assets. 

The data that powers this dashboard, needs to be available internally too for billing and offline analysis. With multiple teams relying on data for both use cases, there was a pressing need for an abstraction layer that could offer uniform data interpretation.

Webflow sought a way to provide query scalability while simplifying data access. The primary goal was to develop a universal semantic layer that could define business logic consistently across the organization. This solution had to be scalable, secure, easy to implement, and cost-effective, while also supporting Webflow’s existing API infrastructure.

## Why Webflow Chose Cube Cloud
Webflow chose Cube Cloud for performance, flexibility, ease of use, and scalability. The decision to implement Cube Cloud was driven by its ability to power real-time data dashboards and its compatibility with Webflow’s tech stack. Cube’s [performance features](https://cube.dev/product/caching-and-data-performance), such as query caching, provided the speed necessary for responsive analytics. 

Webflow successfully integrated Cube Cloud into its infrastructure, pairing it with ClickHouse for high-performance querying. Webflow achieved a p95 of 220 milliseconds using Cube Cloud’s advanced caching capabilities with ClickHouse. Cube Cloud helped the team to ensure streamlined version control and easier collaboration between teams. 

![](https://ucarecdn.com/5915ea8d-1661-4d57-a064-97fef6b0d1ed/-/quality/smart/-/format/auto/)

Additionally, Cube's flexibility with multiple data sources and its ease of use—particularly in defining complex metrics and access through REST and GraphQL APIs—made it the perfect fit for Webflow’s needs. Cube’s [Data APIs](https://cube.dev/product/data-apis) allowed Webflow to easily integrate with various front-end‬ applications and third-party tools. This flexibility has made it easier to build and maintain data-driven applications.‬

> “We integrated Cube Cloud smoothly with ClickHouse, leveraging both for fast query‬ execution while maintaining the abstraction needed for different teams to access data‬ without diving into database-specific complexities.‬”

— Rocio Delgado, Senior Engineering Manager, Webflow

## Webflow Delivers Unified Data with Cube Cloud
Since implementing Cube Cloud, Webflow has seen a marked improvement in data accessibility and governance. Real-time analytics development timelines have been slashed, thanks to Cube Cloud’s architecture and native APIs, which eliminated the need for custom-built API layers. 

Enhanced speed and scalability have enabled Webflow’s teams to focus on innovation without being bogged down by data complexities. Cube Cloud’s universal semantic layer has not only improved Webflow's internal data processes but also empowered the organization to deliver more consistent and efficient data-driven experiences for its users. 

Cube Cloud’s universal semantic layer transformed how Webflow accesses and uses data. By centralizing business logic, it eliminated inconsistencies across teams and allowed for rapid deployment of new data models. The REST API integrations facilitated smooth data flows into Webflow’s front-end applications, simplifying the build and maintenance of data-driven features.


Ready to upgrade your data stack?

Customer-facing site usage analytics and internal billing analysis from one semantic layer

We integrated Cube Cloud smoothly with ClickHouse, leveraging both for fast query‬ execution while maintaining the abstraction needed for different teams to access data‬ without diving into database-specific complexities.‬

Webflow delivers internal and external embedded analytics with Cube Cloud

Alcon


Alcon is the global leader in eye care products. Alcon sought a solution that would provide a unified data modeling and access framework. Their vision was to use conventional dashboards augmented by Agentic AI to enable self-service analytics and drive actionable insights

## The Challenge: Discrepancy, Delay, and Digital Risk

**Alcon, like many large enterprises, faced challenges stemming from pervasive dashboards and complex data structures:**

- **Metric Inconsistency:** The same KPIs and metrics could have different definitions and calculation methodologies across various teams, leading to discrepancies and confusion.
- **Generative AI Risk:** Due to complex data schemas with many databases, tables, and fields, implementing GenAI posed a high risk of error and hallucination. Alcon also needed to maintain strict compliance with regulations like HIPAA and GDPR, requiring robust security
- **Slow Time-to-Value:** Users constantly requested questions that existing dashboards could not answer. Submitting new development requests, even using an Agile process, resulted in slow intake, development, and deployment cycles

## The Solution: Cube's Unified Semantic Layer and Agentic Analytics Platform

The selection of **[Cube Core](https://cube.dev/product/cube-core) as their semantic layer provider** was based on four core capabilities that aligned directly with Alcon’s requirements:

- **Access Control:** Cube enforces centrally managed data security and role-based access necessary for a highly regulated environment
- **Centralized Data Model:** Cube facilitates the centralized definition and management of business logic and KPIs
- **Caching:** Cube minimizes repetitive queries into the data lake/warehouses, performing aggregation to achieve faster performance
- **APIs:** Cube’s APIs allow seamless integration with downstream BI tools and, critically, with the Cube Agentic Analytics platform

![](https://lgo0ecceic.ucarecd.net/71abc7c1-8041-46e7-8d82-6ae77415a0f2/)

By implementing Cube, Alcon defined multiple logical data representations—**Cubes** (for accounts, products, orders, etc.) and **Views** (logical combinations that expose data fields)—to centralize metric management and calculation definitions in one place

> “__Semantic SQL is a wonderful thing – it's really at the heart of the semantic layer.__ 
Without Cube’s semantic SQL, our data analysts might have to write 20 different queries for a single core business metric. With Cube, that metric is defined once in the data model, and every downstream tool uses that definition along with the associated calculation logic.”

— Dr. Jun Huang, Global Head of Data Science for Digital Health, Alcon

## The Impact: Governance, Trust, and Accelerated Insights

Implementing Cube’s semantic layer and the [Cube platform](https://cube.dev/product/cube) delivered immediate benefits, enabling semantic governance in action.

- **Consistency and Trust:** The unified definitions provided by Cube ensure that data consumers receive consistent results. When testing the new system, the GenAI chatbot's responses to KPI questions matched exactly what was displayed on the existing Tableau dashboard. This consistency ultimately built user trust
- **Reduced Development Effort:** The Agentic AI complements the dashboard, allowing users to ask questions beyond the dashboard's scope. This capability reduces the need to develop as many dashboards as before
- **Improved Governance for AI:** The well-constructed semantic layer brings the correct context to the AI agents, significantly reducing the risk of hallucination. Furthermore, Alcon uses the Agentic Analytics platform to set rules, ensuring the agent only provides responses using approved metrics, adding a necessary level of control


Alcon leveraged Cube's semantic layer and Agentic AI to overcome metric inconsistency and AI risk in global operations. Cube enabled consistent, fast self-service analytics that answers questions beyond dashboard scope

Consistent self-service analytics across global operations, with GenAI grounded in the semantic layer

Without Cube, our data analysts might have to write 20 different queries for a single core business metric. With Cube, that metric is defined once in the data model, and every downstream tool uses that definition along with the associated calculation logic.

Alcon transitions from dashboards to dialogue with Cube's agentic analytics

SecurityScorecard


## SecurityScorecard Launches Embedded Analytics

[SecurityScorecard’s](https://securityscorecard.com/) mission is to make the world a safer place by transforming the way organizations understand, mitigate, and communicate cybersecurity risks to their boards, employees, and vendors. Today, thousands of organizations leverage SecurityScorecard’s patented rating technology for self-monitoring, third-party risk management, board reporting, and cyber insurance underwriting.  

In order to achieve their mission and continue to serve their customers, SecurityScorecard constantly invests in new functionality that improves the customer experience. One such project was focused on analytics - reporting and dashboard capabilities - that they could offer customers within the product. 

## Evaluating and Delivering Embedded Analytics

Benja, VP of Engineering, knew that it was of utmost importance to deliver an embedded analytics solution that could handle their huge datasets without sacrificing speed - and to do it quickly. 

To start, the team evaluated the embedded analytics capabilities of both Sisense and Looker. Frustrated with the lack of transparency of the Looker team and impressed by both Sisense’s demo and the attentiveness of their support team, Security Scorecard moved quickly to sign with Sisense. 

After the contract was signed and they began work, however, it quickly became clear that Sisense was not going to provide what they needed. The Sisense team was very hands-on and helpful, but nevertheless, there were issues that surfaced that couldn’t be resolved.  In addition, the developer experience was clunky and made it difficult to work efficiently. The team also heard from another Sisense embedded analytics customer that they needed a team of 10  engineers working on Sisense directly. SecurityScorecard didn’t want to spare that many resources just to make it work.

### Discovering Cube Cloud and Quickly Getting to Work

As he was considering what to do with their Sisense deployment, Benja heard about Cube Cloud and within a few short weeks was able to do a proof of concept and get hands-on with the product. He experienced how easy it was to onboard, a short learning curve, as well as a much more robust developer experience. Having tried to fit Sisense in for their embedded analytics solution first, Benja appreciated the “headless BI” architecture that allowed them to decouple their semantic layer from their visualization layer. Observable was chosen as their visualization layer and they were ready to move forward. 

Marcus, Engineering Manager, took over the project and appreciated how easy it was for him to ramp up and understand Cube Cloud. 

> “We were under a tight deadline to get off Sisense. But I was able to pick up what had been done already just by looking – without having to read any documentation. The Cube UI is very intuitive.”

**It took just 2 months to implement all six of our dashboards with Cube Cloud and Observable and the team has been using Cube Cloud now for a year and a half.** 

## Cost-savings, Faster Development, Reducing Latency

When they were switching to Cube Cloud, they were told by other vendors that there would be a higher operational cost. However, that never materialized and in fact “the swap from Sisense reduced our total infrastructure cost by 60%” said Benja.

Once Cube Cloud was up and running, they realized how easy it was to release new dashboards and analytics. Before Cube, said Marcus, “It was easy to create a new data model, but working with actual data was a challenge. The team that made those endpoints available were always swamped with other tasks. Now with Cube, as long as the data is available in Snowflake, we can run queries ourselves. The real issue was that we didn’t have endpoints before and now, with Cube, we do. Cube unblocked that bottleneck for us.”

Over time, they found that “the cycle time for implementing new analytics and reports went from roughly 1 quarter to under 2 weeks in most cases” said Benja.  

> “We addressed multiple security concerns (caused by first trying embedded analytics with Sisense) given Cube's flexibility for custom access control, and the freedom to implement proper browser session security.” - Benja

In some cases, before Cube Cloud, the latency with embedded analytics was “so high that reports were just impossible to attempt” said Benja. With Cube, we reduced latency on those reports because of the flexibility provided by the headless BI architecture. Lately, the team has been working on adding more pre-aggregations. Marcus shared the “Gradual systematic work that we do with the Cube team to find the queries we want to optimize. Then we pre-aggregate and see the results.”

> “It was a really big improvement. We reached faster performance for some queries. Even better, pre-aggregations reduced the number of requests to Snowflake by 2x which translated into a big savings on our Snowflake consumption.”

Overall, SecurityScorecard continues to benefit from Cube Cloud in improving the performance of queries, reducing latency, and ease of development. Cube also delivers value in being agnostic to data source and visualization layer. SecurityScorecard is considering moving from Observable to building their own custom visualization with React or similar libraries. They are also considering whether Snowflake is the right choice and trying out different cloud data warehouses. Because of Cube Cloud, they can easily move different tools in and out of their data stack - both on the visualization layer and the data source layer - while holding Cube as the underlying unifying semantic layer. 

If you want to learn more about how Cube Cloud can deliver a semantic layer for all your data needs, please visit: [www.cube.dev/contact](www.cube.dev/contact).


Sign up for Cube Releases and Updates

SecurityScorecard implemented Cube Cloud for embedded analytics and have seen faster performance of queries, reducing latency, ease of development and cost savings on Snowflake costs.

Lower latency, easier development, and 2x lower data-warehouse spend

With Cube, we’ve been able to speed up time to release a new data model to production by 5x and decrease analytics downtime by 90%.

Cloud Academy

SecurityScorecard halves Snowflake costs with faster embedded analytics on Cube

Jobber


[Jobber](https://getjobber.com/), the leading provider of business management software, helps small home service businesses stay organized, connect with customers, grow revenue, and better compete against large corporations. The company's technology supports more than 50 industries, including HVAC, plumbing, lawn care, cleaning, and more. Since launching in 2011, businesses using Jobber have serviced over 15 million households in more than 47 countries. 

![zeisler-quote.png](https://media.graphcms.com/Jiqz2GcDRliDe6QP8E7T)

One of the important tools for Jobber's customers is dashboards that can provide a snapshot of what's happening in their businesses to schedule their day, optimize routing, keep track of invoices, accept payments, and more, even when people are not in traditional brick and mortar offices. Today, more than 100,000 service professionals use Jobber's platform and rely on it to stay on top of—and grow—their businesses.

![Untitled.png](https://media.graphcms.com/NWbbXWdWRym4mvp56NA3)

In the past, the Jobber team was retrieving information by doing direct queries against a production database from their Ruby on Rails application through [Active Record](https://guides.rubyonrails.org/active_record_basics.html) ORM. However, as their business scaled and with close to a decade of data, the dashboard performance started to get slower. The team worked on things like caching, query optimization, and database tuning to address performance issues but realized that more needed to be done.

![weinrich-quote.png](https://media.graphcms.com/wHVLFnwNRBC2SnfSQz37)

## How Jobber is using Cube

When Jobber first discovered Cube, they started studying the documentation and examples and liked the flexibility. The Jobber team also liked the [two-level caching](https://cube.dev/docs/caching#top) system in Cube as they previously had to implement a lot of that with their own code. Now they simply use Cube almost as a black box that they communicate with and can remove the optimization code they had to maintain in the past. Jobber's first use case with Cube was using daily [rollup pre-aggregations](https://cube.dev/docs/pre-aggregations#rollup) with the two-level caching. 

Another important and timely feature was the [external pre-aggregations](https://cube.dev/docs/pre-aggregations#external-pre-aggregations) capability of Cube. With their source database being a read-only database replica, building the pre-aggregations inline within the source database wasn't an option.

![weinrich-quote](https://ucarecdn.com/c05b62e3-2bcb-4792-9c10-b2c57d9f7731/-/quality/smart_retina/-/format/auto/)

As you can see in the architecture diagram below, Jobber has a single PostgreSQL database backend, and they recently started using React for the frontend. Jobber has a read-only replica of the database to populate the rollup pre-aggregations database and wraps the Cube REST API with their own API for handling things like authentication (Cube is a trusted sub-system in this configuration). Jobber also leverages [multitenancy](https://cube.dev/docs/product/configuration/advanced/multitenancy) with a query transformer to enforce at runtime that all data queries filter to the authenticated tenant. Other security features include full [certificate verification](https://cube.dev/docs/connecting-to-the-database#enabling-ssl) for database connections.

![Jobber-Conceptual Architecture](https://ucarecdn.com/eb6536d5-557d-4843-bb5e-fcece383eb65/-/quality/smart_retina/-/format/auto/)

Splitting Cube like this—an API server which handles the queries and a scheduled refresh server which updates the pre-aggregation rollups periodically—required leveraging some special configuration options for the orchestrator:

- **API Server**: Uses `CubejsServer` but configured so that it will only respond with data from the rollup pre-aggregations database even if queries attempt to access data outside of the available rollups (`rollupOnlyMode: true`), and additionally, should skip the consistency checks and background refreshing of the rollups (`externalRefresh: true`).

```jsx
orchestratorOptions: {
  preAggregationsOptions: {
    externalRefresh: true,
  },
  rollupOnlyMode: true,
},
```

- **Scheduled Refresh Server**: Uses `ServerCore` (no need to run a web server here!) to execute `runScheduledRefresh` repeatedly (with a five-second cooldown) until the rollups have completed refreshing. Note that leveraging a read replica requires setting up `readOnly: true` on the `driverFactory` configuration.

Jobber's architecture could be a viable option in their environment for anyone who is querying production databases (vs. querying some big data data sources).

## Deploying, testing, and including Cube into the CI pipeline

There were several team members at Jobber that were involved in Cube development and included two developers, one designer, and a product manager. The team initially used Cube out-of-the-box and utilized the Cube Developer Playground extensively, with a few additional refinements, such as converting the auto-generated project to TypeScript. Jobber uses Docker for their development environment, and they surface the Cube microservice in a container. 

The Jobber team also developed tests for things like additional schema validations on their CI build. One of the things the team ran into early on was the table name truncation that tends to happen with PostgreSQL. So one of their tests actually asks Cube what table names it's going to generate, and if the table name is longer than what PostgreSQL allows, the test will fail early in the CI process. 

The Jobber team also did two rounds of performance testing. First, the team wanted to understand where the bottlenecks for Cube were (e.g., CPU vs. memory) when saturated with incoming requests and observed how it responded while ramping up simulated concurrent requests.

In the load test graph below, you can see how their test showed signs of achieving maximum throughput (for the given server configuration), with response times (blue) starting to get shaky as the number of concurrent requests (yellow) ramps up. This particular test was getting 100% Redis cache hits, and the bottleneck was the CPU.

![Untitled-2.png](https://media.graphcms.com/pxNLuyThRTi0rC29dC5U)

Next, they used simulated traffic in the frontend to mimic actual customers' traffic (and data requests) more accurately and began experimenting with different scaling options (vertical and horizontal). This allowed them to observe more complex performance characteristics because both caching tiers were getting exercised.

Once on beefier servers, the CPU was no longer the bottleneck, and the next bottleneck encountered was related to memory! This manifested in a runaway memory ramp (at a certain amount of traffic) where Node.js would consume all the available memory and eventually pause the entire runtime for several seconds to run a "mark sweep" style garbage collection.

![Untitled-3.png](https://media.graphcms.com/gjZl4ZejQhKsr1EdrTyA)

After some research into how Node.js' memory configuration works—[it's complicated](https://github.com/v8/v8/blob/2b17c752d117bf0ededd23206bb38b69e641a976/src/heap/heap.h#L1106-L1136), often described incorrectly online, and changed between versions 10 and 12—the Jobber team optimized the usage of the server resources by [running concurrent copies](https://devcenter.heroku.com/articles/node-concurrency) of the Node.js process using a library called [throng](https://www.npmjs.com/package/throng).

The graph below shows the service's response time shape over three days. You actually see that each day, as the traffic starts increasing up to the peak volume (represented as the vertical white lines), the Cube response time actually goes down (almost counterintuitively). This is because the first hit of the day is going against the rollup pre-aggregations database (level 2), but subsequent looks at the dashboard hit the faster query result cache in Redis (level 1).

![Untitled-4.png](https://media.graphcms.com/P8MVx2q6QGu2YYlANt5n)

## Contributing to Cube

Jobber's team was also very active contributors to Cube and in many ways co-developers as they were evaluating and deploying Cube. This [GitHub query](https://github.com/search?l=&q=repo%3Acube-js%2Fcube.js+author%3Ajcw-+author%3Acolefichter+state%3Aclosed&type=issues) shows contributions from two team members at Jobber. They actually only show contributions via pull requests and don't include Slack or other channels.

This type of active engagement from users clearly demonstrates the value of open source. The contributions help accelerate development and, more importantly, provide valuable insight to the Cube Dev team on actual use cases in production environments.

![klotz-quote](https://ucarecdn.com/ecdef370-fcb3-4ad7-88c5-f328366d7973/-/quality/smart_retina/-/format/auto/)

If you want to see Cube in action today at Jobber, you can visit the [Jobber's Help Center page](https://help.getjobber.com/hc/en-us/articles/360051851213-Home#h_01EDPE0KKPBMDHE96TF3DXCAD9). In the screenshot below, Cube.js is used for the four line-series charts.

![sidenavClosed.png](https://media.graphcms.com/flj48F6LShyE6kDpNVGU)

After the successful deployment, the Jobber team is continuing to explore other areas where Cube can reduce engineering costs while delivering great features for their customers.

## Interested in joining Jobber's success with Cube?

Explore Cube [examples & tutorials](https://cube.dev/docs/examples) and [get started](https://cube.dev/docs/getting-started) today. To jumpstart your efforts, please join us on [Discourse](https://forum.cube.dev/) & [Slack](https://slack.cube.dev/), follow us on [Twitter](https://twitter.com/thecubejs), and get engaged with the growing Cube community.


How Jobber uses Cube to help customers run their businesses with high performance dashboards using Cube to speed up embedded analytics development

High-performance dashboards inside the home-services SaaS used by thousands of pros

Cube really stood out as a great fit for our use case. We were able to level‑up our data infrastructure without needing to build a full‑blown and expensive data pipeline.

Jobber accelerates embedded analytics development with Cube


## What is Cloud Academy?

[Cloud Academy is a leading e-learning platform for enterprises](https://cloudacademy.com/) looking to teach, refine, and develop a workforce’s technology skills. As a part of the UK-based learning and development company, __QA__, the platform offers learners a customized experience based on their trajectory, proficiency, and role. With technical subjects such as cloud computing, software development, DevOps, and security, users take assessments and then are given access to courses and hands-on labs tailored to their current skills. 

## Deliver Better Performance for Embedded Analytics

Back in 2021, QA was struggling with delivering a great analytics experience to their customers. They had integrated a well-known BI tool into their Cloud Academy learning platform and were unsatisfied with the results. The platform was offline too often, adding new elements and modeling the data was slow and inefficient, and the interface didn’t seamlessly integrate into their product as they would have liked. Alessandro Lollo, Data Engineering Manager was committed to delivering a product with CI/CD principles - continuous integration and continuous delivery/deployment - and the BI tool they had integrated was not living up to their standards. 

### Cube Cloud: Easier to use and more secure for embedded analytics 
It took about a month to integrate Cube Cloud into the Cloud Academy platform and then, in less than 3 weeks, they delivered their first Cube-based [embedded analytics](https://cube.dev/use-cases/embedded-analytics) app to enterprise customers with a data visualization experience that was seamlessly integrated into their product. 

### Flexible data modeling and pre-aggregation for speed
The team appreciated Cube’s flexible data modeling framework as it made it easier to use their existing data warehouse and much faster to maintain, update, and add elements to their data models. Cube’s fully managed pre-aggregation capabilities allowed them to boost the response times of complex data models and improve their customers' experience. 

### Developer tools for the Data Engineer
Alessandro was happy with Cube Cloud’s developer toolkit that allowed for easy collaboration and Git-integration that delivered a smoother development process - as well as the zero downtime of the fully-hosted solution. Of course, security is paramount to Cloud Academy, and Cube Cloud’s virtual private cloud (VPC) and VPC peering capabilities in addition to the security context orchestration and role-based access controls allowed Cloud Academy to maintain their high standard of security. 

### Cube Cloud: 5x increase in speed; 90% less downtime
All-in-all, Cloud Academy was able to speed up releases of new [data models](https://cube.dev/product/data-modeling) into production by 5x while decreasing their platform’s analytics downtime by 90%. But the biggest benefit came over time, as Lollo and his team realized that with the new more tailored, and integrated user experience, more users were taking advantage of these analytics features.

> “With Cube, we’ve been able to speed up time to release a new data model to production by 5x and decrease analytics downtime by 90%.” —Alessandro Lollo, Senior Data Engineer 

## Expanding Cube Cloud to Deliver Data Insights Everywhere

After finding success with their customer-facing analytics, QA’s Cloud Academy team began to turn their attention to internal stakeholders realizing that Cube Cloud’s [semantic layer](https://cube.dev/use-cases/semantic-layer) could potentially provide the security orchestration they needed to provide internal stakeholders with insights into how their product was being used: course consumption, learning paths, and key metrics related to the recommendation system. And everyone wanted access to these insights: product, marketing, sales, executives, and other teams that wanted to leverage this data to make key business decisions.

### Protecting user data was paramount: Cube Cloud delivered

Cube Cloud’s robust [security tools](https://cube.dev/product/semantic-layer-security) and capabilities were the key to allowing Cloud Academy to share these insights with internal stakeholders while protecting their users' personal data (PII) - of utmost priority for Cloud Academy. With Cube's powerful security context features, Cloud Academy could mask or restrict access to certain fields, depending on which users are accessing data. Additionally, in a multi-tenant reporting use case, Cube’s row-level security is paramount to ensure that external users don't accidentally see unintended data. These complex user and data access control requirements made Cube Cloud the perfect fit.

### Developing and delivering faster with Cube Cloud
As before with embedded analytics, Lollo and team appreciated the developer tools and Git-integration that allowed for collaborative development. In particular, the automated testing features that made it easy for the Cloud Academy team to develop and launch new use cases quickly. In fact, the process was so easy that Lollo estimated they could now go from idea to final result 70% faster than before. 

> “The total time we have to spend between the idea of building a cube or an analysis and delivering to end users is 70% faster than before.”—Alessandro Lollo, Data Engineering Manager

## The Future of Cloud Academy’s Semantic Layer

Today, the Cloud Academy data team has Cube Cloud integrated into their customer-facing product and is delivering [product and usage insights to internal teams](https://cube.dev/use-cases/connected-bi) using Apache Superset. But there are more opportunities on the horizon as Lollo considers having Cube Cloud deliver to Hex for additional data exploration.

Cube Cloud’s flexibility leaves Lollo and his team with plenty of room to play and imagine what the future could entail. *“I can imagine analysts merging data coming from Cube and maybe attaching some other type of exotic or fancy data coming from - I don’t know!”*

> “Our analysts have all the freedom they want to store data and do prototyping, but there may be some use cases where they need additional tools. Using the semantic layer here ensures well governed and well defined data, as well as proper access controls.”

Here at Cube, we can’t wait to find out how QA moves forward with this new understanding of the data on their Cloud Academy platform.


Cube Cloud’s robust security tools and capabilities were the key in allowing Cloud Academy to deliver data insights faster to internal stakeholders while also protecting their users personal data (PII) - of utmost priority for Cloud Academy.

5x faster data modeling and 90% less analytics downtime

Cloud Academy delivers data insights 70% faster with Cube Cloud's semantic layer

Pressboard


Founded in 2014 and acquired by impact.com in 2022, Pressboard provides tools that empower content creators, brands, and media companies to measure, promote, and report on their content. Its platform enables businesses to measure audience engagement through tools that assess sponsored content, social media campaigns, and eCommerce performance. 

Pressboard also provides detailed metrics like scroll depth and active reading time, along with automated, shareable reports to streamline client workflows. Additionally, the platform supports campaign execution and analysis, making it a comprehensive solution for content marketers. Pressboard has become a trusted partner for many of the top media companies worldwide.  

## Facing Mounting Data Challenges
David Richards, Pressboard’s Director of Engineering, faced mounting challenges in managing the company’s growing data infrastructure. As a small team supporting a highly customized, embedded analytics solution, developers were often bogged down creating bespoke solutions for each client. Every new feature or visualization required tailored SQL code and unique endpoints, resulting in a significant developer backlog.

The lack of a unified semantic layer created additional hurdles. Developers spent excessive time ensuring data accuracy and consistency across reports, leaving little room for innovation. Workflow inefficiencies also hindered Pressboard’s ability to respond to client needs quickly, while performance issues with SQL Server strained the platform’s ability to deliver fast, reliable reporting as the customer base expanded. These obstacles not only impacted developer productivity but also created friction for customers relying on the platform to make data-driven decisions.

## Choosing Cube as the Solution
To address these challenges, Pressboard explored several solutions, including Microsoft SSAS and Power BI Embedded Analytics. However, these tools lacked the flexibility and scalability required for a multi-tenant, customizable application. After considering building an in-house semantic layer solution, the team discovered and began using Cube Core. 

Cube offered several key advantages that made it the ideal solution for Pressboard’s needs. Its code-first approach allowed for seamless integration with the company’s existing tech stack and an Angular-based embedded analytics solution for customer-facing dashboards. Cube’s robust support for multi-tenant data controls enabled Pressboard to enforce complex permissions while consolidating all client data into a unified, logical database. Additionally, Cube’s pre-aggregations improved query performance, reducing strain on SQL Server and ensuring faster, more reliable reporting.

Pressboard’s implementation journey involved transitioning from Cube Core to Cube Cloud as the team sought to reduce the overhead of managing their own infrastructure. Initially, performance issues arose when pre-aggregations caused heavy load on SQL Server. However, switching to SingleStore resolved these issues with minimal disruption. The migration process was seamless, requiring only minor adjustments to query patterns to accommodate SingleStore’s MySQL compatibility.

![](https://ucarecdn.com/b41301ab-464b-4732-aed0-5eb16c1e8b43/)

Cube’s universal semantic layer integrated seamlessly with Pressboard’s data infrastructure. By centralizing data access and storing query configurations, the team simplified reporting and improved data governance. This setup enabled developers to focus on delivering new features rather than managing data pipelines.

## Delivering Impactful Results
The adoption of Cube’s universal semantic layer had a transformative effect on Pressboard’s data operations. Developer productivity improved significantly, as the need for custom SQL queries and bespoke endpoints was drastically reduced. Performance gains from pre-aggregations allowed the platform to deliver fast and consistent reporting, even as the customer base expanded.

By consolidating client databases into a single logical instance, Pressboard improved data governance and security while maintaining the flexibility to enforce complex permissions. This streamlined approach not only enhanced operational efficiency but also elevated the user experience. Cube’s flexibility enabled Pressboard to expand its Widget Builder functionality, allowing clients to create custom charts, dashboards, and reports that aligned with their branding.

An unexpected benefit of Cube’s implementation was the ability to develop industry and client benchmarks. The platform also empowered non-technical stakeholders to perform ad-hoc data analysis, further increasing the platform’s value and stickiness. Additionally, the introduction of data exports in CSV and Excel formats expanded use cases for clients, making the solution more versatile and appealing.

Clients have responded positively to Pressboard’s enhanced analytics platform, praising its customization options and user-friendly interface. The improved consistency and accuracy of reports have built greater confidence among users, who are now more engaged with the platform. These enhancements have also increased customer loyalty, making the product an indispensable part of their workflows.

## Evolving Pressboard’s Data Strategy with Cube Cloud
Pressboard’s adoption of Cube’s universal semantic layer has transformed its data infrastructure, enabling the company to overcome significant operational challenges. By streamlining workflows, improving performance, and enhancing the user experience, Cube has positioned Pressboard for sustained success in a data-driven world. With these foundational improvements in place, Pressboard is now focused on expanding its offerings and delivering even greater value to its customers.

As Pressboard continues to grow, the company plans to evolve its data strategy by adopting a Data-as-a-Service model. By exposing APIs, Pressboard aims to provide clients with the flexibility to consume data through their preferred BI tools and spreadsheets. This vision underscores the company’s commitment to empowering customers with seamless access to reliable, actionable insights.

## About
Founded in 2014, Pressboard empowers the world’s top publishers to manage, measure and report on sponsored content, native advertising, eCommerce, social media, and more in a single dashboard. Branded content teams rely on these tools not only to improve their efficiency, but also to delight their brand clients and drive repeat campaigns.

Founded in 2008, impact.com transforms the way enterprises manage and optimize all types of partnerships. In 2022, impact.com acquired Pressboard to further their goal of revolutionizing how brands, advertisers, and publishers forge meaningful content partnerships and connect with their consumers.


Replaced bespoke SQL endpoints with a unified semantic layer inside impact.com's content-measurement product

Pressboard rebuilds data operations on Cube's universal semantic layer

Breakthrough


## Customer-facing dashboards that load in 2 seconds

[Breakthrough](http://Breakthroughfuel.com) is a leading provider of sustainable fuel and freight solutions for shippers that reduce cost, create efficient networks, and decarbonize transportation. All their product offerings analyze vast datasets to offer optimization strategies for reducing transportation fuel spend, carbon footprint, and freight spend. With large enterprise customers, such as Unilever and Danone, relying on their products, they need to address many different types of customers. With both a SaaS application and service-based product offerings, Breakthrough’s data stack needs to allow for both self-serve capabilities and tools for professional analysts.  

![Breakthrough Embedded Dashboard](https://ucarecdn.com/d776193b-9f1b-4a62-8820-c793179b4df9/-/quality/smart/-/format/auto/)

## The Need for Speed
A few years ago, the Breakthrough team built the analytics for one of their products on top of very custom SQL hitting a Postgres database “that would crawl with these analytical queries,” said Juan Muñoz, Chief Technologist at Breakthrough. Muñoz knew they needed to re-platform the solution to get the performance they required, so they tested out Cube in a proof-of-concept, “We figured out: Yes, we can do this now. This will solve all our issues.” Once the solution was tested, the real work began, and the team rewrote the product with Cube as the semantic layer and both Preset and their own visualization framework on the front-end.

## The Semantic Layer Architecture Revolutionizes The New Stack
Today, clients send data on their truckload movements, which Breakthrough then enriches. This part of the data pipeline, called Load Processing Pipeline, is written in Data Flow in Google Cloud Platform (GCP). Then the data gets dumped into Google BigQuery where dbt picks it up and does more auditing. Finally, data is sent through Cube, the [semantic layer](https://cube.dev/use-cases/semantic-layer), to the front-end framework that Breakthrough developed in React with their own visualization toolkit including sliders, date pickers, and other useful widgets all mapped to Cube queries. For their service-based product offerings, the data is visualized in Preset where the Breakthrough team has more capabilities to do additional analysis.

To help serve all the different client needs, Breakthrough provides many different data experiences. For those who want to dig into the analytics, they have dashboards that allow for slicing and dicing the data in many ways. For others that just want answers, they have built machine learning that will recommend actions and optimizations based on the analysis. Breakthrough's consulting-focused services are the primary user of Preset dashboards for their personalized analysis for their [clients that can go even deeper into analyzing the data.](https://cube.dev/use-cases/embedded-analytics)

## The Semantic Layer Underneath is A Single Place to Create Metrics
All the different data experiences are supported by Cube - the semantic layer underneath it all. “In just one place, we can define and share metrics across both our SaaS app and our service-based products. The metric only has to be implemented once. That’s a huge value to us.”  

> “We no longer have to embed all the calculations everywhere and have gotten rid of the tedious copying and pasting of all the code and formulas. Now it’s all in one place. And that has allowed us to grow.” 

That growth and scale comes in many different forms. With their new data stack and Cube in the center, they can now add new visuals “super fast.” Before Cube, the team would have to change the database query, the resolver, the UI, and effectively the whole stack to add new data or visuals. 

> “We had one request that was scheduled for a month of work. Once we implemented Cube we did it in just a few days. That speed of turnaround happens because we’ve separated out a shareable data asset that can be recombobulated with our visual assets. That was a huge performance win for us in terms of development. The time to release new features and visuals decreased significantly - from months to just days.” 

With this new data stack with Cube as the semantic layer, query performance has greatly improved. Breakthrough is able to [get more people onto the platform with a much faster experience](https://cube.dev/blog/sub-second-query-performance-for-data-apps). “It’s super speedy. We’ve seen a great improvement in load time.” 

## Looking to the future - The meaning of a semantic layer
“The new Cube architecture allows us to build a sliceable cube of data, put Cube on top of it, and eliminate rework. It’s a huge architectural win for us.”

Now that they’ve seen success with their products, the team plans to extend Cube to all of their other core products in addition to pushing out more features, charts, graphs, and other ways to experience data. They’ll be doing more machine learning to analyze pricing and other optimizations - all analytics backed by Cube - as well as extending more capabilities across all their product lines. 

> “Having that semantic layer that can serve not just a BI tool, not just an application, but both - so I can have the team model our business in one spot and have it available in multiple places has allowed us to grow and scale our products much faster than ever before.”


Using the Cube’s universal semantic layer with Google BigQuery, Preset, and React, Breakthrough has greatly improved the performance of embedded dashboards and reduce the time required for dashboard development.

BigQuery, Preset, and React stack ships faster with better performance

Breakthrough speeds embedded dashboard development with Cube's universal semantic layer

The Linux Foundation


## Empowering Open Source Communities with Data Insights

The <a href="https://www.linuxfoundation.org/" target="_blank" rel="noopener">Linux Foundation</a> (LF)  is a leading non-profit organization established in 2000 to support Linux development and open-source software projects. In addition to providing a neutral home where Linux kernel development can be fostered, the LF is dedicated to building sustainable ecosystems around open-source projects to accelerate technology development and encourage commercial adoption. With over 900 open-source projects as part of its portfolio, the LF plays a crucial role in the global open-source community, hosting major events like the <a href="https://events.linuxfoundation.org/open-source-summit-north-america/" target="_blank" rel="noopener">Open Source Summit</a> and <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/" target="_blank" rel="noopener">KubeCon</a> to foster collaboration and innovation.

##### Caption: Linux Foundation’s Insights tool - an open-source project analytics tool that empowers users with valuable data-driven insights with the help of a semantic layer

![Linux Foundation Embedded Analytics Dashboard](https://ucarecdn.com/0f76feef-34fa-4330-9969-5124c5b5cefc/-/quality/smart/-/format/auto/)

## From Data Overload to Optimized Efficiency
Before partnering with Cube, the Linux Foundation faced challenges with their data stack's complexity and performance. Rudy Grigar, Director of Cloud Services at the Linux Foundation, explained, “We have lots of places where data lives at the Linux Foundation, anywhere from Google Sheets to Hubspot to Crowd.dev,” making it difficult to standardize and visualize data efficiently. Initial solutions were either too slow or too costly, prompting them to seek a more scalable and productive approach.

The first version of their <a href="https://insights.lfx.linuxfoundation.org/" target="_blank" rel="noopener">Linux Foundation Insights</a> tool, released five to six years ago, "could connect data sources, aggregate the data, and visualize it, but it was extremely expensive," Grigar added. While V1 could talk to Kafka and GitHub, it was not always accurate. This led them to search for a more reliable solution.

Their second attempt involved creating a data lake with centralized data governance and optimizations, but this approach struggled to keep up with performance demands and proved to be both slow and costly. Additionally, insights V2 relied heavily on computing data on the fly, which resulted in delayed performance despite accurate results.

Furthermore, the Linux Foundation's initial data infrastructure was not able to provide real-time insights due to the lack of advanced caching mechanisms and swift data aggregation processes. This led to scattered data depiction and inconsistent performance, making it challenging to deliver reliable insights to their diverse user base. “The performance aspect was difficult, and the question of ‘Is the data accurate?’ has always been a tough one,” Grigar noted.

Therefore, the Linux Foundation found themselves seeking a robust solution to streamline data management, embedded analytics, and visualization across multiple projects using a [semantic layer](https://cube.dev/use-cases/semantic-layer); hence, they turned to Cube

##### Caption: Linux Foundation embedded analytics data stack
![Linux Foundation Embedded Analytics data stack](https://ucarecdn.com/5d838a33-349f-4f17-a428-256b03ee8ff6/-/quality/smart/-/format/auto/)

## Making the Leap: Choosing Cube Cloud

The Linux Foundation had heard about Cube prior to their collaboration with Crowd.dev, but it was Crowd.dev's successful use of Cube Core that served as the tipping point for deeper evaluation. Grigar explained, “We had heard of Cube prior to Crowd.dev using it, and it just happened that Crowd was using it. We were discussing the architecture for Insights V3 and Cube was a key component of that,” particularly for its semantic layer capabilities. The big question was whether to run Cube in-house or use Cube Cloud.

The decision to choose Cube Cloud over [Cube Core](https://cube.dev/product/cube-core) was influenced by several factors. First and foremost, the Linux Foundation wanted to avoid the operational overhead associated with hosting and maintaining Cube themselves. Grigar noted, “The big factor for me was whether we wanted to take on the responsibility and accountability of hosting the Cube stack, having to learn the ins and outs of scaling it, improving performance, and handling updates.” He further elaborated, 

> “I thought, do we want our team to be experts in hosting and running Cube, or do we want to focus on things more pertinent to the business foundation? That was the big driver for me.”

Additionally, Cube Cloud provided significant advantages in terms of integration and support. Grigar added, “Using Cube Cloud greatly benefits us. It requires minimal optimization time, ensures reliable deployments, and allows financial predictability. Moreover, it integrates with our GitHub workflow, providing significant advantages both financially and engineering-wise.”

The support from the Cube team also played a crucial role in their decision. Grigar highlighted, “We had hands-on support through the process, with group training sessions and continuous guidance on how to best use the tool. This support was invaluable in getting things off the ground and ensuring we were using Cube effectively.”

Ultimately, the combination of reduced operational overhead, seamless integration, financial predictability, and support led the Linux Foundation to choose Cube Cloud over Cube Core.

## Effortless Onboarding: Implementing Cube Cloud

The implementation of [Cube Cloud](https://cube.dev/product/why-cube-cloud) at the Linux Foundation was efficient and straightforward. Grigar shared, “It was quick to get started, and our development team was excited to use Cube.” As their data requirements grew more complicated, the Cube team provided vital support. “When our data started getting complex, the Cube team helped us better instrument our cubes and structure our aggregations.”

Cube's user-friendly design made it accessible for developers. Grigar noted, “Building a cube is pretty straightforward if you are familiar with any SQL language skills. It gets harder with more complex cubes, but it's much easier compared to the tools we were using previously.”

The swift implementation and support ensured that the Linux Foundation could quickly and easily employ Cube Cloud's capabilities to enhance their data-handling and information modeling processes through its semantic layer.

## Revolutionizing Embedded Analytics and Data Management for Open-Source Projects

Implementing Cube Cloud significantly optimized the Linux Foundation's data processes by leveraging its advanced semantic layer. Grigar highlighted the role of [pre-aggregations](https://cube.dev/product/caching-and-data-performance), stating, “Our applications would not be able to function without the pre-aggregation capabilities that Cube provides.” By harnessing embedded analytics, this automation allowed the Linux Foundation to maintain real-time data access and eliminate reliance on outdated data. “Pre-aggregations from Cube helped make our application real-time, so we don't have to rely on slow or stale data,” Grigar added.

Cube Cloud’s advanced data management features provided substantial benefits for the Linux Foundation's Open-Source Community Insights tool. “The caching layer and Cube Store have been instrumental in speeding up our data access and improving the user experience,” Grigar emphasized.

Additionally, the Linux Foundation heavily relied on the Cube REST API, which facilitated smooth integration with their access control solutions. Grigar explained, “We are able to plug in through our access control solution and integrate it with the Cube REST API.” The organization explored other API options, such as SQL and GraphQL, to further enrich their data-handling capabilities. “GraphQL has been on the table as an API, and there may be some places where GraphQL makes more sense for us. It’s nice to have the options for that,” Grigar noted.

The flexibility and range of [API options available with Cube Cloud](https://cube.dev/product/data-apis) enabled the Linux Foundation to adapt their data operations strategies to meet diverse project requirements, ensuring efficient and streamlined operations across their extensive portfolio of open-source projects using embedded analytics.

## Enhancing Developer Productivity with Real-Time Insights Across Multiple Dashboards
Furthermore, Cube Cloud offered developers at the Linux Foundation a more versatile approach to data governance using its semantic layer. Grigar explained, “Using Cube lets us pull from multiple data sources, standardize the visualization process, and cache through Cube Store, allowing for custom time ranges.” This enabled developers to quickly identify active development periods and drill down into specific date ranges.

The Linux Foundation's various dashboards, including Insights, Individual Dashboard, Control Center, and Organizational Dashboards, leverage Cube to render real-time data from diverse sources such as Google Sheets, HubSpot, and Crowd.dev. This integration ensures accurate, timely, and accessible data, facilitating better decision-making and insights for their projects.
By unifying data management and visualization, Cube Cloud has empowered the Linux Foundation's developers to optimize their workflows and drive more impactful outcomes.

## Comprehensive Benefits: DevOps and FinOps
Grigar also emphasized Cube’s profound impact on their DevOps, cloud operations, and engineering teams. "It's really helpful for us. My team doesn't have to sink a ton of time into optimizing; we can trust the deployments and rely on the service. Having the creators of the software manage the infrastructure is huge," Grigar explained.

Financial predictability has also been a significant advantage. Grigar noted, "Financially, we know what it's going to cost, which is super helpful. On the FinOps side, and on the engineering side." This predictability and integration have been powerful assets for the Linux Foundation.

## Expanding Horizons: Future Innovations and AI Integration
Looking ahead, the Linux Foundation plans to expand its use of the Cube platform across more of its core products to ensure consistent data standards and streamline analytics across different applications. This expansion will include developing additional private or restricted access to data for internal teams, using Cube's [access control capabilities](https://cube.dev/product/data-access-control).

Moreover, the Linux Foundation intends to further enhance its data cloud infrastructure by refining their dbt models and ensuring seamless integration with their expanding data sources. With Cube at the center of their data strategy, the Linux Foundation is poised to continue its leadership in the open-source community, driving innovation and productivity through advanced data analytics and [AI integration](https://cube.dev/use-cases/llm-and-ai-semantic-layer).

Additionally, the Linux Foundation is committed to integrating AI capabilities into its platform. Grigar shared that there is an interest from their executive director to utilize AI further. "Cube would be a great place to leverage AI, so I'm interested to see if that would line up in the future," he said. They hope to explore the potential of using Cube's AI API to create more intuitive and engaging user experiences. For instance, implementing chatbots for board meetings to provide real-time insights on project contributions could be a significant Improvement.

By harnessing AI and Cube's robust data handling capabilities, the Linux Foundation aims to transform how users interact with and interpret data, paving the way for more informed decision-making and proactive project management. In doing so, the Linux Foundation continues to utilize Cube Cloud to drive open-source community insights, ensuring their projects remain at the forefront of technological innovation.

##### Caption: Linux Foundation Insights Embedded Dashboard 
![Open Source Embedded Dashboard](https://ucarecdn.com/cc4614fb-4639-49c8-8c9d-deb747bd9ad3/-/quality/smart/-/format/auto/)


Before partnering with Cube, the Linux Foundation faced challenges with their data stack's complexity and performance

Implementing Cube Cloud semantic layer significantly optimized the performance of the embedded analytics project, the Linux Foundation Insights. Harnessing embedded analytics, the automation eliminate reliance on outdated data.

Faster queries and a simpler stack on Snowflake, dbt, Crowd.dev, and Angular

The Linux Foundation boosts embedded analytics performance with Cube's semantic layer

SamCart


SamCart is an eCommerce platform powering over 75,000 creators worldwide, supporting digital sellers, creators, and entrepreneurs with a seamless, conversion-focused checkout solution. SamCart’s platform is designed to help its users increase conversion rates with minimal friction, delivering an eCommerce experience that aligns with the fast-paced needs of modern digital businesses. 

SamCart provides customers with an in-app dashboard displaying the key metrics and reports these sellers and entrepreneurs need to be successful in running their business. This becomes the source-of-truth and most relied upon aspect of SamCart’s dashboard for understanding the health of their business. It is critical that this dashboard updates regularly and maintains accurate information.

SamCart’s Mason Tiffin, a data engineer specialized in modernizing data platforms, shares their story.

## Supporting the Growing Demand for Data
As SamCart’s customer base expanded, so did the demand for accurate and quick access to data on the client-facing reporting platform. One of the most pressing challenges was centralizing and standardizing core data models to ensure consistency across reports, a critical need for SamCart’s worldwide user community. 

Additionally, performance issues began to surface as dashboards often took too long to load, and customers increasingly reported data discrepancies, leading to confusion and frequent support requests. These challenges hindered SamCart’s ability to deliver an optimal customer experience, impacting the overall perception of the brand and adding strain on customer support teams, who had to handle numerous data export requests to meet customer needs.

## Evolving SamCart’s Data Stack with Cube Cloud
Fortunately, SamCart’s Chief Architect had prior experience with Cube in other projects. Determined to improve the user experience and streamline data access, SamCart turned to Cube’s universal semantic layer, seeking a solution that could centralize and govern their data processes while also accelerating query execution times. 

The primary goals were to ensure scalability, flexibility, and high performance to accommodate SamCart’s growing customer base and evolving data needs. Their requirements focused on answering three key questions:

- Can the system properly scale to handle all requests efficiently?
- Can the system evolve as data needs and data stack evolve?
- Can the system provide sub second query performance for large data sets?

Implementing Cube’s solution was a multi-stage process. In the first phase, SamCart connected Cube to their MySQL database and centralized data models. With the data models defined in Cube Cloud, they could begin defining pre-aggreations, which provided an immediate boost in query performance and significantly improved load times. However, as their data volumes and customer expectations grew, they recognized the need for a more robust solution because MySQL’s throughput became limiting. 

The second phase involved transitioning to Snowflake as the data source and using dbt Labs for data transformations, allowing SamCart to simplify their data architecture. With MySQL data models defined in Cube Cloud, the migration was as easy as pointing to the new Snowflake instance, making the work they had already done for MySQL available to the new cloud data platform. 

In addition to performance, the team had to address the complexity in having customers in almost every timezone globally for serving pre-aggregations. Initially, they considered consolidating time zones into regions, but they ultimately decided to offload timezone conversions to Snowflake and dbt Labs, which enabled Cube to deliver consistent data while optimizing resources.

![](https://ucarecdn.com/a2d4ecb6-742e-4572-bae4-c2ffa6f087f0/-/quality/smart/-/format/auto/)

This move enabled them to shift heavy workloads to Snowflake, allowing Cube to focus on building pre-aggregations, which drastically reduced pre-aggregation build times from eight minutes to mere seconds by leveraging Cube Cloud’s export buckets. This enhancement not only accelerated the testing and development cycles. In addition, SamCart realized cost savings from reducing the number of direct Snowflake queries and provided their customers with faster access to data at the same time.

Mason shared, “The main integration Cube has is to Snowflake. Snowflake is at the heart of our data platform so all sources and data builds occur in Snowflake. Cube Cloud has been nice because it allows us to extend the features and functionality we love about Snowflake.”

## Achieving New Levels of Consistency, Efficiency, and Performance
With Cube’s universal semantic layer now seamlessly integrated into their Snowflake infrastructure, SamCart gained powerful new capabilities that transformed their data operations. [Pre-aggregations](https://cube.dev/product/caching-and-data-performance), a standout feature of Cube, allowed SamCart to reduce query execution times significantly, with some queries dropping from 20 seconds to as little as 1.1 seconds, achieving an average of 600 milliseconds. 

This impressive performance gain translated into an enhanced user experience, with customers enjoying dashboards that now load in sub-second times. The reduction in load times also cut down on support requests related to performance, allowing the team to focus on more complex inquiries. 

Cube’s integration brought new levels of consistency to SamCart’s data operations. By centralizing their data model and streamlining complex data logic, Cube improved data accuracy across reports and simplified the data development process. The enhanced oversight and logging features in Cube Cloud enabled the SamCart team to quickly identify optimization opportunities and address any data issues, fostering a more efficient and reliable data environment.

## Looking Ahead
Cube’s universal semantic layer has enabled SamCart to deliver a faster, more consistent, and reliable data experience for their customers. The improvements in performance and data governance not only reduced customer complaints but also allowed SamCart to shift its focus toward delivering advanced analytics solutions. As SamCart continues to grow, Cube will remain a key partner in their data journey, helping them drive greater insights and create a seamless experience for the digital sellers, creators, and entrepreneurs they support.

With a solid foundation in place, SamCart plans to expand its use of Cube, incorporating additional dashboards and reports to further enhance the insights available to its customers. As they evolve from primarily descriptive analytics toward diagnostic and predictive analytics, SamCart envisions Cube Cloud playing an instrumental role in managing and delivering high-quality, real-time data to their customers.


Faster, more accurate in-app dashboards for 75,000+ creators

SamCart reaches new levels of consistency, efficiency, and performance with Cube

Fortune 500 Manufacturing Company


This Fortune 500 Manufacturing Company is a leader in high-quality affordable bottled beverages with production facilities throughout the United States. The dedication to operational improvements, a consistent recipe of hard work, integrity, attention to detail, and the relentless quest for perfection has driven the company to become one of the largest bottled beverage companies in the United States.

This dedication to operational improvements led the team, including their  Application Manager, to dream of building the most advanced “internet of things” sensor-based warehouse in the US and maybe in the world. Three years ago, they began implementing sensors or “tags” in all the shop floor equipment. With 1000 or so tags, they started collecting data and moving it to the cloud to visualize it. However once the team realized the value of this data, they wanted to expand it to more and more devices in the plant - and expand to all their plants across the network. 

> “That's when we realized that the amount of data which was streaming to the cloud is way, way, way more than what we expected.” 

## Traditional BI tools can’t handle the large data load

Originally, they had used Power BI on top of their Databricks lakehouse to visualize this data, but at some point it was not able to handle the volume and visualizations would not even render, not to mention the speed and latency of the analytics produced. 

The second challenge was that the cost of storing and processing all that data was much higher than what they were willing to spend. “We had to change technologies not only on the compute front, but also on the storage front.” 

### Embedded Analytics for an internal use case
The team started by doing a proof of concept (POC) with both GoodData and Cube Cloud looking at how the semantic layer can deliver data to a custom front end they would build in HighCharts.

Cube was able to connect to Highcharts and significantly improve the speed of queries with pre-aggregations. But the company had 40+ plants that wanted to use these analytics tools and each plant has a significant amount of data. Running that amount of data through one production cluster will eventually fail and creating a separate production cluster for each individual plant essentially creates as many data models, environments, endpoints and REST API URLs as there are plants - an inefficient and error prone approach. 

But Cube has the ability to help the company scale horizontally with Cube’s multi-cluster deployment capability that allows them to spin-up separate Cube API instances and separate Cube Store infrastructure within just one deployment. Many production clusters within one deployment sharing one REST API URL, one data model, and one environment. The company even has control over how they bucket the data, choosing which plants will be in which bucket.

## Cube Cloud delivers game-changing support 

GoodData’s technology was not able to match Cube’s pre-aggregation or multi-cluster functionality. But the Application Manager adds, “The real game changer was the support provided by the Cube team in this evaluation period. That kind of support we never got from GoodData. The support from Cube Cloud was tremendous.” 

The company noted that the support team also proactively reaches out to help optimize queries that seem to be taking longer than expected. “This kind of engagement we typically don't get from other vendors.”  

## Innovation needed to scale to 50 plants and half-a-million sensors 

Today, the company has half a million tags across its 50 plants. This includes all the motors, pumps, chillers, palletizers, packers, and every single piece of equipment in the plant. 

“The plant teams love the data and we’ve seen that they don't even want to wait until a new plant is settled before starting to get it. They want to go live as soon as possible and start collecting and visualizing the data from day one.” - Application Manager 

The path to rolling out their data stack to all of their plants was not always straightforward because of the massive volume of data that they were collecting and analyzing. 

![Databricks and Cube managing massive amounts of data](https://ucarecdn.com/88f11b9b-e2ee-46b6-9c22-4a6519a952f7/-/preview/1000x328/)

With the help of the Cube team, the company settled on an architecture consisting of Databricks for their core lakehouse storage and data processing, Cube Cloud for their semantic layer, security, pre-aggregations and APIs and Highcharts for visualizations.

This pattern allows them to handle the immense amount of data generated by their plant monitoring, retain historical data as efficiently as possible, but also feed their reports and alerts the real-time data critical to detecting potential device failures and production interruptions.

## Big wins for the data team

As the company has rolled out Cube Cloud and their data platform to more and more plants, they have started to see tangible results.

### Getting ahead of catastrophe
Recently, there have been several cases where the analytics system alerted the team that a specific motor would likely break down in the next 48 hours. Since the plant managers could see this data, they were able to successfully alert the maintenance team and avoided the downtime that a failing motor would have caused. 

### Cost savings with conditional-based maintenance
Prior to Cube Cloud and their data solution, maintenance was calendar-based. A motor would be inserted every 30 days irrespective of whether it is needed or not. But now they have enough data to identify that a motor was still at 50% efficiency and replacing it can be delayed - offering huge cost savings across 50 plants and thousands of motors. 

### Granular data delivers big results
With one expensive motor, the data analysis recognized a vibration and knew exactly what the cause was. It was a small issue to fix, only a couple of $100s for some parts. But if they hadn’t had the data to analyze the issue and if these small parts had failed, they would have had to replace the enter motor which is at least $100k. Being able to recognize the issue and address it quickly - before the entire motor was affected - meant the company saved a potential loss of $100k+ as well as the lost productivity in the plant. 

### Right place, right technology, right partner
> “This was an exciting journey with a great deal of changes in the technologies. What we started with, we no longer use. The landscape has changed but right now I feel we are in the right place with the right technologies and right partner in Cube”

The company plans to expand their plants by at least three to five plants a year. And apart from growing the number of plants, they also add lines to the existing plants. “The data which we are collecting right now will exponentially increase - there is no way we are going to stagnate,” The Application Manager said, “I have high confidence that the Cube team will be able to fully support our growth.”


Cube has helped the company speed up query performance and manage massive amounts of data. Cube’s multi-cluster deployment capability, allows them to spin-up separate Cube API instances and separate Cube Store infrastructure within just one deployment.

Plant-floor analytics Power BI couldn't render, now sub-second on Cube Cloud

With Cube, we’ve reduced the time required to generate real-time and historical reports from 10’s of seconds to less than 2, while reducing our spending on hosting by almost 80%.

Cuboh

A Fortune 500 manufacturer manages massive IoT data with Cube

spyne 


## AI-enabled embedded analytics on one semantic layer

Marketing channels have exploded. At first it was Google and Facebook, but today it’s LinkedIn, Snapchat, TikTok, and dozens more. Managing all of this complexity has become a challenge for marketers and growth teams. [spyne](https://www.spyne.app/) is a business operations platform focused on making it easier for publishers, agencies, and marketers to monitor, manage, and understand campaign performance in a single interface. They take the data complexity out of the modern marketing landscape.

As a core part of their offering, spyne wanted to share insights with customers through detailed dashboards.. They quickly realized that they needed to have full control of the visualizations to deliver the experience they were looking for. 

> “We didn’t want to use Tableau, Power BI or Looker Studio. We needed our own tool integrated completely within our platform.”  -  Patrice Navarre, CTO and co-founder of spyne

When rendering dashboards for an embedded application, every millisecond adds up and impacts the customer experience. 

Marketing Operations teams have long struggled with collecting and bringing together data from a growing digital landscape and integrating it into a consistent data model. Customers come to spyne having already tried to build dashboards using their own mix of analytics tools, including common BI tools.

> “Our purpose is to make that simpler - you just open your account, plug your sources and you get your dashboards. You don't have to worry about anything else.”

In addition to simplifying the data model, spyne knew that application performance would be critical in keeping customers happy. With Google BigQuery as their warehouse, and a custom front-end integrated into their product, they began looking for ways to accelerate queries with pre-aggregations and caching. 

> “BigQuery is extremely scalable, but sometimes it takes half a second and up to one second to perform a query. We have up to a few hundreds queries on some of the more complicated client dashboards. That is where query caching can make a huge difference.” 

They discovered [Cube Cloud](https://cube.dev/product/why-cube-cloud) in their search for [query acceleration](https://cube.dev/product/caching-and-data-performance). 

The team at spyne got Cube Cloud working quickly and proved that it would be a valuable addition to their [embedded analytics stack](https://cube.dev/blog/modern-embedded-analytics). In less than an hour, the front-end team was able to create a data model, retrieve a token, and build a test. In one day spyne started building on Cube Cloud.

Today, Cube Cloud accelerates all of the campaign data held in Google BigQuery and then customers interact with that data through spyne’s custom front end interface. spyne offers many pre-built dashboards, and customers can build their own dashboards using a custom dashboard designer spyne provides.

> “While we offer the ability for customers to create their own dashboards, we don’t want customers - or even our front-end developers - to have to create complex SQL queries themselves. They just graphically configure their charts and reports, and Cube does the job of turning these into complex SQL queries on our warehouse.”

The spyne team also acknowledges Cube is a great tool to optimize query cost in Google BigQuery.

### Developing new functionality with Open AI

In addition to their core dashboarding capabilities, spyne has expanded into an AI offering where customers can interact with their data through natural language questions and get intelligent commentary on how marketing campaigns are going.  This solution relies upon the reasoning powers provided by OpenAI. 

While the spyne team was concerned that it might be [difficult to teach an LLM how to understand the data](https://cube.dev/blog/semantic-layers-the-missing-piece-for-ai-enabled-analytics) that was available within Cube, and to form valid queries to answer users questions, it ended up being rather straightforward to solve these problems. First, to handle discovery of what data is available, Cube provides a meta API endpoint to inspect the contents of a data model in a structured way. As for removing the need to have the LLM write complex SQL, the team elected to build requests using the REST API endpoint and the model was able to generate perfectly tailored queries to answer any question.

### How does it work for customers?

Customers now can ask a question in natural language from a simple search bar, and spyne delivers two answers. The first one are charts - different types of charts depending on the question. 

> “If you ask what the performance was day by day last month, then you get a line chart. You say, please compare the performance across my strategies. Then you get a bar chart. If you say, what's the breakdown of a specific dimension then you get a donut or a pie chart and so on.”

The second answer provides commentary on those charts by interacting with OpenAI.

_Screenshot from spyneAI, where they leverage OpenAI and teach the Cube data model._

![spyneAI chatbot](https://ucarecdn.com/c4d6c867-18c8-4376-94d4-97b92e7664ba/-/quality/smart/-/format/auto/)

### Results

spyne discovered Cube Cloud in their search for performance gains on top of BigQuery, but over time came to appreciate the dynamic query generation, pre-aggregation, multi-tenant security contexts and robust API-endpoints that Cube Cloud provides. By investing in a strategy that centered the [semantic layer](https://cube.dev/use-cases/semantic-layer) in their application design, they were able to go all in on building their own custom dashboard package which includes static dashboards as well as an advanced custom dashboard builder their customers love. 

When AI showed up on the scene, the team at spyne was well positioned to get an [AI-enabled analytics](https://cube.dev/blog/semantic-layer-the-backbone-of-ai-powered-data-experiences) feature to market in their app faster than their competitors, delighting their customers and demonstrating their value as a partner to marketers everywhere.

> “Cube has been great. Not only has Cube improved query performance on BigQuery from a few seconds to milliseconds, but it made it possible for us to quickly roll out our spyneAI assistant”


Using the Cube Cloud semantic layer spyneAI accelerated query performance of embedded analytics for their customers. And, they have built their AI ChatBot on top of the same semantic layer, giving multiple data apps the same metrics.

Cube Cloud powers both spyneAI's chatbot and customer-facing dashboards

spyne ships embedded analytics and an AI chatbot on one semantic layer

Simon


Core to our business at [Simon Data](https://www.simondata.com/) is a data platform that enables our clients to access, operationalize, and centralize their marketing data.  The ultimate goal of Simon Data is to give marketers an intuitive, non-technical platform in which to manage sophisticated data operations required to drive great customer marketing outcomes.

![Simon Data Screenshot](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/a4a475ea-dcc6-4fea-8386-6ae3843c8ed8.png)

The warehouse is powered by a complex, multi-tenant environment comprising datasets of varying lineages, schemas, and business purposes. Some datasets are common across client accounts — such as data we produce or import through marketing channel integrations — while other datasets are client-specific. While this delivers significant leverage for our customers to orchestrate bespoke end-user impressions, it also introduces a brain-bending taxonomical challenge to the engineers looking to drive analytical insights across the entire system.

Since the product’s creation, the platform has seen several analytics products built into it. Early last year, we organized a focused team to consolidate them on a standard foundation. At that same time, we also wanted to rethink how we integrated analytics in our application to streamline the development and deployment processes.

We knew the best path forward was to build a framework that could be used both now and in the future for analytics product development on any part of our core platform. To pull this off, we had some goals for the system.

We wanted a seamless development experience, support for querying arbitrary data, fluency in managing various schemas, and an ability to rapidly prototype and develop the user experience. Equally important was the ability to transparently present the queries and transformations used to produce results to facilitate QA by multiple stakeholders.

## What our users wanted

When we talked with users and business stakeholders, we discovered several pain points:

- Users complained about difficulty configuring custom reports and limited dashboarding capabilities.
- Developers spent too much time maintaining multiple different and complex implementations of analytics products.
- Salespeople wanted an easy-to-use and effective out-of-the-box reporting dashboard to present to prospective clients.
- Client Solutions Managers wanted more transparency in how the system calculated results.
- Product managers and engineers were concerned about the level of effort required to build new analytics products.

## Enter Cube

We started with a holistic review of the analytics products we already had to gather requirements for the new reporting suite and took a close look at how clients were (or were not) using them. Alongside that, we also did a systematic review of technologies we could use to build a new reporting platform.

We looked at many commercial products and open-source projects and narrowed the list down to a handful of contenders, including [Apache Kylin](http://kylin.apache.org/) and Druid from the open-source space and Looker from the enterprise. Cube quickly rose to the top of that list.

What we liked most about Cube (no other offering provided all of these):

- It was designed for precisely the problem we were trying to solve, which was embedding analytics into an existing application, and it fits nicely into our existing technology stack.
- First-class support for the tools we use: Snowflake on the backend and React/Recharts on the frontend.
- Pluggable authentication and schema configuration hooks we could use to integrate with the rest of our platform. Specifically, we use [driverFactory](https://cube.dev/docs/config#options-reference-driver-factory) to provide credentials for Snowflake and MySQL (for external pre-aggregations).
- Out-of-the-box support for deploying as a serverless application on AWS Lambda with API Gateway, ElastiCache, and Aurora/MySQL.
- A fantastic developer sandbox app, [Developer Playground](https://cube.dev/docs/dev-tools/dev-playground), which provides interactive query development, troubleshooting/debugging, the export of queries, and even ready-made Recharts components.
- [Multiple layers of caching](https://cube.dev/docs/caching) to provide the performance necessary for interactive data visualization in our application.
- An integrated framework for building frontend data components leveraging our massive data warehouse, one that was lightweight and enabled rapid iteration without a lot of boilerplate, nor the need to wire together lots of different libraries.

## Where we had to invest in Cube

Marketers interact with Simon Data through our easy-to-use web application. We needed a way to query data from multiple independent data warehouses, each with its different schema, and present the results in a common interface. This was a challenge on two fronts: development and deployment.

First, we had to invest in integrating Cube with our infrastructure to provide credentials and schema configuration for each individual client's data warehouse. Cube provided hooks we could use, so this was reasonably straightforward.

However, we needed to give developers a way to run Cube to mirror the production environment while being able to rapidly iterate on schema, query, and frontend component development. This meant building a common application bootstrap and configuration for Cube that we could use to launch it in dev, staging, and production environments.

One neat trick we pulled off here was getting Cube to seamlessly serve both its playground application and API queries from our web app when running in development mode. This is important for us to be able to run everything (i.e. both Cube and Simon Data web app) on our laptops and have the web app be able to send queries to the Cube Playground running locally.

Another challenge we faced was safely and securely deploying configurations to production without impacting what was already running. We achieved this by making schemas immutable.

When we want to deploy a new schema or patch an existing one, we create a whole new schema or increment the current schema with the changes. Once we have the latest schema working in our development environment, we can test it out in the staging environment and deploy it to production. We can do all of this in the background, so we only switch the production web application over to the new schema once we have complete confidence in it (see Figures 2 & 3 below).

Our repeatable deploy process sets up the new schema in Snowflake and Cube simultaneously, which gives strong consistency between the Snowflake and Cube configurations.

We have defined schemas as a set of Snowflake views and Cube cubes that are developed and deployed together. We create a schema by writing view templates that map onto the data in Simon’s warehouse designed for the given customer to provide a standard interface to create the cubes on top of (see Figure 1 below). Our developers write these view and cube templates using [Jinja](https://palletsprojects.com/p/jinja/) from their IDEs and can rapidly iterate on them locally using our end-to-end development environment integration. Once the schema is complete and committed, our deployer tool dynamically renders the templates by filling in variables specific to each customer’s datasets. This pattern was the key to building repeatable schemas and deploying them consistently in our complex multi-tenant environment.

Finally, we created a comprehensive, automated end-to-end integration test suite (written in Python) that exercises each cube across all schemas that are live in Cube.js. This serves two important purposes:

1. It validates our production environment.
2. It keeps the Cube pre-aggregations database up to date ahead of user interaction.

The integration test runs periodically and also after the deployment of any new schemas. Once the test passes, we can safely switch the web application to the new schema with confidence.

### How Cube is deployed at Simon Data

![Figire 1](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/329b1deb-0db8-4c31-a91a-8aa93d4c817c.png)
**Figure 1: Schema is the unit of deployment**

- Each schema gets deployed into both Cube and Snowflake at the same time.
- A schema is composed of one or more sources. Each source defines a particular data source.
- Sources are where developers work. During development, the Cube, View, and Table definitions are created as a single unit (a source) that powers one or more in-app features.
- In a source, each Cube (Cube config files) has a dependent View (with a SQL query, which the Cube is defined on top of), and each View has one or more dependent Tables (with a name and list of columns that are verified in validation).
- Tables represent the upstream data in the data warehouse that we want to bring into the web application with an in-app reporting feature.

![Figure 2](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/fc652e61-0640-463f-b8ed-0b7d0375b12d.png)
**Figure 2: Deployment process**

- Create a new schema in the Cube Playground.
- Deploy the schema into Snowflake & Cube.
- Switch the Simon Web App to use the new schema.

![Figure 3](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/3d5dc184-927a-4216-9bef-345227ed7b99.png)
**Figure 3: Schema migration**

We can develop a new schema and deploy it in the background, then switch the Simon web app over when ready.

## How are we better of now?

We delivered three major wins to our clients and business stakeholders with this platform:

**Speed.** We can develop and ship analytics products without dealing with any net new infrastructure development going forward. Our efforts are focused on what matters: the data and the UI. Integrating the Cube Playground into our development stack enables us to rapidly build a schema and query in Cube and then export that for implementation in the front end, all of which a developer can quickly do on a laptop.

**Flexibility.** We have a framework that enables us to seamlessly query any data in Snowflake and present it in the web application. The real win here is that we won't have to choose between maintainability and time to market to get this flexibility -- we can have both.

**Stability (Antifragility).** When we're ready to ship a new product feature, we can deploy it with the confidence that we will not introduce regression on existing functionality because our schemas are immutable. We can also roll out new features to client accounts in a controlled manner, one by one or in batches, and even keep the changes hidden to perform production validation before they are released to end users.

## Results and future plans

We’ve already built net-new analytics products on this platform that solve fundamental client pain points, proving that the platform works. We’re also starting to realize the velocity gains when iterating on these products to add functionality and refine the user experience.

Now we’re starting to look at consolidating some of the earlier analytics products onto the new framework. Finally, our business stakeholders now have transparency into the calculations that power analytics products in the application, giving them confidence in the data and helping them more easily answer client questions.

## Interested in joining Simon Data's success with Cube?

Explore Cube [examples & tutorials](https://cube.dev/docs/examples) and [get started](https://cube.dev/docs/getting-started) today. To jumpstart your efforts, please join us on [Discourse](https://forum.cube.dev/) & [Slack](https://slack.cube.dev/), follow us on [Twitter](https://twitter.com/thecubejs), and get engaged with the growing Cube community.


Simaon uses Cube for embedding data for internal and external users. These dashboards are now more reliable, fast and flexible.

Standard analytics framework consolidates multiple in-app products on Cube

We can develop and ship analytics products without dealing with any net new infrastructure development going forward. Our efforts are focused on what matters: the data and the UI.

Simon Data ships fast, flexible embedded dashboards for internal and external users

ShopBack


[ShopBack](https://corporate.shopback.com/) is the largest shopping rewards and discovery platform in Asia-Pacific, with a presence in Australia, Indonesia, South Korea, the Philippines, Singapore, Malaysia, Taiwan, Thailand, and Vietnam.

From a small team of six in 2014, we now house over six hundred employees across the region, having scaled to nine countries to provide a more rewarding shopping experience for over 28 million users. Our platform enables users to make better purchase decisions while delivering performance-based marketing with high and measurable return on investment to merchants.

ShopBack continues to innovate, evolve, and create value for our users and merchant partners. In 2020 alone, we powered close to US$3 billion in sales for over 5,000 merchant partners across the Asia-Pacific. To date, we have also awarded over US$200 million of cashback to our users.

![ShopBack info graphics](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/b8895d67-8413-4ee1-89c9-765f76e81279.png)

## Why ShopBack started using Cube

For all transactions on our ShopBack sites, we need to analyze all transactions, including purchase value, sales volume, etc. In January 2020, we started working on a new project that required a lot of dashboard reporting of aggregated data for both internal and external (e.g. merchant partners) application users. One of the options considered was building an in-house application and storing the data in a graph database. However, in consultation with [Yann AïtBachir](https://www.linkedin.com/in/yaitbachir/) (Head of Data at ShopBack), our engineers decided to go with Cube as it was a better fit for our use case as our data was very much relational and will be pre-aggregated into OLAP cubes for analytics.

![Shopback quote](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/46935f81-2009-43d4-aede-fe8fca409a75.png)

Since we first started using Cube, there has been an ongoing effort to add new Cube schemas, measures, etc., as our data continued to grow while improving the performance of our queries at the same time. To address performance concerns, we implemented [pre-aggregations](https://cube.dev/docs/caching/pre-aggregations/getting-started) in early 2021. Before implementing pre-aggregations, our [p95](https://findanyanswer.com/what-does-p95-mean-in-statistics) query loading time could take as long as ~50 seconds, which is an insanely bad user experience. Once we started implementing pre-aggregations, we were able to go as low as ~20 seconds p95. After we started further optimizing our pre-aggregations with indexes, modifying our approach to pre-aggregations for unique queries, and a couple of optimizations outside of Cube, we were able to get to below 5 seconds p95.

We still have a few more optimizations planned to reach our target of &lt;1 second p95, but this goes to show that proper application of pre-aggregations can drastically improve the performance of your Cube queries. The performance improvement with pre-aggregations is further demonstrated in the two figures below:

![Figure 1: Chart loading improvements](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/92903a28-4597-46bf-a4f3-60100287519c.png)

![Figure 2: Queries loading time](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/2a63e83f-d2b4-4e3f-8b9e-4020c2863e59.png)

## Implementing Cube at ShopBack

Since we started working with Cube in 2020, we have had nine people working on this project full-time with six engineers, 2 product managers, and 1 QA engineer. In addition, we had several other engineers who helped over the past 1½ year as we implemented Cube at ShopBack.

![Figure 3: Architecture Diagram Screenshot](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/d27316b5-d9e5-4ab6-b796-2999d1b4ef20.png)

What you see on the figure above is an architectural diagram of our Cube implementation.

* **Main Application.** The Node.js application in AWS uses an integrated Cube API instance to serve requests to our React frontend application. It fetches 95% of our data from our pre-aggregations, and the remaining 5% have consistently small datasets, so we have not seen the need to pre-aggregate it. Cube responses are also cached within Redis whenever there’s a successful first fetch. Given that our application allows users to use multiple different filters, this significantly reduces the load times for filters that have already been used for the day.
* **Data Pipeline.** Our application acts as a downstream service that receives/pulls in data from our other services. All of this data goes through our ETL process (built in-house), which then stores the processed data into our Postgres database.
* **Caching.** Our architecture uses pre-aggregations that are being stored in the same Postgres database and a non-clustered instance of Redis for storing fetched data and tracking the latest refreshed pre-aggregations for a multi-tenant application setup. The refreshing of our pre-aggregations is done by a separate instance of our application that acts as the [refresh worker](https://cube.dev/docs/deployment/production-checklist#set-up-refresh-worker); this refresh-worker tracks the refresh keys stored in our database (as seen below) to keep track of which pre-aggregations need to be refreshed. Making the [refresh keys](https://cube.dev/docs/caching/using-pre-aggregations#refresh-strategy) manageable like this allows us to fully control whenever we want to trigger a refresh in the middle of the day should we want to.

While working with Cube, here are some of the challenges/learnings that we came across:

* **Making sure we are hitting pre-aggregations.** With the amount of data that we have, we had to make sure that we pre-aggregate our different use-cases correctly. For example, you cannot make a pre-aggregation with a granularity set as a month if there are queries with date ranges that can start/end in the middle of the month. We learned that if we didn’t pay attention to these details, we may be surprised by not “hitting” our pre-aggregations database.
* **Performance.** While it was important to make sure that pre-aggregations are being hit, it was also important to remember that these pre-aggregations are still database tables that are queried on (and in our case, they’re stored in the same source database). In other words, if you end up with a pre-aggregation with a lot of data and a lot of cardinalities, then we also need to index those pre-aggregations. We learned that [indexing](https://cube.dev/docs/schema/reference/pre-aggregations#indexes) our pre-aggregation tables has dramatically improved the performance of our queries. Below you can see a sample of our pre-aggregations that can easily have millions of rows in the pre-aggregation table. As mentioned above, adding indexes (in this case to columns `status` and `outletId`) helped contribute significantly to speeding up our queries.

```js
preAggregations: {
  overview: {
    type: 'rollup',
    measures: [ count, amount ],
    dimensions: [ status, outletId ],
    timeDimension: occuredAt,
    granularity: `day`,
    partitionGranularity: `month`, 
    segments: [ validRecords ],
    refreshKey: {
      sql: `SELECT refresh_key
            FROM preaggregation_meta
            WHERE preaggregation = 'Records'`,
    },
    indexes: {
      overviewIndex: {
        columns: [ status, outletId ],
      }, 
    }, 
  }, 
}, 
```

* **Going beyond raw SQL queries.** In general, it’s fairly easy to create raw SQL for your queries with their own joins/nested statements. However, when we started using pre-aggregations, we realized that the original SQL statements weren’t flexible enough, and you couldn’t simply “port SQL to Cube.” Now, rather than starting with SQL, we consider how we will implement Cube from the outset.
* **Extracting refresh-related information.** We are currently trying to get more logging data from refreshes for the ShopBack team and our clients (e.g., "chart data last refreshed at *hh:mm:ss*"). We extract refresh-related information by looking for select keywords in refresh logs, but if there are easier ways to do this, we’d love to learn more!

The next major Cube project for us is implementing [Cube Store](https://cube.dev/docs/caching/using-pre-aggregations#pre-aggregations-storage) to achieve lower latency and higher concurrency. We are looking forward to implementing Cube Store after our region’s shopping campaigns/festivals and once our team has enough bandwidth (you can check out what else our tech team is working on [here](https://medium.com/shopback-tech-blog)). From our investigation into Cube Store, we know that we will need to explore some workarounds:
  
* For security reasons, we do not set our AWS keys in our instance environment variables. As such, we do not store values in `CUBESTORE_AWS_ACCESS_KEY_ID` and `CUBESTORE_AWS_SECRET_ACCESS_KEY`, and these are causing unexpected behaviors with our network calls.
* With the Cube Dev team, we’re investigating a low-level error message regarding the Parquet library when we have a lot of data (e.g., 4M rows).

## Working with the Cube community

Another key benefit of working with Cube is the community, as we believe it is a great example of an active community. I worked with other open source communities before joining ShopBack, and I typically saw the number of questions/issues pile up to a pretty high number. On the other hand, with the Cube community, whenever we have questions, they typically get answered within 24 hours of posting them.
  
Also, the community members are quite collaborative in terms of helping each other out. I have had a number of direct messages on [Slack](https://slack.cube.dev) with other community members to discuss how they did their implementations/deployments. In return, I also try to reply to threads that I feel I can help with.

## Interested in joining ShopBack's success with Cube?

Explore Cube [examples & tutorials](https://cube.dev/docs/examples) and [get started](https://cube.dev/docs/getting-started) today. To jumpstart your efforts, please join us on [Discourse](https://forum.cube.dev/) & [Slack](https://slack.cube.dev/), follow us on [Twitter](https://twitter.com/thecubejs), and get engaged with the growing Cube community.


Cube provides ShopBack a framework and tools to build custom embedded data visualizations with minimal effort.

Flexible framework powers data visualizations across the cashback platform

Cube provides us with the framework and tools to build our custom data visualization platform with minimal effort. Our full-stack developers are able to get productive quickly, optimizing performance wherever possible.

ShopBack builds custom embedded analytics with minimal effort using Cube

FeedMe


Based in Malaysia, [FeedMe](https://feedmepos.com/) was founded in 2019 and provides a Point of Sale (POS) system for the food and beverage industry across South East Asia. In addition to POS equipment that you see in restaurants, FeedMe provides reporting to their customers. The reporting ranges from sales reports, marketing analytics, inventory management, and others.  

FeedMe wanted to provide a robust reporting system that allowed users to generate their own custom reports. However, their previous solution that was based on SQL queries and JavaScript to process data across MongoDB, CouchDB, and BigQuery was becoming increasingly difficult to maintain and scale. FeedMe uses CouchDB in their client POS systems that can work either online or offline. CouchDB data is then fed into the BigQuery data lake for reporting.  FeedMe’s backend systems are written in JavaScript, so they wanted to use JavaScript to process data from MongoDB and BigQuery.  

## Taking a phased approach to deploy Cube

The FeedMe team found Cube through Google searches as they were looking for a solution that can help them develop a data schema standard.  They soon learned that Cube could help simplify their data processing and decided to take a phased approach to deploy Cube. 

In the first phase, they only focused on migrating part of their data schema using Cube’s [Dynamic Schema Creation](https://cube.dev/docs/schema/dynamic-schema-creation#top). They found this process to be relatively straightforward and spent about two weeks to complete this first phase.

In the next phase, the team spent another three weeks migrating the rest of their data schema and then implementing more advanced features such as [pre-aggregations](https://cube.dev/docs/schema/reference/pre-aggregations) and [Cube Store](https://cube.dev/docs/deployment/overview#cube-store). The FeedMe team liked the more flexible caching mechanism in Cube since they can customize [refreshKey](https://cube.dev/docs/schema/reference/pre-aggregations#refresh-key) and [rollup](https://cube.dev/docs/schema/reference/pre-aggregations#parameters-type-rollup) definitions. With Cube pre-aggregations and Cube Store, FeedMe’s BigQuery cost is down by about ⅔. (Before Cube, they could only rely on BigQuery’s built-in cache.)

Also, without pre-aggregations, it could take several minutes for their customers to query several months of sales data which wasn’t ideal.  When the data is cached and pre-aggregated, a similar query would take less than 10 seconds. 

## How FeedMe is using Cube

At FeedMe, Cube is deployed via Docker along with Kubernetes, and they use [Chart.js](https://awesome.cube.dev/tools/chartjs) for visualizations. You will find more details in the architectural diagram below.

![Architecture Diagram Screenshot](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/cd35818c-31b5-4fcf-9e69-866de2f670b1.png)

Cube has been in production at FeedMe since May 2021, and below is a sample screenshot of a sales dashboard. 

![Sales Dashboard Screenshot](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/469f653f-9dcf-432c-b628-54adbf313764.png)

The following screenshot shows a dashboard called the daily Close Up summary.

![Close Up Summary Screenshot](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/cdfbbc45-fdaf-466d-aa39-e27314be13f1.png)

## Working with the Cube community

The FeedMe team used the [Cube documentation](https://cube.dev/docs/) as an onboarding tool to get familiar with Cube and its features in the early days. They also liked the collaborative nature of the Cube community, especially on [Slack](https://slack.cube.dev/), as they were navigating different features such as [rollupJoin](https://cube.dev/docs/schema/reference/pre-aggregations#rollup-join), pre-aggregations, and Cube Store. 

They also provided feedback to the Cube Dev team when they discovered an [issue](https://github.com/cube-js/cube.js/issues/3081) with pre-aggregations. Enhancements to the rollupJoin and pre-aggregations will further streamline how the FeedMe team provides custom reports for their users while maintaining their BigQuery costs. 

## Interested in joining FeedMe's success with Cube?

Explore Cube [examples & tutorials](https://cube.dev/docs/examples) and [get started](https://cube.dev/docs/getting-started) today. To jumpstart your efforts, please join us on [Discourse](https://forum.cube.dev/) & [Slack](https://slack.cube.dev/), follow us on [Twitter](https://twitter.com/thecubejs), and get engaged with the growing Cube community.


FeedMe uses Cube to simplify their data processing and speed up the queries on embedded dashboards. 

Simpler data processing and faster queries on embedded dashboards

FeedMe lets restaurant users generate custom reports with Cube

Cube

Cube Core

Product

Data Modeling

Data Access Controls

Caching and Query Performance

Data APIs

Capabilities

Why a Semantic Layer?

Use Cases

Financial Services

Technology

Healthcare

Media and Advertising

All Industries

Industries

Finance & Accounting

Human Resources

Marketing

All Departments

Departments

Solutions

Blog

Pricing

Join the Slack Community

Check the Code on GitHub

Events

Press

Community

Documentation

Demos

Changelog

Customer Stories

Integrations

Security

Legal & Trust

Learn

Snowflake

Databricks

Microsoft

BigQuery

Consulting Partners

Partnerships

Resources

Build production analytics on Cube.

How software companies and data teams use Cube — the agentic analytics platform built on a semantic layer — to ship production analytics, embedded inside their products and inside the org.

How teams ship production analytics on Cube.

The future of reporting isn’t a chart, it’s an insight. Large language models are becoming a commodity — the LLM is the engine, but the semantic layer is the map. Cube gives us the foundation to make that real for every customer.

With Cube, we reached faster performance for some queries. Even better, pre-aggregations reduced the number of requests to the Data Warehouse by 2x, which translated into big savings. 


We didn’t want to use Tableau, Power BI or Looker Studio. We needed our own tool integrated completely within our platform, Cube allowed us to do just that. 