What’s the difference between Embeddable Managed Cube and my own Cube Core / Cube Cloud?

FAQs
1

What’s the difference between Embeddable Managed Cube and my own Cube Core / Cube Cloud?

What are the two ways to use Cube with Embeddable?

Embeddable supports two ways of working with Cube:

:one: Embeddable Managed Cube (Default)

This is the built-in, fully managed Cube layer that comes included with Embeddable.
It is the default experience and what most of our documentation refers to.

With Embeddable Managed Cube:

  • Data modelling is done inside Embeddable.

  • Database connections are configured in Embeddable.

  • Environments are managed in Embeddable.

  • Caching and pre-aggregations are managed by Embeddable.

:two: Cube Core / Cube Cloud (BYOC — Bring Your Own Cube)

In this setup, you run your own Cube instance:

You connect your Cube instance to Embeddable via the Data Provider API.

With BYOC:

  • All data modelling is done in your own Cube instance.

  • Database connections are configured in Cube.

  • Environments are managed in Cube.

  • Caching and pre-aggregations are managed in Cube.

Embeddable connects only through the Data Provider API.

Why does the UI look different for Cube Core / Cloud customers?

Most of Embeddable’s UI and documentation assume you are using Embeddable Managed Cube.

If you are using Cube Core or Cube Cloud, some features will not appear or will not apply to you — and this is expected behaviour.

Below are the key differences.

Why can’t I see the Data Model Editor?

The Data Model Editor is only available to Embeddable Managed Cube customers.

If you are using Cube Core or Cube Cloud:

  • You define and manage models inside your own Cube instance.

  • Those models are then synced into Embeddable.

  • You do not need the Data Model Editor in Embeddable.

If you cannot see it, nothing is wrong — it simply doesn’t apply to your setup.

image
image1920×1036 89.6 KB

image
image2048×1105 178 KB

What is the “Refresh” button next to Datasets for?

The Refresh button is specifically for Cube Core / Cube Cloud customers.

When you:

  1. Make changes to your models in Cube, and

  2. Want those changes reflected in Embeddable

You must click Refresh to sync the updated models via the Data Provider API.

image
image792×706 51.4 KB

Embeddable Managed Cube customers do not typically need this.

Do I need to use Environments or Connections in Embeddable?

No — not if you are using Cube Core or Cube Cloud.

The following pages are specific to Embeddable Managed Cube:

If you are using your own Cube instance:

  • Your database connections live in Cube.

  • Your environments live in Cube.

  • Embeddable only connects through the Data Provider API.

Which documentation sections do NOT apply to Cube Core / Cloud customers?

The following sections are written for Embeddable Managed Cube customers and are not operationally relevant to BYOC customers:

  • Connect Your Data (except Data Provider API)

  • Data Modelling (except SQL-Based Security (row-level security))

  • Caching / Pre-aggregations (managed within Embeddable)

  • Embeddable Caching API

Important exception:
SQL-Based Security (row-level security) does apply to all customers, including Cube Core / Cloud.

Can Cube Core / Cloud customers still read the data modelling docs?

Yes.

The Embeddable data modelling docs are helpful for understanding concepts.

However:

:backhand_index_pointing_right: Your source of truth for modelling, schema definitions, caching, and pre-aggregations is the Cube documentation.

All configuration must be done in your Cube instance.

What features apply to ALL customers?

The following areas apply equally to both setups:

  • Building components

  • Creating dashboards

  • Embedding

  • Theming

  • Component SDK

  • Row-level security (SQL-based security)

Everything related to the UI and embedding experience works the same way.

How does Row-Level Security (RLS) work for Cube Core / Cloud customers?

All customers — including BYOC — can test RLS in the Embeddable Builder using:

presets/security-contexts.sc.yml

This file defines named security context presets used during testing.

Example

- name: default
  securityContext:
    country: United States
    language: English
  dataProvider: default 
 
- name: main-instance
  securityContext:
    country: Germany
    language: German
  dataProvider: main-instance

Each preset:

  • Defines RLS identifiers (e.g. country, customer_id)

  • Specifies which dataProvider to use

This allows you to test SQL-based security directly in the Embeddable Builder.

How do Cube Core / Cloud customers connect to Embeddable?

You connect using the Data Provider API.

That is the only required integration point.

You do NOT need to:

  • Configure database connections in Embeddable

  • Set up environments in Embeddable

  • Create data models in Embeddable

All of that is handled in Cube.

Where do I check errors?

If you are using Cube Core / Cube Cloud:

  • Errors originating from Cube must be investigated in your Cube logs and monitoring tools.

  • Embeddable does not have visibility into your Cube instance.

If you are using Embeddable Managed Cube:

  • Our team has full log visibility.

  • We can help investigate lower-level Cube issues directly.