top of page

Cut Perforce storage costs by 60–80%.

Without changing a single developer workflow.

p4-cache transparently tiers cold Perforce depot data to object storage while keeping hot data on fast NVMe — no p4d patches, no client changes.

The storage curve every Perforce shop hits.

  • As depots grow, 5–15% of data is read in any 30-day window.
  • 85–95% sits idle on premium storage tiers.
  • Expensive SAN and cloud SSD costs scale linearly with growth.

How p4-cache works.

On startup

The daemon initializes its metadata map, identifying cold objects for tiered migration.

At read time

The shim intercepts Perforce requests, serving hot data from local NVMe or pulling cold data from object storage instantly.

At write time

New submits arrive at local line-speed storage before being asynchronously moved to the tiered cloud layer.

Architecture overview

The p4-cache architecture is built as a high-performance system centered around the p4-cache daemon, written in Rust for memory safety and zero-cost abstractions. It leverages a lightweight LD_PRELOAD library (libp4shim.so) to intercept p4d file operations transparently at the POSIX level, requiring no changes to the Perforce binary itself.

The system maintains a persistent manifest that maps depot files across multiple tiers. Hot data is kept on local high-speed NVMe storage for immediate access, while cold data is tiered to cost-effective backends including Azure Blob, Amazon S3, Google Cloud Storage (GCS), or standard NFS exports. This design creates a unified, infinitely scalable storage pool for your most demanding workloads.

Request flows

Cold reads

When p4d attempts to open a file marked as cold, the shim intercepts the open() call and signals the daemon. p4-cache fetches the requested object from cloud storage into the local NVMe cache at wire speed before completing the file descriptor open for p4d.

Writes

New depot files are written directly to the local NVMe tier, ensuring maximum submit performance and zero latency for active development. Once the write is finalized, p4-cache asynchronously pushes the data to the configured cold backend based on your migration policies.

What this does to your storage bill.

Cloud Studio (80 TB): Cut $100k annually with ROI within one year.

Enterprise (1 PB): $3M+ yearly savings; no future storage refresh.

By shifting petabytes of legacy data to S3-compatible storage, you reclaim premium disk space and stop the endless cycle of expensive hardware upgrades.

Production-grade, with citations.

Security & audits

  • Three independent code audits completed with all findings fully closed.
  • Real-time restore verification using BLAKE3 cryptographic content hashing on every restore.
  • Strict UID allowlists enforced at the kernel boundary to prevent unauthorized access.
  • Mandatory TLS across all connections with full customer CA support for end-to-end encryption.
  • Zero telemetry architecture—no 'phone-home' functionality or data collection.

Failure modes & recovery

p4-cache is designed for absolute reliability. If the daemon process stops, p4d continues to run; only requests for cold-tier files will hold until the daemon restarts. In the event of cold storage unavailability, the system enters a read-only safety mode for tiered assets, ensuring no data loss occurs while connectivity is being restored.

The system robustly handles kernel-level events; if fanotify overflows, the shim detects the state change and p4d remains operational. Because local NVMe acts as a write-back cache, all data is primary and recoverable even in extreme failure scenarios. Your Perforce environment remains stable and your data safe.

Operations & observability

  • Comprehensive Prometheus metrics endpoint for real-time monitoring of hit rates and latency.
  • High-fidelity structured JSON logs for automated parsing and alerting.
  • Continuous access logs exportable to Elasticsearch or Postgres for deep audit forensics.

Who this is for

  • Cloud studios managing 5–50 TB Perforce depots seeking massive cost reduction.
  • Enterprises with 200 TB to 2+ PB on legacy SAN (NetApp/Pure/Isilon) facing expensive refreshes.
  • Security and architecture teams requiring deep technical briefs and verifiable audit trails.

Next steps.

Most teams start with a 60-day evaluation against a representative slice of their depot.

Resources for reviewers

Share these with storage architects, security teams, and Perforce admins during evaluation.

bottom of page