Aller au contenu

OSS vs Enterprise

OpenDome est open-core. Le moteur que vous faites tourner et consommez est open source sous Apache-2.0. Le tier géré/Enterprise ajoute l’orchestration centrale, une console, des packs curatés et du tooling de compliance par-dessus exactement les mêmes charts de la cellule — rien dans l’open core n’est bridé pour vendre l’upgrade.

Fonctionnalité OSS Apache-2.0Enterprise Commercial
Cellule (data plane par tenant, Helm)
Moteur OSL — les 13 endpoints /osl/*
Spec OSL, JSON Schemas, conformance
Connecteurs — Postgres, MySQL, Salesforce, taps Singer custom
Embedder + retrieval hybride Lance
Application des politiques (SQL allowlist, row filters, projection) — fail-closed
Émetteur de tokens local (HS256 par tenant)
Auto-hébergé sur votre propre Kubernetes
Console — UI de domain-map, modeleur sémantique, previews gouvernées
Control-plane — provisioning multi-tenant, cycle de vie, rotation des JWT
BYO-OIDC — frontez le moteur avec votre IdP, faites confiance à X-Actor-Roles
Packs verticaux — modèles et métriques curatés Finance / Legal / HR
Connecteurs premium — SAP, Workday, ERP bancaire
Pack de compliance — chaîne d’audit, artefacts AI Act / DORA / GDPR
Agent packs — manifests MCP préconfigurés
Cloud géré + SLA + support

La cellule est le même artefact dans les deux éditions. Les différences sont ce qui tourne autour :

OSS — cellule standalone

Vous installez charts/standard-tenant + charts/tenant-semantic-api. La cellule émet ses propres tokens HS256, applique la politique in-process et sert OSL via son propre Ingress. Le namespace du control-plane n’existe jamais.

Enterprise — flotte gérée

Un control-plane central provisionne et fait tourner de nombreuses cellules, émet les JWTs, proxie les appels de la console (en transmettant X-Actor-Roles pour que la cellule applique toujours l’ACL de l’appelant) et ajoute les packs, la compliance et le support.

Quelques fonctionnalités sont documentées dans la spec OSS mais sont publiées derrière le tier Enterprise ou sont encore en cours d’atterrissage — la documentation le dit inline plutôt que de laisser croire à une couverture complète :

  • La résolution MetricFlow dans POST /osl/query est planifiée ; aujourd’hui l’endpoint sert un slice SQL gouverné. Voir la référence de query.
  • Le CLI osl et la suite de tests de conformance sont des épics à venir.
  • Les joins cross-model / le moteur de métriques pour les attributs de JointEntity sont différés — ces attributs résolvent à null dans le slice actuel.