Skip to content
Talk to a specialist

The solution

How it works, from setup to history.

The pieces of the platform, in the order you will use them.

The four building blocks

These four are all you need to build any routine.

Job

A process. It is what you schedule, run and watch.

Step

One stage of the process: SQL, script, data copy, backup. Each one decides what to do if it fails.

Schedule

When it runs. Registered separately, reusable, with an explicit time zone.

Executor

The service that runs your routines on your own server. It is separate from the portal, and there can be several — on different machines, close to where the data lives.

Step types

What you build on screen, and what needs a script.

The difference is worth knowing: it tells you whether you need someone who codes.

🗃️

SQL

A query or stored procedure on any of the connected databases. The result can feed the next step.

🔁

DataSync

Data copy between databases, with source, target and field mapping on screen — without a line of code. Four strategies: full load, date window, incremental by key and upsert. SQL scripts before and after, on both the source and the destination, and files as source or target: CSV, Parquet and Excel.

💾

Database backup

A scheduled, compressed dump with its own retention — and an alert when it fails.

🐍

Python

This is where any system with an API comes in — Salesforce, Dynamics, HubSpot, your in-house ERP, an internal service. Connections and credentials arrive ready as environment variables, so the script never carries a password.

No catalogue, no ceiling: there is no ready-made connector to drag in — in exchange, no integration is out of reach and there is no extra module to contract.

⌨️

Shell / PowerShell

The same, for those who prefer a system script. SFTP, SMB and rsync already ship in the executor image.

🔗

Shared command

Write it once, use it in several processes. Versioned, with explicit synchronisation.

Files and Python

A spreadsheet is a data source, not an attachment.

A good share of the world’s real ETL starts in an Excel file somebody exports. It comes in through DataSync, on screen: CSV, Parquet and Excel are read directly, with field mapping and without writing code. Python is still there for what is neither a database nor a spreadsheet — an API, a proprietary format, a transformation only code can express.

Excel, CSV and Parquet

Read directly by DataSync, with field mapping on screen — no manual conversion and nobody opening a spreadsheet to save it as CSV first. And the same three formats work as a target, with compression.

No script: files are source and target in the step itself.

When Python comes in

When the format is proprietary, the rule is too complex for mapping, or the data comes from something that is neither a file nor a database. pandas and openpyxl are already in the image.

JSON and XML

Native in Python. Parquet does not need it: DataSync reads and writes Parquet on its own.

Any API

REST, SOAP, the internal service down the hall. The credential arrives as an environment variable.

ETL or ELT — your call

Transform in Python before writing, or dump it raw and transform in SQL afterwards: the platform does not impose the design. What it gives you in both cases is what a loose script lacks — a schedule, order between steps, history, an alert when it fails and control over who can touch it.

Between steps

What one step hands to the next.

Success and failure

Each step chooses: stop, continue to the next one, or jump to a specific step.

Data

The result of a query becomes a variable in the next step — including in a loop, one execution per row.

Dependency and chaining

A process can wait for another, or trigger the next one when it finishes cleanly.

Frequently asked questions

What people ask before booking the call.

Can it load an Excel spreadsheet into the database automatically?
Yes, and without programming: the DataSync step reads Excel (.xlsx), CSV and Parquet directly, with field mapping on screen. Python is still available for anything needing unusual treatment — with pandas and openpyxl already installed and the connection injected, no password in the script. The routine runs at whatever time you schedule, with history and an email alert when it fails.
Can it copy tables between different databases?
Yes, and without writing code: the DataSync step has source, target and field mapping on screen, with four strategies — full load, date window, incremental by key and upsert — and SQL scripts before and after, on both the source and the destination. Source and target can be from different vendors — from Oracle into PostgreSQL, for example.
Which databases does it talk to?
Seven for execution: Oracle, SQL Server, PostgreSQL, MySQL/MariaDB, Firebird, DB2 and ODBC. The platform’s own control database can be SQL Server, MySQL, PostgreSQL, Firebird or Oracle — you use what you already have.
Do I need to know how to code to use it?
For SQL, DataSync and backup, no: you build it on screen. A script (Python, Shell or PowerShell) is only needed when the routine has to talk to something that is not a database — an API, a remote file, a legacy system.
Does it integrate with systems that have an API, such as Salesforce, Dynamics or our own ERP?
It does, through the Python step: any system with a REST or SOAP API is within reach, and credentials arrive as environment variables. There is no catalogue of ready-made connectors to drag in — in exchange, no integration is out of reach and there is no extra module to contract.
Does it work without internet access, inside our network?
It does. It is installed on your server, in a container, and with the control database on your premises too nothing needs to leave the network. There is no telemetry and the product does not “phone home”.
Does it replace cron and SQL Server Agent?
It does, and it solves what they do not: a single routine crossing databases from different vendors, with history, an alert when it fails, control over who may run it, and a version of whatever was changed.
Does it run on Windows?
The portal runs on Linux, in a container — including on Windows Server with virtualisation. Executors run either way: in a Linux container, with every automation type, or as a native Windows service, to reach what lives on the internal network with no Linux VM in between. The Windows executor runs SQL queries, data synchronisation (DataSync), and PowerShell and Command Prompt scripts; for Python scripts, Bash scripts and database backups, use a Linux executor.
How do I find out that a routine failed?
By email, at two independent levels — the whole process and each individual step — and on the dashboard, which shows what ran, when, for how long and with what result, together with the full execution log.

Shall we run one of your processes?

We will build, together with you, a routine much like the one running in your company today.

Talk to a specialist