Bridge
Bridge vs Cube

Cube is infrastructure your engineers build on. Bridge handles the ask your customer made.

Custom fields, dashboards, exports. Handled in chat by your CSM, on your API. No metrics layer to build.

Start free guided pilotSee the comparison

Free for 14 days on one of your customers. No card.

At a glance
CubeBridge
What it is
A governed metrics layer for engineers
A chat tool for your CSM, on your API
Who uses it
Your engineers, defining metrics in code
Your CSM, typing the ask in chat
What it ships
Governed metrics served to your apps via API
The one-off view a customer asked for
Custom one-off ask
A metric to model in the semantic layer first
Handled in chat
Custom fields
Defined in the data model, in code
Calculated live on every record
Time to a new ask
An engineering cycle to model and surface it
Minutes
6 of 12 differences shownSee all

Why choose Bridge over Cube.

Cube is the metrics layer your engineers build on, so every custom ask is still a build. Bridge sits on your API and handles them in chat.

01Workflow

Handled in chat, not modeled in code.

Cube is where your engineers define metrics and serve them to your apps. A new view still means modeling a metric and building a UI on the API. Bridge sits on your API. The CSM types the ask in chat, Bridge builds the view, the link goes back in the same conversation. No layer to build.

See the full comparison
bridge_chat
live
Show every load 24h+ late, by carrier and lane.
calling /shipments · grouping by carrier · building view
late-loads.bridge.link/acme
shared
Sent back in the same conversation. No ticket opened.
02Custom dashboards

Built in chat, not on a metrics API.

A new customer dashboard on Cube means an engineer models the metric in the semantic layer first. Bridge builds the one your customer asked for once, in chat against your API, scoped to that customer and shared as a white-labeled link they open themselves.

Start a free pilot
late_loads_view
shared
loads late
42
carriers
7
avg delay
31h
late by lane
03Custom fields

Calculated live, not defined in code.

Bridge adds calculated fields across every record without a change to your data model or a deploy. No engineering ticket, no migration scheduled. The field is live the moment the formula resolves.

Start a free pilot
contacts
calculated
ContactActivity 90dchampion_strength
Acme Corp142 events92High
Globex88 events64Med
Initech31 events27Low
calculated live · no schema change
04Custom exports

In their format, not built on the API.

Bridge writes a CSV in the shape your customer asked for, with custom and calculated columns included. Saved as a view they can re-run. Their format becomes the default, with no export feature to build on the metrics API.

Start a free pilot
export.csv
custom format
invoicedays_overduepriority_score
INV-204161High
INV-203834Med
INV-210212Low
custom + calculated columnsdownload
05Speed

Minutes, not an engineering cycle.

On Cube, a custom ask is an engineering task: model the metric, deploy, build a UI on the API. In Bridge, the CSM types the ask, Bridge calls your API and builds the view, and the link goes back in the same conversation.

Start a free pilot
time_to_delivered
measured
Bridge4 min
CubeDays. Quarters.

from the moment the CSM relays the ask

Where they actually differ.

The capabilities that decide which tool fits the ask in front of you.

Cube
Bridge
Built by your CSM, no engineering
Cube: no
Bridge: yes
Installed on your API in minutes, no layer to build
Cube: no
Bridge: yes
Delivered in minutes, not an engineering cycle
Cube: no
Bridge: yes
Custom dashboards, handled in chat
Cube: no
Bridge: yes
Custom fields without a data model change
Cube: no
Bridge: yes
Custom exports in the customer's format
Cube: no
Bridge: yes
Delivered in chat with no semantic layer to model first
Cube: no
Bridge: yes
Customer stays in the conversation, no app to write
Cube: no
Bridge: yes
Per-customer scoping from your API auth
Cube: no
Bridge: yes
Unlimited CS seats, no per-developer fees
Cube: no
Bridge: yes
A governed semantic / metrics layer
Cube: yes
Bridge: no
Define metrics once, serve them to many apps via API
Cube: yes
Bridge: no
A governed semantic layer your engineers model and own
Cube: yes
Bridge: no
Open source, self-host free (Cube Core)
Cube: yes
Bridge: no
Verified June 2026cube.dev/pricing

Should you choose Bridge or Cube?

Bridge sits on your API and handles custom asks in chat. Cube is the governed metrics layer your engineers build your product's analytics on. They cover different jobs.

Best for most teams

Choose Bridge

  • Custom dashboards
    The one your customer asked for once, built in chat and scoped to them.
  • Custom fields
    Calculated across every record, live, with no model change or deploy.
  • Custom exports
    A CSV in the customer's format, with calculated columns included.
  • One-off asks
    Anything no app surfaces today, handled in minutes by your CSM. No engineering involved.
Start a free pilot

14-day pilot. One customer. No card.

Different job

Choose Cube only if

  • You need one governed metrics layer powering your product's analytics.
  • Your engineers want to define metrics once and serve them to many apps.
  • You have engineering capacity to model, deploy, and maintain that layer.
  • You want an open-source, self-hosted core.

Still deciding which tool fits the ask?

If your engineers need a governed metrics layer to build on, that is Cube. If you want a customer's one-off ask handled in chat without an engineering build, that is Bridge.

Start a free pilot
  • 14-day pilot on one customer
  • No card to start
  • Keep Cube for your metrics layer

The questions we get most.

Yes. They cover different jobs, so you can run both. Cube as the governed metrics layer your engineers build your product's analytics on. Bridge for the one-off asks your customers make through your CSM that no app surfaces.

Yes. They type the ask in plain English. Bridge calls your API, computes whatever needs computing, and builds the view. No metric to model. No code to deploy. No engineering pulled in.

No. A governed metrics layer your engineers define once and serve to many apps is Cube's job. Bridge sits on your API and handles a customer's one-off ask in chat, shared as a white-labeled link. Cube is infrastructure your engineers build on; Bridge is the CSM handling a customer's ask. If you need a metrics layer powering your product, use Cube. It is excellent at that.

Cube Cloud now ships its own dashboards and analytics chat too, but they sit on a semantic layer your engineers model and maintain first. Bridge needs no semantic layer: it handles the customer's one-off ask directly in chat against your API. Different audience, different job.

No. Bridge is hosted only. Cube Core is open source and free to self-host. If a self-hosted, open-source metrics layer is what you need, Cube is the right call. The Bridge value is removing the engineering ticket your CSM was about to open.

Cube Core is open source and free to self-host. Cube Cloud has a free dev tier, then $40 per developer per month on Starter and $80 per developer per month on Premium, with Enterprise quote-only, and Cloud usage is consumption-based on Cube Consumption Units. Bridge is $199/month for up to 5 connected customers, with unlimited CS seats. Past 5, pricing moves to enterprise and we size it with you. The pilot is free for 14 days, no card. Different models. See the Bridge pricing page for detail.

Only what your API exposes. Queries are authenticated per session. Per-customer activity logs are on by default. We do not train models on your data.

Still on the fence?Book 20 minutes with the founder

Start saying yes to custom asks without an engineering build.

14 days. One customer. Free. Then $199/month for up to five connected customers, enterprise past that.

Start free guided pilotSee pricing