Who it is for
Teams with real data movement constraints
Organizations that need local, customer-controlled movement between files, object storage, transforms, manifests, and deployment environments where cloud ETL is not the right boundary.
ENGAGEMENT-LED · SOVEREIGN ETL
Z-ETL is scoped data movement infrastructure.
Z-ETL is a data pipeline engine written in Zig for local and customer-controlled deployments. It is for buyers who already know they have a data movement problem — source systems, file formats, throughput, failure behavior, audit needs, and deployment boundaries matter enough that the useful answer must be scoped before delivery.
What it does
Streams, transforms, and verifies
Moves data through ingest, transform, and output stages using scoped build options such as DuckDB, local inference, Lua, audit manifests, and checkpoint/resume behavior.
What it does not do
Not self-serve SaaS or a public binary
Z-ETL is not a hosted ETL subscription, anonymous download, generic connector marketplace, or guarantee that every source system is supported without integration scope.
Z-ETL PIPELINE · CANONICAL FLOW
INGEST CSV · Parquet · JSONL · S3
TRANSFORM DuckDB · llama.cpp · Lua
OUTPUT BLAKE3 manifest · atomic write
LOCAL TARGET SCOPED BUILD AUDIT MANIFEST
What to include in your Z-ETL request
Data shape
Formats, row counts, file sizes, compression, malformed-row tolerance, schema drift, and audit requirements.
Systems boundary
Source systems, target systems, network access, credentials model, object-store provider, and air-gap constraints.
Runtime target
Operating system, CPU architecture, accelerator availability, filesystem behavior, and deployment restrictions.
Success criteria
Throughput target, memory ceiling, failure behavior, support window, documentation requirements, and delivery owner.
Parsing · SIMD-oriented CSV path
Scoped builds can target AVX2/AVX-512 instruction width on x86_64 and ARM64 paths where the environment supports them.
Memory · streaming posture
Ring-buffered processing keeps the pipeline oriented around bounded memory instead of loading the whole file into process memory.
Binary · static deployment target
Deployment is designed around a small hermetic binary surface rather than a Python, JVM, npm, or Docker runtime stack.
Compliance · Blake3 audit manifests
Transformation records, malformed-row quarantine, and manifest verification can be included in the scoped delivery.
Sources · filesystem, compressed files, object storage
Source and target support is confirmed during scope, including authentication, multipart behavior, and error handling.
Resilience · checkpoint and resume
Checkpoint behavior and recovery requirements are part of the engagement design, especially for large or remote sources.
What happens after contact
- Fit check: confirm whether Z-ETL matches the data movement problem or whether another path is better.
- Written scope: define sources, outputs, build flags, success criteria, support terms, and delivery format.
- Delivery: provide the licensed build, integration notes, deployment instructions, and support channel agreed in scope.