docs(nexus-pdp): publish measured check latency and capacity, and correct memory and disk sizing (early access) by EliMoshkovich · Pull Request #670 · permitio/docs

EliMoshkovich · 2026-10-05T21:51:11Z

PER-16873. The figures come from the Nexus PDP check benchmark of Oct 9–10, 2026.

This PR does two things on the early-access Nexus PDP pages.

1. New Nexus PDP benchmarks page (/concepts/pdp/nexus-pdp-benchmarks), in the Cloud PDP Benchmarks page's format:

Server-side check latency (P50/P95/P99) at about 55 req/s and 10 concurrent requests, for RBAC and ReBAC depth 0–3, on a small data set and with about 20 million facts.
Capacity per instance at 2 and 4 vCPU and with 20M facts, plus capacity with 1, 2 and 3 instances.
4 vCPU gives 1.56× (below 2×) for most patterns and 1.95× (consistent with 2×) for depth 2. The instance was throttled at its CPU limit during the capacity runs.
Scale-out is consistent with linear at 3 instances. With 2 instances RBAC is one step below 2×; the cause is not established.
The 20M runs also differ in the checks' own (smaller) data and in the memory limit (10 vs 4 GiB).
Small-data-set memory is about 0.15–0.2 GiB.
Memory peak during snapshot load (about 5.3–6.7 GiB) and data volume use (about 7.4 GiB) with about 20M facts.
Capacity method: an open-model arrival rate rising 25% every 2 minutes, up to 200 concurrent requests. The latency bound is 30 ms (RBAC) and 40 ms (ReBAC), the average P99 on the Cloud PDP page.
Every response was checked against its expected decision. No run had a failed request or a wrong decision.
Methodology, access patterns with parent-relationship counts, data set contents, key results, and the limits of the results: one build, one region, x86 only, synthetic data, single-path users, no ABAC conditions, serving checks only.
Sizing guidance with a worked example, labelled as guidance rather than measurement.
Build 0.7.0-beta.50, AWS us-east-2. No cold-start figures.

The page is written to be shareable with any prospect as-is: generic, with no customer named and no internal details.

The page is linked from the Nexus PDP overview, How It Works (replacing the "no published throughput figures" caution), Deployment, Configuration, the PDP overview, the Cloud PDP Benchmarks page and the sidebar. Deployment also gets a new CPU requirement row, and 2 CPUs in the Docker and pod-spec samples (separate commit). The route inventory baseline includes the new route, and the early-access callouts are dated October 2026.

2. Memory and disk corrections, kept from earlier revisions:

A 2.5 GiB minimum memory limit: below 2304 MiB the embedded database can stop applying changes without reporting it (last verified on 0.7.0-beta.26).
The cache is sized from the container's memory limit.
The SURREAL_ROCKSDB_* variables only affect the snapshot step.
The pod spec gets a memory limit and a startup probe.
Disk: about 3× the snapshot during a cold start, and at least 4× during a rebuild.

How it was checked:

Every figure was checked against the benchmark's extract tables.
An independent deep review found 25 wording and method items, all fixed in abf6ef9 and 351bdba. No figure needed correcting.
a8e09ac addresses Zeev's third review: 4 vCPU ratios per pattern, scale-out arithmetic, the 20M capacity drop, the large data set's composition, memory, sizing beyond 3 instances, the probe wording and Next-steps length.
141b54a removed an incorrect explanation of the 2-instance RBAC result ("per-connection load balancing"): the request split at the failing steps was near even. It added the 20M-fact memory and disk data points and the data-set caveat.
ddc0105 drops the statements that the checks don't query the 20 million facts (review feedback). The large-data-set caveat now names only the checks' smaller data and the memory limit.
npm run build passes (0 bad links or anchors; routes and sidebars OK). cspell is clean on the Nexus PDP pages.

Sign-off on the figures: omer9564 approved the version with the published latency and capacity figures at a8e09ac, and ddc0105 applies the one comment from that review.

Description updated during review to match ddc0105 (the benchmark source line, the sign-off line, and the ddc0105 change).

🤖 Generated with Claude Code

…ly access) PER-16873. From the PER-16040 staging scale test (nexus-pdp 0.7.0-beta.26, default storage-engine settings, 2.0M / 10.8M / 20.0M facts). Memory grows with the data set and peaks during a cold start (~6.5 GiB at 20M facts), so 'memory you configure' and a flat 4 GiB are corrected. No latency or throughput figures. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

netlify · 2026-10-05T21:51:17Z

✅ Deploy Preview for permitio-docs ready!

Name	Link
🔨 Latest commit	`ddc0105`
🔍 Latest deploy log	https://app.netlify.com/projects/permitio-docs/deploys/6ad0dc98b44259b93dcedc4b
😎 Deploy Preview	https://deploy-preview-670--permitio-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

linear-code · 2026-10-05T21:51:18Z

PER-16873

Copilot

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

zeevmoney

Changes requested — 1 HIGH, 9 MEDIUM, 5 LOW.

Blocking:

HIGH docs/concepts/pdp/nexus-pdp-how-it-works.mdx:147 — no memory floor; below about 2.5 GiB Nexus PDP can stop applying updates without an error

Non-blocking:

MEDIUM docs/concepts/pdp/nexus-pdp-how-it-works.mdx:142 — 2.0M cold-start memory isn't from the measured build; that run peaked under load
MEDIUM docs/concepts/pdp/nexus-pdp-how-it-works.mdx:144 — 20M serving memory "~2.7 GiB" isn't in the measurements (1.7–3.2 GiB)
MEDIUM docs/concepts/pdp/nexus-pdp-how-it-works.mdx:146 — "+0.5" in the cold-start formula has no source; rebuilds not covered
MEDIUM docs/concepts/pdp/nexus-pdp-how-it-works.mdx:140 — peaks are sampled lower bounds; runs had 8/32 GiB limits
MEDIUM docs/concepts/pdp/nexus-pdp-how-it-works.mdx:150 — 5.8 GiB reading doesn't show the disk guidance holds
MEDIUM docs/concepts/pdp/nexus-pdp-how-it-works.mdx:128 — sentence above the caution still says memory depends on cache sizes you set
MEDIUM docs/concepts/pdp/nexus-pdp.mdx:61 — the memory limit, not a setting, sizes the serving cache in this build
MEDIUM docs/concepts/pdp/nexus-pdp-deployment.mdx:25 — pod spec sets a memory request but no limit
MEDIUM docs/concepts/pdp/nexus-pdp-how-it-works.mdx:131 — configuration reference and PDP overview still give the old memory guidance
LOW docs/concepts/pdp/nexus-pdp-how-it-works.mdx:148 — cold-start growth claim needs its CPU caveat
LOW docs/concepts/pdp/nexus-pdp-deployment.mdx:31 — name the startup-probe endpoint and the CPU count
LOW docs/concepts/pdp/nexus-pdp-how-it-works.mdx:152 — "deliberately heavier than a typical one" has no source
LOW docs/concepts/pdp/nexus-pdp-how-it-works.mdx:123 — "grows far more slowly" has no like-for-like measurement
LOW docs/concepts/pdp/nexus-pdp-how-it-works.mdx:138 — small consistency fixes in the new section

Details are in the inline comments on each line.

Copilot

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

…873) - Add the 2.5 GiB memory floor (PER-16808) to the caution, the sizing bullet, the deployment Memory row and the configuration reference. - Describe the serving cache as sized from the container memory limit (SurrealDB 3.2.4 defaults); scope the SURREAL_ROCKSDB_* variables to the snapshot load; add a memory limit to the pod spec. - 2.0M row: cold-start peak "Not recorded"; serving ranges from the 10 s container working set (2.1-2.9 GiB at 10.8M, 1.7-3.2 GiB at 20M); note the peaks are sampled lower bounds and the runs' 8/32 GiB limits. - Scope "peaks during a cold start" to large data sets; drop the unsourced +0.5 GiB end of the formula; note a rebuild was not measured. - Disk: report measured use (0.33 / 1.6 / up to 5.8 GiB) and size the volume from the snapshot (3x cold start, 4x rebuild, unbounded event store). - Cold start: CPU caveat, /health/ready startup probe, the node wait. - Cite the container PDP's 6 KB-per-object estimate as an estimate. - Consistency: Google Drive-style, role assignments in the change stream, image digest, facts link on the deployment page. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

…-sizing' into eli/per-16873-nexus-pdp-measured-sizing

Copilot

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

…ecovery (PER-16873) - 2304 MiB (2.25 GiB) is the stall point; 2.5 GiB the minimum to run at. - Nexus PDP keeps answering from the data it already has; beta.26 reports nothing, and at 2 CPUs or fewer the process can stop answering. - Restart to recover; decimal memory units count as written. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

EliMoshkovich · 2026-10-06T18:27:25Z

Follow-up on the two points that were open before customer-facing use. Both are now backed by a test or the owner's ticket, not only the source.

1. The memory limit sizes the serving database; SURREAL_ROCKSDB_* doesn't. I tested the measured image locally (permitio/nexus-pdp:0.7.0-beta.26@sha256:fa7012ad…, --dev-fake-data-plane, --network none, fake key) and read the serving database's RocksDB OPTIONS file at each memory limit:

`--memory`	write buffers
2g, 3g	2 × 64 MiB
4g, 8g	4 × 64 MiB
none (35 GiB Docker VM)	8 × 128 MiB
4g + `SURREAL_ROCKSDB_WRITE_BUFFER_SIZE=32 MiB`, `…_MAX_WRITE_BUFFER_NUMBER=3`, `…_BLOCK_CACHE_SIZE=256 MiB`	4 × 64 MiB (variables ignored)

This matches the table in the configuration reference, and PER-16808's bisect ("the embedded SDK ignores SURREAL_ROCKSDB_*"). The block cache size isn't in OPTIONS; its formula comes from SurrealDB 3.2.4's cnf.rs, as quoted in PER-16808.

2. The stall caution now matches PER-16808 and @omer9564's draft customer page (cloud-pdp #270, edge-memory.md):

2304 MiB (2.25 GiB) is the stall point, and 2.5 GiB is the minimum to run at.
Nexus PDP keeps answering from the data it already has.
As of 0.7.0-beta.26 it reports nothing. At 2 CPUs or fewer the process can stop answering, which a /health liveness probe catches.
Restart to recover.
Decimal memory units count as written.

When a release carries cloud-pdp #306 (refuse to start below the floor) and #292 (ingest down, stalled_since, the write-stall metric), this caution should switch to that behavior and to the draft's "Watching for a stalled database" section. Likewise, the event-store note should change when a release carries PER-16705 (#299).

🤖 Generated with Claude Code

Copilot

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

zeevmoney

Approved — no CRITICAL or HIGH issues found.

Non-blocking:

MEDIUM docs/concepts/pdp/nexus-pdp-how-it-works.mdx:150 — the recommended limits cover a first boot, not a rebuild
LOW docs/concepts/pdp/nexus-pdp-how-it-works.mdx:144 — the 2.0M row's serving range mixes two builds
LOW docs/concepts/pdp/nexus-pdp-how-it-works.mdx:131 — the snapshot load isn't what stalls, and the floor is worded differently across pages
LOW docs/concepts/pdp/nexus-pdp-configuration.mdx:84 — the SURREAL_ROCKSDB_* variables barely affect the snapshot load either
LOW docs/concepts/pdp/overview.mdx:53 — the PDP overview doesn't say that Nexus PDP memory still grows with the data set
LOW docs/concepts/pdp/nexus-pdp-how-it-works.mdx:162 — disk sizing assumes a known snapshot size, and a killed cold start leaves its copies behind
LOW docs/concepts/pdp/nexus-pdp-deployment.mdx:31 — the startup probe times are from 8 CPUs only

Details are in the inline comments on each line.

- Size memory for a rebuild: 4x the snapshot + 1 GiB (about 7 / 12 GiB at 10M / 20M facts), labelled estimates, on all three pages. - 2.0M serving memory: up to 1.5 GiB (the measured build only). - The stall comes from applying changes, not the SST snapshot load; the 2304 MiB floor is worded the same everywhere; raise the limit to recover. - SURREAL_ROCKSDB_* barely affect the snapshot load either. - PDP overview: memory still grows with the data set. - Disk: snapshot size per million facts; a killed cold start leaves copies. - Startup probe: fewer CPUs take longer; startupProbe in the pod spec. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

Copilot

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

Copilot

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

…e from them Add a Nexus PDP Benchmarks page in the Cloud PDP Benchmarks format: server-side check latency at a fixed rate for RBAC and ReBAC depth 0-3, per-instance capacity at 2 and 4 vCPU and with about 20 million facts, scale-out to 3 instances, a short method section, the limits of the results, and step-by-step sizing guidance with a worked example. Replace the "no published throughput figures" caution with a link to the page, add a CPU row to the deployment requirements, add the measured serving memory to the resource footprint, and link the page from the Nexus PDP pages, the PDP overview, the Cloud PDP benchmarks and the sidebar. Update the route inventory baseline for the new route. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

Review follow-up on the Nexus PDP benchmarks page: - Capacity method: a separate open-model run for each scenario, starting at the latency-run rate, +25% every 2 minutes, up to 200 concurrent requests. State the latency bound's source per policy model. - Correctness: describe the pre-run and in-load checks; no run had a failed request or a wrong decision. - Access patterns: count the parent relationships for each depth, and say the Cloud PDP page is not a row-by-row comparison. - Data sets: define facts and give the full small data set. - Key results: scope the latency results to the measured rate, say the large data set shows total size only, name which patterns lost a step, state the CPU observation and the 1.56-1.95x figure, explain the per-connection balancing with the per-instance shares, and give the memory range with its read-cache caveat. - Sizing: mark the steps as guidance, add headroom before dividing, add a mixed-traffic formula and a depth 3 example. - Limits: x86 only (arm64 not measured), ABAC conditions not measured. - Sentence-case title, consistent P99 casing. Elsewhere: the CPU wording on How It Works and Deployment, the memory caveat on How It Works, "last verified on 0.7.0-beta.26" for the stall caution, the 2-CPU stop-answering condition tied to the memory floor, and the early-access callouts dated October 2026. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

The deployment requirements now list 2 vCPU to start, with the request equal to the limit, matching the benchmark setup. Add --cpus 2 to the docker run sample and cpu: "2" to the pod spec's requests and limits. Code-sample change in its own commit, per the style guide. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

EliMoshkovich · 2026-10-10T05:45:28Z

@zeevmoney @omer9564 this is a deep rewrite with the measured Nexus PDP check benchmark: a new page, /concepts/pdp/nexus-pdp-benchmarks. Re-requesting both of you, since the earlier approvals covered a version without performance numbers. @omer9564, the figures need your explicit OK before merge, per your rule on publishing Nexus numbers.

Copilot

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

…mory and disk - Remove the per-connection balancing explanation of the RBAC scale-out figures; the measured ratios only resolve to whole 25% steps. State the 2- and 3-instance figures against linear scaling within that resolution, and keep load spreading as general sizing practice. - Add the measured snapshot-load memory peak (about 5.3 to 6.7 GiB) and data volume use (about 7.4 GiB) with about 20 million facts, on the benchmarks page and in the resource footprint. - Say the added facts were of resource types the measured checks don't query, so the large data set shows the effect of a large environment. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

Copilot

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

zeevmoney

Approved — no CRITICAL or HIGH issues found.

Non-blocking:

MEDIUM docs/concepts/pdp/nexus-pdp-benchmarks.mdx:107 — "not 2 times" isn't established for ReBAC depth 2; "CPU was at its limit" is an estimate
MEDIUM docs/concepts/pdp/nexus-pdp-benchmarks.mdx:108 — scale-out bullet misstates the depth 2 arithmetic and understates the 2-instance RBAC gap
MEDIUM docs/concepts/pdp/nexus-pdp-benchmarks.mdx:106 — the capacity drop with 20 million facts reads as measurement noise
MEDIUM docs/concepts/pdp/nexus-pdp-benchmarks.mdx:48 — the large data set isn't the small data set plus 20 million facts
LOW docs/concepts/pdp/nexus-pdp-benchmarks.mdx:109 — small-data-set memory range doesn't match the measurements
LOW docs/concepts/pdp/nexus-pdp-benchmarks.mdx:120 — sizing assumes linear scale-out past 3 instances; step 3's headroom reason
LOW docs/concepts/pdp/nexus-pdp-deployment.mdx:57 — pod-spec intro asks for a startup probe the excerpt already has
LOW docs/concepts/pdp/nexus-pdp-configuration.mdx:101 — Next steps lists go past the style guide's five links

Still open from the previous review:

LOW docs/concepts/pdp/nexus-pdp-how-it-works.mdx:140 — disk is sized in multiples of a snapshot size readers can't see; the per-million-facts conversion left with the removed measurements

Process note: no explicit OK of the published latency and capacity figures from omer9564 is on record yet; his earlier approval predates the figures. The source results in pdp-benchmarks are also still in review.

Details are in the inline comments on each line.

- CPU: state the 4 vCPU gain per pattern in 25% steps (below 2x for RBAC and ReBAC depth 0, 1 and 3; consistent with 2x for depth 2), and say the instance was throttled at its CPU limit during capacity runs. - Scale-out: correct the linear-scaling arithmetic; RBAC with 2 instances is about one step below 2x, cause not established; measured up to 3 instances. - Large data set: describe the checks' own, smaller data and the 10 GiB memory limit as differences besides size; the capacity drop for RBAC and ReBAC depth 0 and 1 is real, one 20% step. - Small-data-set memory: about 0.15 to 0.2 GiB. - Sizing: headroom covers below-linear scale-out instead of the step resolution; load test beyond 3 instances. - Disk: give a measured volume data point for a first estimate. - Deployment: the excerpt's startup probe is a placeholder to set from a timed cold start. - Next steps lists capped at five links. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

EliMoshkovich · 2026-10-10T14:13:20Z

@zeevmoney thanks. All your comments are fixed in a8e09ac, with a reply on each thread.

The older still-open item (how-it-works: disk sized from a snapshot size readers can't see) is addressed with a measured data point instead of the removed per-million-facts conversion. The Disk section now says you don't see the snapshot size before the first cold start, and gives the benchmark figure as a first estimate: with about 20 million facts, the data volume used up to about 7.4 GiB. It adds that no rebuild ran in those measurements and a rebuild needs room for one more database copy, so give the volume more than that and monitor free space after the first cold start.

The build passes (0 bad links or anchors) and cspell is clean. Not merging: per Omer's rule, @omer9564's explicit OK on the published figures is still needed.

Copilot

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

…view) Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

Copilot

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

zeevmoney

Changes requested — 1 HIGH, 2 MEDIUM, 2 LOW.

Blocking:

HIGH docs/concepts/pdp/nexus-pdp-benchmarks.mdx:2 — conflicts with master, where #674 already published a Nexus PDP benchmarks page at this path

Resolve the conflict with master before this lands. Eli, Or and Omer need to agree on two things: one Nexus PDP benchmarks page, and one wording for the large-data-set disclaimer. #674 keeps the "resource types the checks never read" line that ddc0105 removed here.

Which page becomes the base hasn't been decided yet. Either way, keep what this PR adds:

the sizing section with its worked example;
the correctness method;
the limits: region and instance family, arm64, synthetic data, and serving checks only;
the corrections on the other pages:
- the 2.5 GiB memory floor;
- the cache sized from the memory limit;
- the scope of SURREAL_ROCKSDB_*;
- the CPU row and the CPU in the Docker and pod-spec samples;
- the pod-spec memory limit and startup probe;
- the disk sizing.

Non-blocking:

MEDIUM docs/concepts/pdp/nexus-pdp-benchmarks.mdx:48 — the large data set's model has no drives or files
MEDIUM docs/concepts/pdp/nexus-pdp-benchmarks.mdx:141 — the limits leave out three conditions that make capacity optimistic for a default deployment: logging, a warm working set, and one run per configuration
LOW docs/concepts/pdp/nexus-pdp-benchmarks.mdx:17 — the measured build is named only by a tag that can move
LOW docs/concepts/pdp/nexus-pdp-benchmarks.mdx:107 — the throttling clause reads as more than the runs show (in the reply on the earlier CPU thread)

Each thread from the previous review now has a reply saying it was verified at ddc0105. The details are in the inline comments.

zeevmoney · 2026-10-30T14:21:27Z

@@ -0,0 +1,152 @@
+---
+title: Nexus PDP benchmarks


[HIGH] This PR no longer merges: master already has a different page at this path (#674)

Problem:

docs: add Nexus PDP benchmarks page #674 (merged 2026-10-20) added its own nexus-pdp-benchmarks.mdx from the same benchmark run. It also edited the how-it-works info box, the deployment Memory row, the PDP overview's links, the Nexus PDP overview's Next steps and the sidebar.

Merging master into this branch gives an add/add conflict on this page, and content conflicts in nexus-pdp-deployment.mdx, nexus-pdp-how-it-works.mdx and overview.mdx.

Two files merge with no conflict marker but end up with duplicates: sidebars.js lists concepts/pdp/nexus-pdp-benchmarks twice, and the Next steps in nexus-pdp.mdx link to the benchmarks page twice.

Master's deployment Memory row links to /concepts/pdp/nexus-pdp-benchmarks#memory. This page has no memory anchor, so keeping that row next to this page fails the build's anchor check.

The two pages differ in content:

Only master's page states the image digest, the warm-working-set, logging and one-run-per-configuration caveats, and the 2-instance request splits.

Master's page still says the 20 million facts were on resource types the checks never read, which ddc0105 removed here.

Only this page has the sizing guidance, the correctness method, and the arm64 and synthetic-data limits.

Suggestion: Rebase on master and keep a single page that carries the content of both. Agree with #674's author on one wording for the 20 million facts. Drop the duplicate sidebar entry and the duplicate Next steps link. For the anchor, either add {#memory} to a memory heading or point the deployment row at #key-results.

zeevmoney · 2026-10-30T14:21:30Z

+| Data set | Contents |
+| --- | --- |
+| Small | 1,750 users, 12,610 resource instances, 12,000 relationship tuples, and 2,223 role assignments, in 11 tenants |
+| Large | About 20 million facts (users, resource instances, relationship tuples, and role assignments) in a file-sharing model of drives, folders, and files, plus the checks' own data: 1,100 users, 1,500 resource instances, 900 relationship tuples, and 1,573 role assignments |


[MEDIUM] The large data set's model has no drives or files

Problem: In the large-data-set runs, the 20 million facts come from a document-sharing data set with these resource types:

nested folders;

documents;

user groups, which hold shares.

It has no drives and no files. My earlier suggestion for this row used the same "drives, folders, and files" wording.

ddc0105 removed the "checks don't query" clause. Without it, "folders, and files" matches the access-pattern table's "a role on a folder that contains the file", so readers can take the row to mean the measured checks walked the 20-million-fact folder tree. The runs didn't measure that.

Suggestion: "About 20 million facts (users, resource instances, relationship tuples, and role assignments) in a document-sharing model of nested folders, documents, and user groups, plus the checks' own data: 1,100 users, 1,500 resource instances, 900 relationship tuples, and 1,573 role assignments"

zeevmoney · 2026-10-30T14:21:33Z

+- **One test environment.** All runs used one AWS region and one instance family: x86 (AMD EPYC, `m6a`) only. The `arm64` image was not measured. Other CPUs, storage, and Kubernetes setups can give different results.
+- **Synthetic data and policies.** The data sets and the RBAC and ReBAC policies were generated for the test. Your policy, the number of roles and relationships, and the shape of your permission graph change the results.
+- **The access patterns listed.** The runs measured single permission checks for the patterns in [Access patterns](#access-patterns), with one access path for each user. Users who reach a resource through many paths, ABAC conditions, and other endpoints such as bulk checks or user permissions were not measured.
+- **Serving checks only.** The runs measured checks against a running instance. They didn't measure checks while Nexus PDP applies a large burst of data changes, or the time to start a new instance.


[MEDIUM] The limits leave out three conditions that make the capacity figures optimistic for a default deployment

Problem:

Logging: the benchmarked instances ran at warn log level, exported only the request trace span, and sent no decision logs. The configuration reference gives the defaults as RUST_LOG=info and EDGE_DECISION_LOG_OPT_OUT=false, which means decision logs are on. A default deployment therefore spends CPU on each check that these runs didn't, and step 4 of the sizing guidance divides by capacity figures that don't include that cost.

Warm working set: checks were drawn at random from a fixed set of 1,000 checks for each data set. Every decision repeated many times, so any caching worked on a warm working set.

One run per configuration: each figure comes from a single run. That includes the 20-million-fact capacity drop, which Key results describes as lower.

The benchmark results list the first two as notes to publish with the figures. Master's version of this page (#674) includes all three.

Suggestion: Add three bullets to "What these results don't cover":

"Logging. Nexus PDP ran at warn log level and sent no decision logs. The defaults (RUST_LOG=info, decision logs on) use more CPU for each check, so load test with the logging you run in production."

"A repeated set of checks. Checks were drawn from a fixed set of 1,000 for each data set, so every decision repeated and caches stayed warm."

"One run per configuration. Each figure comes from a single run."

zeevmoney · 2026-10-30T14:21:36Z

+## Methodology
+
+- **Date:** October 2026.
+- **Build:** `permitio/nexus-pdp` `0.7.0-beta.50`.


[LOW] The measured build is named only by a tag that can move

Problem: The page names the measured build by its tag alone, 0.7.0-beta.50. The deployment page in this PR says a numbered beta tag can be published again for a later build, so the tag doesn't pin down which build was measured.

Suggestion: "Build: permitio/nexus-pdp 0.7.0-beta.50 (sha256:43b0f5c6d422558555e47ff4e84b99920d00ac832978f245e57b28d2d0d5eec6)."

zeevmoney · 2026-11-02T18:28:56Z

Direction for the benchmarks page conflict with #674 (Zeev's call): rebase this PR with #674's page as the base. #674's page is docs/concepts/pdp/nexus-pdp-benchmarks.mdx, already live on master. Then bring this PR's additions onto it:

the sizing section, the correctness method and the Limits section;
the corrections on the deployment, how-it-works and overview pages. Master's deployment row links to #memory, so keep that anchor working;
remove the line saying the facts are "on resource types the checks never read" from docs: add Nexus PDP benchmarks page #674's page. All resource types share the same tables, the same fix as in ddc0105. No need to re-check this with anyone;
sidebars.js and nexus-pdp.mdx: keep one entry each. The auto-merge produces duplicates.

The other findings from the last review still apply where the rebased page has the same text: the data-set model naming, the Limits points (warm working set, logging levels used in the runs vs the defaults), the image digest, and throttling per step. Re-request review after the rebase.

EliMoshkovich requested review from omer9564 and zeevmoney and a balanced review from Copilot October 5, 2026 21:51

Copilot started reviewing on behalf of EliMoshkovich October 5, 2026 21:51

View session

Copilot AI reviewed Oct 5, 2026

zeevmoney requested changes Oct 5, 2026

View reviewed changes

Merge branch 'master' into eli/per-16873-nexus-pdp-measured-sizing

17d55b6

Copilot AI balanced review requested due to automatic review settings October 6, 2026 17:56

Copilot started reviewing on behalf of EliMoshkovich October 6, 2026 17:56

View session

Copilot AI reviewed Oct 6, 2026

EliMoshkovich and others added 2 commits October 6, 2026 13:06

Merge remote-tracking branch 'origin/eli/per-16873-nexus-pdp-measured…

cfc34ba

…-sizing' into eli/per-16873-nexus-pdp-measured-sizing

Copilot AI balanced review requested due to automatic review settings October 6, 2026 18:08

Copilot started reviewing on behalf of EliMoshkovich October 6, 2026 18:09

View session

EliMoshkovich requested a review from zeevmoney October 6, 2026 18:09

Copilot AI reviewed Oct 6, 2026

Copilot AI balanced review requested due to automatic review settings October 6, 2026 18:27

Copilot started reviewing on behalf of EliMoshkovich October 6, 2026 18:28

View session

Copilot AI reviewed Oct 6, 2026

zeevmoney approved these changes Oct 6, 2026

View reviewed changes

Copilot AI balanced review requested due to automatic review settings October 6, 2026 18:42

Copilot started reviewing on behalf of EliMoshkovich October 6, 2026 18:43

View session

Copilot AI reviewed Oct 6, 2026

Copilot started reviewing on behalf of EliMoshkovich October 6, 2026 21:30

View session

Copilot AI reviewed Oct 6, 2026

EliMoshkovich and others added 3 commits October 10, 2026 00:35

Copilot AI balanced review requested due to automatic review settings October 10, 2026 05:45

EliMoshkovich changed the title ~~docs(nexus-pdp): correct the memory and disk sizing guidance (early access)~~ docs(nexus-pdp): publish measured check latency and capacity, and correct memory and disk sizing (early access) Oct 10, 2026

EliMoshkovich requested review from omer9564 and zeevmoney October 10, 2026 05:45

Copilot started reviewing on behalf of EliMoshkovich October 10, 2026 05:45

View session

Copilot AI reviewed Oct 10, 2026

Copilot AI balanced review requested due to automatic review settings October 10, 2026 05:58

Copilot started reviewing on behalf of EliMoshkovich October 10, 2026 05:59

View session

Copilot AI reviewed Oct 10, 2026

zeevmoney approved these changes Oct 10, 2026

View reviewed changes

Copilot AI balanced review requested due to automatic review settings October 10, 2026 14:12

Copilot started reviewing on behalf of EliMoshkovich October 10, 2026 14:13

View session

Copilot AI reviewed Oct 10, 2026

omer9564 approved these changes Oct 15, 2026

View reviewed changes

Comment thread docs/concepts/pdp/nexus-pdp-benchmarks.mdx Resolved

docs(nexus-pdp): drop the 'checks don't query' disclaimers (Omer's re…

ddc0105

…view) Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

Copilot AI balanced review requested due to automatic review settings October 15, 2026 14:00

Copilot started reviewing on behalf of EliMoshkovich October 15, 2026 14:01

View session

Copilot AI reviewed Oct 15, 2026

zeevmoney requested changes Oct 30, 2026

View reviewed changes

Zivxx mentioned this pull request Nov 8, 2026

PER-17948: docs(nexus-pdp): start Nexus PDP with a project or organization API key #681

Draft

Conversation

EliMoshkovich commented Oct 5, 2026 • edited by zeevmoney Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

netlify Bot commented Oct 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Deploy Preview for permitio-docs ready!

Uh oh!

linear-code Bot commented Oct 5, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Uh oh!

zeevmoney left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Uh oh!

EliMoshkovich commented Oct 6, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Uh oh!

zeevmoney left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Uh oh!

EliMoshkovich commented Oct 10, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Uh oh!

zeevmoney left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

EliMoshkovich commented Oct 10, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

EliMoshkovich commented Oct 5, 2026 •

edited by zeevmoney

Loading

netlify Bot commented Oct 5, 2026 •

edited

Loading