---
title: "About Results Storage Mode"
url: "https://dm0bkdes5q7a2ls.productfruits.help/en/article/about-results-storage-mode"
language: "en"
last_updated: "2026-05-21T15:20:46.287Z"
---

# About Results Storage Mode

In Spirion Sensitive Data Platform (SDP) v13.6.1, Results Storage Mode is a critical architectural setting that determines where the agent "stages" findings during an active scan.

This setting was specifically enhanced to support the **PostgreSQL-based queueing model** used by Windows Agents to ensure data integrity and scalability.

## **1\. Memory Mode (Default)**

In this mode, the Agent stores all matches in the endpoint's RAM (Random Access Memory) while the scan is running.

-   **How it works:** As the Agent identifies sensitive data, it builds a results object in memory. Once the scan (or a specific chunk of work) is complete, the Agent hands these results to the **Shipper** process to be sent to the console.
-   **Best for:** Standard workstations, laptops, and scans with a low-to-moderate volume of findings.
-   **Risk:** If the machine loses power or the Spirion service crashes before the results are shipped, the findings from that active scan are lost and the scan must be re-run.

## **2\. On-disk Database Mode**

In this mode, the Agent writes matches directly to a local temporary database on the endpoint's hard drive as they are found.

-   **How it works:** The Agent utilizes the local **PostgreSQL** instance installed with the v13.6+ agent. Every time a match is found, it is committed to a local disk-based table.
-   **Best for:**
-   -   **Discovery Agents:** Agents scanning massive repositories (TB+) where millions of matches might be found.
    -   **Unstable Networks:** Environments where the connection to the SaaS console is intermittent.
    -   **Low-RAM Systems:** Prevents the Spirion process from consuming too much system memory during high-volume scans.
-   **Benefit:** This provides **persistence**. If the system crashes mid-scan, the results already written to the disk are preserved. When the service restarts, the **Shipper** process can pick up those results from the local database and send them to the console.

* * *

## **Comparison Table**

| Feature | Memory Mode | On-disk Database Mode |
| --- | --- | --- |
| **Primary Storage** | System RAM | Local PostgreSQL (Disk) |
| **Performance** | Faster (No disk I/O) | Slightly slower (Disk overhead) |
| **Resilience** | Low (Lost on crash) | High (Persisted on crash) |
| **Resource Usage** | Higher RAM consumption | Higher Disk I/O & Space |
| **Recommended Use** | Standard Endpoints | File Servers / Discovery Nodes |

## **Technical Insight: The "Shipper" Interaction**

Regardless of the mode selected, once the results are ready to be sent to the console, they enter the **shipper\_queue** (a table in the local Postgres database).

-   In **Memory Mode**, the results are moved from RAM to the `shipper_queue` at the end of a task.
-   In **On-disk Mode**, the results are effectively already staged on the disk, making the transition to the shipping phase more seamless for extremely large datasets.

## **Recommendations**

For any Agent acting as a "Discovery" node or scanning a target with more than 1 million files, always switch to **On-disk Database Mode** to prevent memory exhaustion and ensure no data is lost during long-running jobs.