Aserto vs Oso Technical Comparison

If you’re evaluating alternatives to Aserto after their announcement to sunset their SaaS platform, it's important to understand how other solutions stack up—not just in terms of features, but in architecture, operational burden, and long-term flexibility. In this post, we go deep into the technical differences between Aserto and Oso across critical areas like infrastructure, performance, modeling, and scalability.

For the full overview on why teams are moving away from Aserto and how to evaluate your next authorization provider, read the companion post: Migrating from Aserto? Why Oso is the Best Alternative.

Fully Managed Infrastructure

Feature Aserto Oso
Deployment Requires operating edge authorizers (Topaz) with local state replication Fully managed cloud service, no infra to operate
Consistency Lag 1–2 minutes behind source of truth Immediate consistency in Oso Cloud
Scaling You scale and shard per-tenant manually Oso Cloud scales elastically with zero effort

Migration Tip: With Oso, you no longer need to maintain and tune edge nodes. Simply model your logic and let us handle uptime and performance.


List Filtering and Querying

Feature Aserto Oso
List Filtering Only supported via Directory API; policy logic not applied Supported directly via query API with full policy logic
Combining Policy + Graph Logic Can’t combine OPA logic with Directory traversal Seamless combination in a single query
Negation Support Not applied during graph traversal Fully supported in query logic

POC Tip: Try filtering a list using a policy that includes a negation condition. For example, the policy might allow users to be banned from projects. A banned user shouldn’t be able to see a project, even if they still have a role on the project (not an uncommon scenario). When you ask: “Show all projects the user has access to,” Oso will return the correct list - excluding the banned projects based on the policy logic. Aserto can’t evaluate this kind of condition during list filtering; it only applies policy logic at decision time, not during traversal.

Example Aserto Limitation:

Negation in Rego

# Aserto can't filter lists when policy says:
allow if not banned

Negation in Oso:

polar

allow(user, "read", resource) if
  not banned(user) and
  has_permission(user, "read", resource);

Oso will correctly filter out banned users, Aserto won't without removing their relations manually.


Latency of Data Sync

Feature Aserto Oso
Data Propagation Time Up to 1–2 minutes to reflect data changes at edge Data is evaluated immediately once available in Oso Cloud
Sync Mechanism Postgres ➝ Rego ➝ Allow Cache ➝ Edge Postgres ➝ Edge (sync not required if using local evaluation)
Local Evaluation BoltDB-based store at edge; complex to manage Facts are derived from your local database with no syncing

Migration Tip: If latency of permissions propagation is a concern, Oso’s centralized but globally distributed model ensures sub-10ms evaluations without sync delays.


Modeling Nested Groups & Hierarchies

Feature Aserto Oso
Nested Groups No first-class support Full support using relationships in Polar
Resource Hierarchies Complex to represent cleanly Simple to express with nested resources + role inheritance
Custom Roles Defined in both a manifest (YAML/JSON) and Rego policy; must be updated in both to reflect changes Defined directly in policy as logic rules; dynamic and declarative

POC Tip: Model a team inside an org with delegated permissions. Oso models this in a few lines of Polar.

Handling Large Data Sets

Feature Aserto Oso
Embedded Store Limits BoltDB has size limits (~few GBs); manual sharding Oso Cloud imposes no arbitrary limits on data size
Scaling Strategy Shard tenants across multiple edge nodes No manual sharding required; managed automatically

Migration Tip: If you’re running into scaling ceilings or planning to grow, Oso's hosted infrastructure lifts those limits.

Policy Updates & Deployment

Feature Aserto Oso
Policy Change Workflow Multi-step: build → tag → push → create policy instance → update app Single step: push changes directly to Oso Cloud via CLI
Promotion Between Envs Manual tagging, env updates required Simple CLI-based push to staging or production
Rollback + Versioning Via registry images and instance tags Via Oso environment versions, push history available

POC Tip: Make a logic-only change. In Oso, push and test it immediately. Aserto requires environment or instance updates even for small changes.

Extending Authorization Models

Feature Aserto Oso
New Object Types Requires manifest updates + policy artifact build Define in Polar and push via CLI
New Relations or Permissions Multi-step with CLI or UI + policy update One-step rule addition
Iteration Speed Slow and UI-dependent, structured around artifacts Fast, testable, and version-controlled via code

POC Tip: Add a new permission or relationship and use it in logic. With Oso, you go from idea to enforcement in minutes, no manifest or build required.

Wrapping Up

When it comes to migrating authorization systems, technical details matter. Oso was built with developer experience, scalability, and clarity at its core—so you can model complex permissions without brittle workarounds or heavy infrastructure. Whether you’re dealing with nested groups, high data volumes, or rapid policy iteration, Oso gives you a modern, unified authorization solution you can trust.

Let us know if you'd like help translating your Aserto setup to Oso. We’ve done plenty of migrations and can help you go live in weeks, not months.

Level up your authorization knowledge

Learn the basics

A list of FAQs related to application authorization.

Read Authorization Academy

A series of technical guides for building application authorization.

Explore more about Oso

Enterprise-grade authorization without redoing your application architecture.