Skip to main content
Omni offers a range of deployment options, from a single-instance setup to multi-instance, multi-region architectures. This guide helps you identify the right starting point based on your actual requirements. Our recommendation: Start with the simplest architecture that meets your requirements. The vast majority of teams can accomplish what they need within a single Omni instance. Multi-instance deployments add operational overhead — they’re worth it when the requirements genuinely call for them, and not before.

What’s your primary requirement?

→ Single instance deployment with git and dbtThis is the most common Omni deployment. A single instance with git integration gives you branch-based development, pull request workflows, and the Content Validator — everything you need to manage changes safely without running a separate production environment.If you’re using dbt, the same guide covers connecting your dbt project and syncing metadata into the model.
→ Single instance deployment with dynamic database environmentsDynamic connection environments let your developers switch to a staging database within an Omni branch — so model changes can be tested against non-production data without maintaining a separate Omni instance.This is the right choice when:
  • You have analytics_prod and analytics_dev databases
  • All developers are allowed to see both databases
  • You don’t need true environment isolation between developers and production users
→ Multiple instance deployment with git followerWhen you need two fully isolated Omni environments — one where development happens and one where production users live — a two-instance git follower setup is the right architecture. Developers work entirely in staging; production is updated only through deliberate git-based promotions.This is the right choice when:
  • Organizational policy prohibits developers from having production access
  • You need a stable, read-only production environment
  • You want to preview full model and content state in a production context before going live
→ Multiple instance deployment with multiple regionsFor teams with data residency requirements or globally distributed operations, the multi-region pattern extends the two-instance architecture into a full matrix of environments and regions. It’s the most operationally robust pattern — reserve it for situations where it’s genuinely required.This is the right choice when:
  • Regulations require data to reside in specific geographic regions
  • You need DEV, STAGE, and PROD isolation across US, EU, and other regions simultaneously
  • Your team has the operational capacity to manage nine (or more) Omni instances

How much review does your content need?

Use standard Omni permissions — apply view, edit, and manage rights by folder and group. The branch/publish workflow provides a natural review gate without enforcing it.
Enable Require pull requests in git settings. This blocks direct commits to your default branch and requires all model changes to go through a PR. For content, you can additionally enable Require PR to publish at the document level — this prevents any published document from being updated without a reviewed PR.
Use document-level Require PR to publish selectively on your highest-stakes dashboards, while leaving standard draft/publish behavior on everything else.
Use a multi-instance setup with git follower. Production users see only the promoted, validated state of your model and content.

How do you manage database schema changes?

Standard schema refresh works well. Use soft refreshes (additive only) for routine updates. Run a full hard refresh only when you need to remove references to dropped objects.
Enable branch-based schema refresh on your connection. This routes schema refreshes through a branch before they can be merged, preventing the force-push that a regular schema refresh would require.
Open a branch, switch to your staging connection through dynamic environments, trigger the schema refresh there, and validate before merging.
Use the schema refresh API, Agent Skills, or CLI to trigger refreshes from your pipeline and for bulk model updates in a local IDE workflow.

How should you scope data access across your team?

How do you structure both internal and embedded (external) users?

The right answer depends on whether internal and external users share the same data or need complete isolation:
  • Shared data, different access rules: A single instance with user attributes and row-level security handles this well. Use model extensions if external customers need customized views.
  • Separate databases per customer: Dynamic connection environments plus model extensions is the standard embedded pattern.
  • Full isolation between internal and external: Consider separate Omni instances for internal and embedded deployments, using git follower to keep models in-sync.

Decision tree summary

Deployment pattern guides