Dynamic Cubes in OneStream: The Gamechanger Inside the Box

OneStream has introduced a feature that will change the way applications are built—streamlining design, improving performance, and reducing the need for physical data storage: Dynamic Cube Services, or DCS.
 
DCS was released in late 2024 with v8.4, and Ascend Partners was selected as an early adopter. DCS enhances areas of OneStream’s existing architecture and unlocks a world of endless design possibilities that were previously impractical or not possible.In simple terms, it allows data and metadata to be sourced and shared from a wide range of datasets beyond what would typically be available in a OneStream cube, enabling new approaches for cube data. To fully appreciate the potential of DCS, it’s worth spending time with OneStream’s documentation, which goes deeper into the concepts and mechanics behind it. For this post, we’ll focus solely on sharing data from a standard OneStream cube into a DCS cube.

What is Shared Data?

Shared data in a DCS cube can take some getting used to because it behaves very differently from data in a traditional OneStream cube. It isn’t physically stored in the DCS cube, you won’t find it in the application database, and it isn’t dynamic in the classic member‑formula sense. Instead, a shared data cell acts as a reference to a corresponding data cell in the original source cube. For those with an Essbase background, it may feel somewhat like a Transparent Partition, and for experienced OneStream users, it can resemble Hybrid Scenarios. Those comparisons provide context, but DCS ultimately delivers much more.

To illustrate how DCS works, it helps to look at how OneStream traditionally gets data for its Standard Cubes. Data records stored in the application database (the DataRecordYYYY tables) are combined with metadata tables—members and their relationships—and rendered back to the user as a multidimensional cube view.  

DCS follows a similar pattern, with one important distinction: it allows the query to the data record tables to be intercepted and replaced with an alternate data source. If the substituted data complies with the format expected from the data record table, it will return those records to the cube.

A basic use case for sharing data between cubes without manipulation is to create a leaner data unit from a subset of the original data to improve performance. However, the real power of DCS emerges when shared data is programmatically manipulated before it reaches the DCS cube.

Dynamic FX Translation

Multi‑currency translation is a requirement for many clients, particularly for constant‑currency analysis. Traditional approaches often require duplicating stored data into additional scenarios and applying alternate FX rates. This is inefficient, inflexible, requires a lot of physical data storage, and needs patience to wait for the preparation and processing of this data.

With DCS, local data can be multiplied by FX rates after query but before data unit creation. Since the process is fully dynamic, changes to FX rates are immediately reflected in reporting without having to re-translate. As a result, both base and parent entities can be displayed in any currency in nearly real-time. This is all done without the need for additional data storage, scenarios, or complex dynamic member formulas. Of course, translated data is most valuable when you can see the results aggregated or consolidated to the top of the entity hierarchy. DCS supports this as well.

Dynamic Aggregation

DCS should not be seen as a replacement for OneStream’s robust Consolidation engine, particularly in scenarios where formal consolidation behaviour is required. However, DCS can aggregate child entities taking into consideration ownership percentages, FX (including alternate currency input members in the Flow dimension) and Elimination data stored in parents very efficiently.

Depending on how you design your logic, historical data can be presented in a way that reflects updated structures or assumptions, as if they had always been in place. For organizations performing Same store, Comparable, or What-if analysis across long time horizons and evolving criteria, this is the capability they’ve been waiting for.

Implications for Future OneStream Designs

Translation and aggregation are just two examples of what DCS does exceptionally well by reducing the amount of stored data records in a OneStream application. Looking ahead, the continued expansion of DCS data sharing use cases will have a meaningful impact on several areas of existing OneStream functionality such as:

• Existing Aggregation Functionality (C#Aggregated)

• Traditional Constant Currency Analysis / Auto-Translation Currencies

• Unnecessary Data Integrations Built Solely for the Purpose of Bringing Data into the Cube

• Relational Data Reporting / BI-Blend

• Traditional Hybrid Scenarios

• Attribute Members

• Intercompany Mismatch Reporting

• Bloated Data Record Tables and Data Unit Performance Issues

Performance

One of the most surprising aspects of DCS is how fast it performs, given what it is actually doing. Because it continues to rely on the proven approach of querying the data record tables, performance remains comparable to that of a traditional cube. One thing worth noting is that the first time you pull on DCS shared data, it has not yet been cached, so initial execution will take a bit longer. Subsequent runs, however, are significantly faster. Below are some examples of the performance we have observed so far when using DCS cube data sharing.

Key Points to Remember

Although Dynamic Cubes introduce a new way of sourcing and sharing data, they behave much like traditional OneStream cubes from a user and tooling perspective. Dynamic Cube data can be exported through Data Management Sequences, supports drill down, and can be consumed by Cube Views and reports just like a standard cube. It is also bound by the traditional cube architecture data unit sizing best practices, so thoughtful design is still required. As a result, anything you would typically expect to do with a traditional cube can also be done with a Dynamic Cube, without requiring changes to existing reporting or operational workflows.

DCS can be added to existing applications to alleviate some of the challenges clients may be facing (aggregating data, FX / Constant Currency translations, awkward relational data reporting, performance issues), so there is plenty of opportunity to leverage DCS without starting over.

Conclusion

DCS represents a significant shift within OneStream, with far-reaching implications for application design. How we design applications will continue to evolve as DCS expands, with purpose-built cubes for physical data storage sitting alongside DCS Cubes that draw on that data for reporting purposes.

As early adopters of DCS, our development team built much of the enabling framework from scratch with the support of OneStream’s Product Team. This allowed us to work through the underlying concepts and establish practical ways to apply the capability. Once those concepts are understood, DCS proves to be quite intuitive in how it shares and consumes data. It’s encouraging to see, based on OneStream’s feedback, that DCS continues to mature as a platform capability, and we hope to see more of this functionality delivered out of the box over time.

Unlock the Potential of DCS with Ascend Partners

With 90+ OneStream implementations delivered, Ascend Partners brings deep, hands‑on experience with modern OneStream architecture, including Dynamic Cube Services. We combine strong technical expertise with a practical understanding of finance and operations to design scalable solutions that align with how data is consumed.

The result is cleaner models, improved performance, and architectures built to support long‑term performance management. If you’re evaluating where DCS can simplify design or address persistent challenges, we’re always open to continuing the discussion.

About the Author

Mike Dewis, Vice President, Application Delivery at Ascend Partners, brings over two decades of finance systems and OneStream implementation experience. As a Certified OneStream Professional and Lead Architect, he leads teams that architect scalable, high-performance solutions for some of the most advanced and complex clients in the ecosystem.