Every analyst. Every engineer. One canvas.

The strongest visual ETL engine. Build pipelines in your browser, move them through staging to production, and run them on your own servers. One flat price.

orders · nightly refresh Draft Unsaved v7 Staging v7 · Production v7 Succeeded
Postgres
Input
482,910 rows
CSV Files
Input
12,480 rows
Filter
Preparation
311,204 rows
Data Cleanse
Preparation
12,480 rows
Join
Join
309,877 rows
S3 File
Output
309,877 rows
Data Out Messages Metadata Join · no run neededJoin · 50-row sampleProduction v7
order_idInt64
placed_atTimestamp
customerUtf8
amountDecimal128
regionUtf8
is_priorityBoolean
order_idcustomerregionamount
1043Redwood LabsWest1,284.00
1044Bellhaven CoNorth312.50
1045Orchard GroupWest9,940.10
1046Kestrel FreightSouth2,410.00
  • Started on Production v7
  • Postgres read 482,910 rows
  • Filter kept 311,204 of 482,910 rows
  • Join matched 309,877 rows
  • S3 File wrote 309,877 rows. Succeeded.
Who it's for

Analysts build it. Engineers ship it. IT signs it off.

Everyone works on the same pipeline in the same browser, so the person who asked for a change can open it, test it and see exactly what it does.

Analysts & business teams

Build it yourself, without a ticket or a licence to wait for.

  • A 50-row preview of every step, one click of Test away
  • Formulas in plain SQL, with [bracket] column names if you prefer them
  • Excel in, and formatted Excel reports and per-person emails out
The Monday report, off the desktop

Data engineers

Production pipelines without the glue code.

  • S3, Parquet, Iceberg and seven warehouses and query engines
  • Schedules, file-arrival triggers and Flows that branch on failure
  • Staging and production versions, with per-node telemetry on every run
Data-lake pipelines, without the glue
Built for production

The discipline engineers expect, on a canvas analysts can read.

Everything a pipeline needs once people depend on it: versions, schedules, orchestration, alerts and a record of every run.

One pipeline is a graph of rows. A Flow is a graph of pipelines.

Run pipelines in sequence or side by side, branch on the outcome, and alert someone only when something fails.

Load orders Load refunds Reconcile Publish marts Notify #data-ops on failure

Rolling back is an edit, not an incident.

Every publish is a numbered version nobody can change, and every run is stamped with the one it ran.

  • v7StagingProduction
  • v6Restore
  • v5Restore

Four ways a run starts.

Each one lands in the same queue, the same history and the same telemetry.

  • On a schedule
  • When a file lands
  • Once per variant
  • As a step in a Flow

Every run answers what happened.

Rows and time for every node, and peak memory and queue wait for every run.

  • Postgres482,910
  • Join309,877
  • S3 File309,877

One expression language, and it is SQL.

Filters, formulas and validation rules all share it, and [bracket] column names still work.

CASE WHEN [score] >= 90 THEN 'A'
     WHEN [score] >= 80 THEN 'B'
     ELSE 'C' END
The engine

100% Rust. No JVM. No garbage collector.

500,000,000rows, one server
80 node pipeline 8 vCPU, 32 GB of memory 33m 55s end to end

One measured run: half a billion rows read from a Parquet file on S3, sent through 75 steps of filters, formulas and column changes, then totalled and checked. Not one row was lost or duplicated, and more than 120 GB spilled to disk rather than running out of memory.

Many established visual ETL tools run on the Java virtual machine, which is why keeping one alive under load means heap flags, per-component memory settings and a lot of time reading stack traces. That is the standing cost of a garbage-collected data engine.

Trinium's engine is Rust from end to end, with no virtual machine to size and no collector to pause a run in the middle of the night. Every node runs at once, rows stream between them in batches, and the work that cannot stream spills to disk inside one memory budget instead of taking the process down.

That is why one ordinary server does work that usually needs a cluster, and why the price can be flat.

Read how execution works
Pricing

Priced per server. Never per person.

Pro counts one thing, the servers you run, and Enterprise counts nothing at all. Everyone in the company can have an account on either, and a bigger machine never costs more.

Noseat licencesEveryone in the company can have an account.
Noper-core licencesA 64-core box is still one server.
Nometered runsRun a pipeline every minute if you want to.
Nometered rowsVolume is a capacity question, not a billing one.
Nodes & connectors

Every tool the job needs, already on the canvas.

On the way in: files, databases, warehouses, lakehouse tables and SaaS APIs. In the middle: cleansing, joins, parsing, reshaping, fuzzy matching, validation and reconciliation. On the way out: the same systems again, plus formatted Excel reports and email.

There are no add-on packs and no marketplace, and everything listed ships in the product.

Connects to

PostgreSQL
MySQL
SQL Server
MongoDB
Snowflake
BigQuery
Amazon Redshift
Databricks
ClickHouse
Trino / Starburst
Amazon Athena
Apache Iceberg
Amazon S3
Azure Blob Storage
Google Cloud Storage
SFTP
REST API
Google Sheets
Salesforce
HubSpot
Jira
Zendesk
SMTP (Email)
Self-hosted, properly

Your data never reaches us. Neither does your telemetry.

Read the security overview
  • Runs in your network. Trinium is a set of containers on your servers, beside a Postgres database you own, and nothing leaves except what your pipelines send.
  • Licences verify offline. Your key is checked against a public key built into the binary, so there is no licence server and no usage reporting.
  • Credentials stay encrypted. Secrets are encrypted at rest, and a pipeline holds only the name of a connection, never its password.
  • Nobody gets locked out. If a licence lapses, new runs stop and everything else keeps working. Nothing is deleted.

Bring your hardest pipeline.

Rebuild one real pipeline of yours during the trial. It takes an afternoon, and it settles the question better than anything on this page.