Skip to main content

New Edge PDP

A Policy Decision Point with an embedded on-disk database, kept in sync over a durable event stream.

The New Edge PDP is a ground-up rewrite of the PDP runtime, shipped as permitio/pdp-v3. It runs one container per Permit environment, holds a local, on-disk copy of that environment's policy and authorization data, and answers authorization queries with no network call in the decision path.

Availability

The New Edge PDP is a new deployment option, not a replacement. The container PDP (permitio/pdp-v2) remains fully supported and continues to be the right choice for the capabilities listed under Feature Parity.

It is currently in early access and enabled per account. Contact us to have it turned on.

Why a new runtime​

The container PDP holds your authorization data inside OPA, and OPA's data store is a single in-memory JSON document. That one design choice sets two ceilings.

It is not a graph store​

A JSON document has no indexes and no concept of edges. It cannot be optimized for graph traversal, or for the granular, relationship-heavy queries that ReBAC and derived roles depend on — questions like "does this user reach this resource through some chain of roles and relationships?"

The New Edge PDP moves those questions out of the JSON document entirely. Relationship data lives in an embedded database built for graph traversal, and OPA queries it over a local loopback while it evaluates policy. Policy evaluation and graph traversal each run on something designed for the job.

It is expensive in memory​

Because the fact graph lives in memory, a large environment needs a large PDP. OPA's own documentation is direct about the cost:

Memory usage scales with the size of the policy (i.e., Rego) and data (e.g., JSON) that you load into OPA. Raw JSON data loaded into OPA uses approximately 20x more memory compared to the same data stored in a compact, serialized format (e.g., on disk).

— OPA documentation: Policy Performance

The New Edge PDP stores exactly that compact, serialized form on disk, and keeps a bounded cache in memory. Memory becomes a number you set rather than a function of how much data your environment holds.

Updates cost a round trip​

There is a third ceiling, in how data arrives rather than where it lives. The container PDP refreshes by reacting to a notification and then fetching the changed data back from Permit's API. A notification says that something changed; a second call is needed to find out what. And catching up after a disconnect means re-fetching, because there is no server-side record of what a given PDP has and hasn't seen.

On the New Edge PDP, updates arrive already containing the change, and the control plane durably retains each PDP's unacknowledged changes until that specific PDP confirms it applied them.

What it gives you​

  • Decisions that never leave the container. Every hop in the request path is loopback or local disk, so no authorization query depends on reaching Permit.
  • Memory you control. The data set lives on disk; a configurable cache bounds what is resident.
  • Sync that survives disconnection. Changes are retained per-PDP, server-side, until that PDP acknowledges them — no re-fetch on reconnect.
  • Availability over freshness. A control-plane outage costs you freshness, never the ability to answer. The PDP serves from its local copy indefinitely, and reports how stale it is.

See Architecture for what runs inside the container, and How It Works for how the local copy is kept current.

Choosing between the two​

Choose the container PDP when you needChoose the New Edge PDP when you need
ABAC, condition sets, user or resource setsLarge data sets without a large memory footprint
Policy-as-Code / custom Rego bundlesRelationship queries served from a graph-capable store
Read-your-own-writes / local factsDecisions that never depend on reaching Permit's API
URL-based enforcement or Kong integrationSync that survives long disconnections without a re-fetch
Custom data sourcesTo drop the Python and OPAL layer entirely
A Prometheus /metrics pipeline, or deployment without persistent storageObservability through structured logs and detailed health endpoints

Both connect to the same Permit environment and enforce the same policies you author in Permit. You can run them side by side while you evaluate.

See Feature Parity for the full comparison.

Contents