Data integration and transformation

Extract, validate and transform. One environment for your whole pipeline

Extract, transform and load (ETL) on the same canvas — with real-time change capture straight from the database log. You write the SQL; the incremental logic is on Januss.

14 days free No credit card Workspace live in minutes
customers_360 live
pg customers extract · cdc
My orders extract · incr
fx customer_360 transform · sql
BQ bigquery load · upsert
3.2M rows / run
98.7% success rate
2m 41s avg duration
CDC on every plan

Real-time change capture comes from the entry plan on — it is not an enterprise add-on.

You pay for what lands

You are billed per row written to the destination — not for what the pipeline had to read to get there.

A ceiling on every plan

Every plan has a maximum your bill will never exceed. Not a marketing promise — it is the contract.

Simulate your volume and see the plan, the overage and the ceiling before you sign.

Calculate my plan
Sources & destinations

Connects where your data already lives — and delivers where it will be used.

The sync mode is chosen per table or view. The same source can have tables on full load, incremental and change capture at the same time.

Sources

Databases, spreadsheets and files — plus any REST API you point us at

pgPostgreSQLCDC MyMySQLCDC MSSQL ServerCDC OrOracleCDC MMongoDBCDC GSGoogle Sheets {}Any REST API /…File directory

Destinations

Databases and warehouses — they take the load, transform and serve views

pgPostgreSQL MyMySQL MaMariaDB MSSQL Server OrOracle BQBigQuery SfSnowflake

Object storage — Parquet, CSV or JSONL, to read straight from the path

S3Amazon S3 AzAzure Blob Storage GCGoogle Cloud Storage

Lakehouse — parquet in your bucket, with transformation and upsert

DLDuckLake

Each destination gets DDL written in its own native dialect.

The problem

Integrating data shouldn't consume your team.

Whoever looks after the data ends up stuck in the same loop: a script someone wrote, a schedule nobody reviews and an expensive tool in the middle. The outcome is always the same — late data, numbers that don't add up, and expensive people firefighting.

Scripts that break silently

Every integration turns into a schedule plus a script nobody wants to maintain. When it breaks, you find out from the wrong report — not from an alert.

Expensive people maintaining plumbing

Hours that should become product become pipeline maintenance. It's the cost that shows up on no invoice — and it's the biggest one.

Database passwords in plain text

A production credential stored in the clear inside the integration tool is an incident waiting for a date.

Data that can't leave

Compliance keeps your database from touching the cloud — and most SaaS tools require exactly that to work.

Januss brings the pieces into one visual flow: from source to destination, with SQL transformation running inside your own database, credentials the platform never sees, and a Runner for when the data can't leave your network.

Everything in one flow

The whole pipeline, under control.

From source to destination — model, schedule and watch every step without leaving the canvas.

Pipelines you draw

Build the extract, transform and load flow by dragging steps. The graph is validated before it runs and executes level by level, in parallel where it can.

CDC — the database tells you what changed

Without it, finding what changed means re-reading the entire table on every run. Januss reads the database's own transaction log — with no extra piece of infrastructure to maintain. If the log rotates before it's read, the reload is automatic.

SQL transformation, in your destination

Transform steps run as SQL inside the destination database itself. No cluster to spin up, no moving the data twice — and only the affected scope is reprocessed.

Every table at its own pace

Full load, incremental, mirroring and versioned history — chosen per table or view. The same source can run all four at once.

Bad data doesn't get through

Declare what has to be true — not null, unique, accepted values, referential integrity, or a query of your own. If it doesn't hold, the pipeline stops and bad data doesn't move on. No external tool, no parallel project.

It tells you before you find out

Failed? You get an email with the error and a direct link to the run — and another when it recovers. After three consecutive failures the pipeline shuts itself off, instead of burning through your allowance failing silently.

How it works

Three steps from source to data that's ready.

1 Connect

Point at source and destination

A database, a spreadsheet, an API or a directory. Januss reads the catalog — tables and columns — and tests the connection before letting you save.

2 Model

Say what the data needs to become

Map columns, chain cleanup rules and write the transformation in SQL. The sync mode is chosen table by table.

3 Run

Schedule it and forget it

Set the schedule and preview the next runs before saving. Every run records status, duration and rows per step — and a failure sends an email.

API connector

Connect any API — Januss writes the connector.

Point it at the OpenAPI spec or at the documentation itself. Januss generates the connector and the table catalog, works out authentication and pagination, and validates with a real call before saving — with no glue code from you.

  • Reads OpenAPI and Swagger — or the documentation, when there's no spec
  • Six authentication methods, including OAuth2 and token login
  • Pagination and nested responses resolved on their own
  • It only saves after making the real call and successfully reading what came back — a broken connector never enters the catalog

The AI writes the connector once. After that it is deterministic: extraction runs the same way every time, with no AI in the data path.

connect · my-api.yaml
reading openapi.yaml … 48 endpoints found
auth detected: OAuth2 · bearer
pagination resolved: cursor
catalog generated: charges (22 columns)
validated with a real call: 200 OK
ready to extract
Transformation

Incremental that never trades away the result.

On every run, the destination table ends up identical, row by row, to what a full reload would produce. Incremental is a cost optimization — never a trade in guarantees. And the transformation runs as SQL inside the destination database: technically that is ELT, not classic ETL — the data never leaves for a separate engine and comes back.

  • Reprocesses only the scope that changed — and deletes what disappeared, which is where upsert alone leaves debris behind
  • When the scope can't be isolated, it reconciles everything rather than get it wrong — and tells you why
  • SQL executed in the destination database: no cluster to provision, pay for and maintain
  • Chainable cleanup rules per column — currency, date, decimal, text, regular expression, value maps — with an error policy set column by column
transform · customer_360 column rules
amount R$ 1.234,56 → 1234.56 currency mask
status A · I → active · inactive value map
document digits only error → fail
runs in the destination · native dialect
MERGE INTO gold.customer_360 t
USING silver.customers s ON t.id = s.id
WHEN MATCHED THEN UPDATE SET-- incremental: only the affected scope is reconciled
Data quality

What fails a test doesn't move on.

Declare what has to be true and let Januss stop the pipeline when it doesn't add up — whether a dashboard, an API or a model will consume that data. No external tool, no parallel project to maintain.

tests · gold.customer_360 5 of 5 passing
not null (customer_id) The column is never empty ✓ pass
unique (order_id) No duplicate orders ✓ pass
accepted values (status) Only the statuses the business recognizes ✓ pass
relationships (orders → customers) Every order has a customer that exists ✓ pass
sql: orders_without_items = 0 Any rule of yours, written in SQL ✓ pass

Each test can stop the pipeline or just warn — you decide, test by test.

Where your data lives

Your credentials — not even we can see them.

Your database passwords are encrypted in your browser, before they leave your machine. The platform stores only the encrypted package and never opens it — only the executor does, at the moment of execution.

  • End-to-end encryption — the password never travels or rests in the clear
  • SSH tunnel for databases not exposed to the internet
  • Execution stays in your workspace's region — Brazil or the United States
  • And when the data can't leave your network, the Runner handles it

The Runner is installed inside your network and talks to Januss over a single outbound connection on port 443. Extract, transform and load happen in there — the data never passes through the cloud. No inbound firewall rules.

your network
DB your database never leaves here
R Runner extract · transform · load
Januss orchestrates and schedules only
Pricing

Know your bill before you sign.

You pay for the rows written to the destination, across every step that writes. Each plan includes a volume, charges per additional million — and has a ceiling your bill never passes.

Rows written per month

10 million

Growth

$199/mo

Plan Rows included Minimum interval History Monthly Additional million Bill ceiling
Starter1M1 hour7 days$59$18$131
Growth10M15 minutes30 days$199$12$379
Pro50M5 minutes6 months$549$6$699
Business100M5 minutesunlimited$899$3$1,499
Enterprisecustomcustomunlimitedon requestnegotiated

Every plan includes real-time change capture, all sources and all destinations. Each plan's ceiling is always lower than the next plan's monthly price — going over on volume never costs more than moving up a tier.

How usage is counted

It counts every step that writes to the destination — not just the extraction. Wrote 1M on the load and another 1.2M across two transformations? That is 2.2M of usage in the cycle, even though the source is the same.

Each plan includes a fixed allowance of rows. Anything above it is charged per additional million — and you track usage live on your dashboard.

cycle usage · rows written2.2M
extraction1.0M
transform · silver1.0M
transform · gold0.2M
cycle total2.2M

Illustrative — real usage shows live on your dashboard.

Contact

Let's see this running on your data.

We talk through your scenario, show the platform running and — if it makes sense — put the first pipeline live together with your team. You talk directly to the people who build the product.