PUCE Storage · Enterprise

PUCE Storage

Storage enterprise con deduplicazione, compressione e crittografia quantum-safe.

Try it — your file, post-quantum encrypted

Real upload with your account: encrypted in the browser (ML-KEM-768) BEFORE it leaves, presigned URL, never through our server.

No objects yet. Upload a file above.

Storage redesigned for the post-quantum era

Three pillars that set PUCE Storage apart from any legacy solution.

Deduplicazione Intelligente

Elimina i dati duplicati prima della compressione, riducendo i costi di storage fino al 60%.

Multi-Cloud

Si integra con AWS S3, Azure Blob, Google Cloud Storage e storage on-premises.

Compliance

Pronto per FIPS 140-3, HIPAA, GDPR, LGPD. Strumenti di autovalutazione inclusi.

Storage pipeline

5 stages executed on every write operation — fully transparent to the client.

01

Ingestion

Data arrives via SDK (Python/Node/Rust/Go) or REST API. Each object is split into 64 MB chunks for parallel transfer.

02

Deduplication & Compression

Inline deduplication via content hashing. High-ratio lossless compression for optimal CPU–space balance. Typical 60–75% reduction in stored volume.

03

PQ Encryption

Each chunk is encrypted with ML-KEM-768 + AES-256-GCM (FIPS 203). Ephemeral keys never persisted. Optional client-side encryption for zero-knowledge.

04

Automatic tiering

Hot → Warm → Cold based on access frequency. Transparent migration without URL changes. Configurable retention per bucket (7d – 10 years).

05

Multi-region replication

Synchronous or asynchronous replication across 3+ regions. Automatic failover. Compliance with data residency requirements (GDPR, NIS2).

Use cases

Four scenarios where PUCE Storage is the obvious choice.

Enterprise backup

Replace legacy backup solutions with PQ-encrypted storage. Deduplication cuts volume by 60-75%. Automatic retention and tiering eliminates manual management.

Regulated data

Healthcare (HIPAA), financial (PCI-DSS) and government (NIS2) data requires strong encryption and audit trail. PUCE Storage provides both by design.

Post-quantum data lake

Store petabytes of analytics data with PQ protection from ingestion. S3-compatible API integrates with Spark, Trino and existing tools.

Legal & forensic archive

Legal documents and forensic evidence need long-term verifiable integrity. SHA3-256 hash + Merkle tree provides tamper-proof evidence.

PUCE Storage vs traditional storage

Six critical differences the auditor will check.

FeaturePUCE StorageTraditional storage
Encryption
ML-KEM-768 + AES-256-GCM
AES-256 (vulnerable to Grover)
Quantum resistance
CNSA 2.0 (through 2030+)
None
Deduplication
Inline chunk-level
Post-process (if available)
Tiering
Automatic Hot/Warm/Cold
Manual or lifecycle rules
Integrity
SHA3-256 + Merkle tree
MD5/SHA-256 checksum
Multi-region
Sync/async with PQ-TLS
TLS 1.2/1.3 (no PQ)

Backup software integration scenarios

4 ways to integrate PUCE with any backup system — each with different trade-offs between deduplication, compression and post-quantum protection.

Scenario A — Compress-Only Pre-Backup

Recommended · Universal

App/DB (100 TB) → PUCE compress-only (30 TB) → Backup dedup+compress → ~15 TB

Typical ratio:6-7:1
Backup dedup works (data is not encrypted)
Compatible with any backup software
Reduces FETB licenses — pay 30 TB instead of 100 TB
No post-quantum protection (encryption is classic from backup)

Scenario B — Full Pipeline Pre-Backup

Dedup caveat

App/DB (100 TB) → PUCE compress+encrypt+sign (~22 TB) → Backup (dedup ~0%) → ~22 TB

Typical ratio:4-5:1
Full PQ end-to-end protection
Compatible with any backup software
Backup dedup does not work (encrypted data looks random)
Only recommended when dedup is not needed

Scenario C — Integrated in Backup Engine

Deep integration

App/DB (100 TB) → Backup [Dedup → PUCE Engine (replaces compression) → PQ Encrypt] → ~10 TB

Typical ratio:8-10:1
Dedup works 100% (PUCE acts after)
ML-select compression superior to native
PQ encryption on storage
Requires deep integration (SBT_TAPE for Oracle, VDI for SQL Server, etc.)
Support varies by backup system

Scenario D — Post-Dedup, Pre-Storage

Ideal · Best overall

App/DB (100 TB) → Backup [Dedup → 40 TB] → PUCE Storage [ML-Select Compress → PQ Encrypt+Sign] → ~8 TB

Typical ratio:10-15:1
Dedup works 100%
ML-select compression on already deduped data
Full PQ encryption on storage
Digital signature on each block
Compatible with all systems
Does not reduce FETB license (backup sees original volume)
Requires access to post-dedup point
ScenarioDedup works?PQ Encrypt?IntegrationRatio (100 TB)Best for
A · Compress-Only✓ Sim✗ NãoNone6-7:1Reduce FETB licenses
B · Full Pipeline✗ ~0%✓ SimNone4-5:1PQ end-to-end, no dedup
C · Motor Integrado✓ Sim✓ SimDeep (API)8-10:1Oracle RMAN, SQL Server
D · Pós-Dedup✓ Sim✓ SimStorage tier10-15:1Best possible ratio

General Comparison — All Platforms

Integration method, recommended scenario and ratios for each backup system.

PlatformPUCE integration methodRecommended scenarioCompression ratio
(without PUCE → with PUCE)
Dedup works?PQ Encrypt?Complexity
Oracle RMANSBT_TAPE library (libpuce_sbt.so)C (Integrated Engine)2.1:1 → 9.3:1✓ Excellent (block-aligned)Medium
CommvaultCVPySDK + Cloud Library S3A+D (Compress + Archive)2.5:1 → 10-15:1✓ MSDP + PUCELow-Medium
Veritas NetBackupHook scripts (bpstart/bpend_notify) + OSTD (Post-Dedup)2.5:1 → 10-15:1✓ MSDP + PUCELow-Medium
Dell NetWorkerCloud Boost S3 / AFTD / Pre-save scriptsD (Data Domain + PUCE archive)2.0:1 → 10-14:1✓ DD + PUCEMedium
Veeam B&RS3 Object Storage Repository (native)A+D (best cost-benefit)1.5:1 → 10-15:1✓ MSDP + PUCELow (plug & play)
SQL ServerVDI / BACKUP TO URL (S3) / .bak → PUCEC (VDI) or A (BACKUP TO URL)1.8:1 → 7-10:1✓ (8K pages repeat)Medium
PostgreSQLpgBackRest S3 / pg_basebackup pipe / WAL archiveC (pgBackRest S3)2.3:1 → 6-9:1✓ (WAL dedup excellent)Low