One binary. It runs where your data lives.
No agents to babysit, no cluster to stand up, no data to ship out. Deploy the engine next to your source, point it at a target, and let it move.
DataForge ships as a single self-contained binary / container image. You give it a source, a destination, and a policy; it runs one streaming pass, reconciles every unit to a terminal state (Δ0), and reports what happened. There is no orchestration layer to operate and no data-plane dependency on us — in its marketplace form, only a signed, content-free run meter ever leaves your environment.
Three ways to run it
Same engine, same guarantee. Pick the isolation posture that fits your environment.
Cloud Marketplace
One-click subscribe on Google Cloud Marketplace. An ephemeral, per-job container spins up in your project, runs the job inside your walls, meters, and self-destructs. AWS Marketplace listing in progress.
Zero-trust container
Pull the public engine image and run it in your own orchestration. It builds the job from configuration, moves your data source-to-target, and returns only telemetry. Nothing to trust us with.
Standalone / offline
For air-gapped, sovereign, and mega-corp deployments: an install-gated, license-keyed build that runs fully offline with no phone-home. Talk to us about Tier C.
Reads from many. Writes to many.
The same Parse → Filter → Accumulate → Write pipeline handles all of these without changing shape. Pick any source on the left; land it in any target on the right.
- Delimited / CSV & structured flat files
- Cloud & local object stores
- HTTP / HTTPS endpoints
- PostgreSQL & SQL Server — live cursors
- Whole objects — documents, images, archives, any blob (Crucible)
- PostgreSQL & SQL Server
- Cloud & local object stores
- Byte-lossless object destinations — checksummed, with a Δ0 manifest
Relational endpoints are interchangeable and cross-engine — a PostgreSQL source can write to a SQL Server target and vice-versa, no staging in between. Files and HTTP are read-only sources: DataForge draws from them and lands the data in a database or object store.
Configuration, not code
A job is declared, not programmed. Illustrative — the exact keys and the CLI live in the Quick Start guide bundled with the kit.
# A job names a source, a destination, and a policy. kind: objects # rows | objects | fetch source: /data/incoming # file path, object store, DB cursor, or URL set destination: postgres://…/warehouse policy: verify: true # independent destination verification on_delta: fail # Δ0 must close, or the job fails loudly # Result: every unit → inserted | malformed | dropped | skipped # scanned == written · net delta == 0
Don't trust our numbers. Reproduce them.
The same harness that produced every figure on the Performance page is the one any prospect downloads. No staging, no post-processing.
What's in the kit
- bench binary (Linux AMD64)
- bench-report HTML generator
- Setup and suite-run scripts
- Environment fingerprinting
- Stage-3 data validation (row count · schema · checksum)
- A real dataset — the CourtListener citation-map corpus (≈2.6 GB), with published SHA-256 checksums