★ LANGUAGE primary ★ DEVICE I/O cross-listed
SlimeTree-VSAM
Modernize the VSAM workload, as VSAM.
A single Rust binary that provides native VSAM (KSDS / ESDS / RRDS) compatible storage. PostgreSQL is structurally 480× slower on VSAM workloads (SQL planner + 2-hop B+tree + MVCC overhead): same-host bench shows 480× on sequential cursor, 267× on random key, a 1-billion-record nightly batch shrinks from PostgreSQL's 19.5 hours to SlimeTree-VSAM's 4.4 minutes (= same order as IBM z/OS VSAM). SHA-256 audit chain inside makes tamper detection work even in air-gap environments.
Bench-validated Mainframe-DB native
What it does
SlimeTree-VSAM provides a native, Rust-single-binary implementation of mainframe-era VSAM (Virtual Storage Access Method) — KSDS (key-sequenced), ESDS (entry-sequenced), and RRDS (relative-record). When you migrate COBOL legacy code to Java or Rust, swapping the DB for plain PostgreSQL often makes the nightly batch window collapse. That is the real ongoing problem in financial core systems — and this is the targeted answer.
Key specs
| Access methods | VSAM KSDS / ESDS / RRDS (key-sequenced / entry-sequenced / relative-record) |
|---|---|
| Implementation | Single Rust binary, deterministic |
| Sequential speed | 480× per-access vs PostgreSQL 16 (sequential cursor, same-host bench) |
| Random-key speed | 267× vs PostgreSQL 16 (random key access) |
| Nightly batch example | 1 billion records: PostgreSQL 19.5 hours → SlimeTree-VSAM 4.4 minutes |
| Audit | SHA-256 audit chain built in; tamper detection works in air-gap environments |
| Integration | Drop-in DB target for SlimeCOBOL Phase D emit (the receiving DB for migrated COBOL) |
| Family | Slime storage family / LANGUAGE primary, DEVICE cross-listed |
How it positions against mainframe storage (reference values)
The 480× vs PostgreSQL quantifies how badly PostgreSQL fits VSAM workloads. Placing SlimeTree-VSAM's absolute performance next to IBM z/OS VSAM (from public sources + commodity NVMe specs) gives the following orders of magnitude:
| Metric | IBM z/OS VSAM (public range) | SlimeTree-VSAM (commodity NVMe + Rust) | PostgreSQL (reference) |
|---|---|---|---|
| Random read latency | 17-22 μs (DS8900F + zHyperLink, best) 100-200 μs (zHPF cache hit) ~ms (cache miss + DASD) |
5-30 μs (in-process Rust + NVMe cache) 50-100 μs (NVMe direct) |
0.1-2 ms (= 100-2,000 μs; planner + 2-hop index + MVCC) |
| Sequential bandwidth | ~1 GB/s (single DASD) 20 GB/s (current TS7700 aggregate) |
2-7 GB/s/drive (PCIe-4/5 NVMe; scales with RAID) | (severely degraded by planner / tuple decode) |
| 1B-record batch (measured) | workload-dependent (typical: minutes to tens of minutes) | 4.4 min (same-host bench, ≈ IBM same order) | 19.5 hours (= nightly window collapse) |
The takeaway: SlimeTree-VSAM delivers the same order of random / sequential performance as IBM z/OS VSAM, on a commodity x86 + Rust single binary. There are cases where IBM zHyperLink's best 17 μs wins; raw hardware-side differences are workload-absorbed in practice. We do not claim "N× faster than IBM". The differentiation is not raw speed but (1) license at 1/X (2) bit-exact compatibility (3) SHA-256 audit chain standard (4) commodity HW operation.
Public sources: Planet Mainframe (zHyperLink), TechTarget DS8900F, IBM TS7700, USENIX ATC '19 NVMe I/O Stack.
Combined effect with PSDP — further parallelism, same source
Stack PSDP (same-language parallelization, no source rewrites) on top of SlimeTree-VSAM and DB / large-batch workloads gain an additional 4-8× scaling. Combined with SlimeTree-VSAM's standalone 480×, the result reaches 1,900-3,800× vs PostgreSQL — the only viable solution (projected) for the largest financial cores whose nightly batch window has already collapsed.
| Workload | PSDP scaling (bit-exact) | Conditions |
|---|---|---|
| OLAP (TPC-H Q1 / Q6 column store, 12 M rows) | 4.38-5.20× | Ryzen 9 7945, 1c → 8c, 25/25 runs bit-exact vs reference |
| CDC (commutativity-aware WAL replay, 20 M ops) | 4.26× | vs serial baseline, 25/25 runs final-state hash identical |
| Multi-connection parallel read (SQLite WAL reader) | 9.76× | 14.2 → 138.6 qps, 1c → 12c |
| Large-batch DB walk (projection) | 6-8× scaling | sequential cursor against in-memory backends like SlimeTree-VSAM (memory-BW bound) |
The combined 1,900-3,800× figure is derived from SlimeTree-VSAM's impl_v6 micro / scale bench (Zen 4 / WSL2 same-host) plus PSDP's measured data. PSDP is not effective when the workload is purely I/O-bound (CPU idle while waiting on synchronous I/O) — see PSDP limited cases. SlimeTree-VSAM's sequential cursor is memory-BW bound, which falls within PSDP's applicable range.
Where it applies — "the nightly batch doesn't finish" is the real problem
The financial-core nightly-batch collapse
Even when COBOL is bit-exact migrated to Java or Rust, swapping the DB for plain PostgreSQL collapses the nightly window in many financial cores. A typical 1-billion-record sequential-cursor batch takes 19.5 hours on PostgreSQL versus 4.4 minutes on SlimeTree-VSAM (same-host bench). This is the structural reason "VSAM refugees" cannot move — and this product is their option.
The SlimeCOBOL drop-in DB target
Designed so that the DB target emitted by SlimeCOBOL's Phase D (QSAM/VSAM emit) drops straight in: RECFM bit-exact, KSDS / ESDS / RRDS chosen automatically by the emitter. After the BLACKBOX bit-exact transcription, the "destination" is now aligned on both performance and audit.
Air-gap audit requirements
Banking / insurance / public-sector cores demand bit-exact audit: a SHA-256 audit chain is built into the storage layer itself. Tamper detection works after the fact even in environments that never touch a network.
Validated results
- 480× faster than PostgreSQL 16 on sequential cursor (same-host bench, per-access)
- 267× faster on random key access (same conditions)
- 1-billion-record nightly batch: PostgreSQL 19.5 hours → 4.4 minutes
- SHA-256 audit chain built in — air-gap tamper detection
- Connected as drop-in DB target for SlimeCOBOL Phase D emit (QSAM/VSAM auto-routing validated)
Customer segments (operator perspective)
- Regional banks & major life insurers, IT directors: COBOL-retirement projects stuck on the DB
- Municipal / public-sector cores: VSAM-dependent workloads, modernization of 20–30-year unattended operations
- Major SIers: Phase D's DB destination — complete the migration project on both performance and audit
- Central government / defence procurement: domestic supply + math-backed guarantees + audit chain together satisfy sole-source conditions
Related
- Deep-dive blog: 480× PostgreSQL — SlimeTree-VSAM as the option that rescues VSAM holdouts (Japanese)
- Same family, semantic-driven variant: SlimeTree-RLM
- Companion products: SlimeCOBOL (the Phase D DB drop-in pair), SlimeNENC family
- Category: LANGUAGE products, DEVICE (cross-listed)
Get it / contact
For reproducing the same-host bench numbers on your environment, PoC engagements, and SIer / reseller partner enrolment: