I don't have documentation of a specific PDP environment variable dedicated to storing data in an external database instead of OPA's in-memory store. What I do have is guidance on handling very large data volumes within OPA/OPAL. For hundreds of millions of records loaded directly into OPA, this is flagged as a real concern: OPA is known to bloat loaded data in memory since it loads it into objects, and high volume with an inefficient structure will lead to bad performance (1) . In a documented case with ~1.3 million records (~150MB) , the OPAL-client container memory inflated to over 2GB and OPA crashed . At the scale you're describing (hundreds of millions of records) , this would be substantially worse. The recommended approaches instead of pure environment-variable configuration are: 1. ​*Confirm the bottleneck is OPA, not OPAL*​ — check which process consumes the memory, try loading data manually into OPA regardless of OPAL, or run the OPA agent standalone . 2. ​*Reduce the data actually loaded*​ — most authorization needs only a small subset of data (often just IDs and relationships) , so minimizing the data set (via a custom data fetcher or an API transformation layer) can save significant space . 3. ​*Increase container/machine resource limits*​ (memory/CPU) . 4. ​*Shard the data across multiple OPA agents*​ if you truly need all of it . Sharding using Permit environments and/or OPAL topics is explicitly supported for splitting data between multiple PDPs in the same cluster, and you can additionally use OPA's

http.send

as part of policy in one PDP to fetch missing data from another PDP (chaining) (2) . Regarding OPAL's data-loading mechanism itself:

OPAL_DATA_CONFIG_SOURCES

defines the instructions clients use to reach baseline data state, and OPAL doesn't send the data itself over pub/sub — it sends instructions to clients on how to fetch data directly via data-fetchers (1) :

- OPAL_DATA_CONFIG_SOURCES={
  "config":{
    "entries":[
      {
        "url":"<http://host.docker.internal:8000/permissions.json>",
        "topics":["permissions"],
        "dst_path":"/course_permissions"
      }
    ]
  }
}

I don't have documented evidence of an environment variable that offloads the store itself to a database rather than OPA's memory. If you're seeing memory/crash issues with your own PDP, could you share: 1. Which Workspace / Project / Env you're using 2. What calls you're performing (SDK code or CURL) 3. Which PDP version you're running 4. Relevant logs from your PDP This would help pin down whether sharding or data minimization is the right path for your setup.

To learn more, see the sources I considered: [[1] Data updates](https://docs.opal.ac/faq/) [[2] at Scale](https://docs.permit.io/how-to/deploy/overview)

Not exactly — sharding is one option for scale, but it's not the only recommended approach and isn't strictly "small chunk stored in OPA's RAM." For truly massive datasets, sharding using Permit environments and/or OPAL topics is explicitly supported to split data between multiple PDPs within the same cluster, with requests rerouted to the relevant PDP in a service-mesh style (1) . In addition, chaining can be applied, using OPA's

http.send

as part of the policy in one PDP to fetch missing data from another . But there's also an approach that avoids loading large volumes into OPA's memory at all: source-level filtering via partial evaluation. Here, the PDP returns a query basis (e.g., SQL) that's appended to an existing query and sent to the database, which returns only the relevant, pre-filtered data — meaning the DB query itself is modified before execution, rather than pulling all data into the PDP/OPA (2) . This capability is available under OPA's

compile

API and is already supported within Permit's PDP . Also relevant to your scenario — you can group related items by shared attributes (time frames, departments, categories) and pass a single group identifier to a PDP or database filter, rather than handling massive lists of unique IDs. For very large volumes, filtering at the source via partial evaluation prevents a flood of irrelevant rows from ever leaving the database (3) . So the choice depends on your use case: if you need OPA to actually hold and evaluate against the full dataset, sharding across multiple PDPs is the documented path (1) . If you can restructure your policy to filter at the database layer instead, partial evaluation avoids the RAM/scale problem entirely (2) (3) . If you're still hitting memory issues with your current PDP setup, it would help to know: 1. Which Workspace / Project / Env you're using 2. What calls you're performing (SDK code or CURL) 3. Which PDP version you're running 4. Relevant logs from your PDP

To learn more, see the sources I considered: [[1] at Scale](https://docs.permit.io/how-to/deploy/overview) [[2] Data Filtering](https://docs.permit.io/how-to/enforce-permissions/data-filtering) [[3] Implementing Database Permissions](https://www.permit.io/blog/why-data-filtering-matters-for-database-authorization)