Count the tools yourself.

The plan pass

It walks the workflow, builds a lazy frame at every connection, and reports the field names and types at every port. An input file is opened for its header and closed again. That is what lets the canvas say a field is missing, or that a formula refers to a column nobody produces, before a row has been read.

Timed ten times over a five-node workflow reading a sixty-million-row CSV, the plan pass took between 13.6 and 21.6 milliseconds, median 17.6. The cache folder was still empty when the ten calls finished, and that is the part which proves nothing was read.

The run pass

It materialises every node's output to Parquet, in order, and reports rows and elapsed time per tool as it goes. A run can be cancelled while it is going, and Run to here computes only what the tool you selected needs.

What the plan pass cannot tell you

Some tools do not know their own output fields until they have seen data, because the fields come from the values rather than from the settings. Pivot and Detect Types are the plain examples: at plan time a Pivot reports the fields it will group by and none of the columns the pivot will create, because those are the values in a column nobody has read yet. Those fields appear after a run and not before it.

The timing above is what a five-node workflow costs. A canvas carrying several hundred tools would cost more, and nobody has measured that, so this page does not claim it.

The very first plan of the day, against a file the operating system had not yet cached, took 129 milliseconds rather than eighteen. The quick figure is the warm one.

The key

It is a hash of three things: the tool's type, its settings, and the keys of everything upstream of it. An input reading a file mixes in that file's path, its size and the time it was last written. Change a setting, and that node's key changes, and so does the key of every node below it. Nothing above it is recomputed, and nothing beside it is either.

Over the sixty-million-row workflow below, re-running with nothing changed came back in 0.014 seconds, with four of the five nodes served from the cache. Editing one setting on the Group & Aggregate tool, so that an average became a maximum, re-ran that tool and the one after it, and took 0.54 seconds.

Databases are deliberately excluded

There is nothing on disk to notice a change in, so a run always asks the database again. A flow cannot quietly report last week's numbers because the cache was pleased with itself. Planning keeps its cache, because planning reads a handful of rows and would otherwise query the database on every keystroke.

Where this bites

The cache is a folder of Parquet files on the same machine, and it grows with the size of what has been run. A workflow over a large file leaves a large cache behind it. Clearing it is one button, and per-file copies of workbooks are dropped after a fortnight if nothing has used them.

It is keyed on a file's path, size and modified time rather than on the bytes inside it. A file that changes without any of those three changing looks unchanged to it. That is a deliberate trade, because hashing a two-gigabyte file on every keystroke would cost more than the cache saves, but it is a trade and not a guarantee.

Files

A CSV, a Parquet file or a newline-delimited JSON file is opened as a lazy scan, and each node's output is written through a streaming sink, so the file is never held whole. The CSV in the measurement above is read that way.

Excel is the exception, because a workbook cannot be streamed. Binse reads one workbook, parks it in the cache as Parquet, and lets go of it before opening the next, so a folder of workbooks costs the memory of one workbook rather than all of them. Dropping a workbook on the canvas reads a two-thousand-row sample to find the field names, and nothing else. A plain JSON document, as opposed to a newline-delimited one, is also read whole, because that is what the format is.

51 file formats

Data Source reads 51 file formats, under 60 extensions, and Write Data and the results pane's Export write 35 of them. The list comes from the engine's own format registry, which every one of those tools asks.

• Text. CSV, tab and pipe separated files, fixed-width and whole-line text, JSON and newline-delimited JSON, XML, and the tables on an HTML page. ASC files are read, whether text or an ESRI ASCII grid.
• Spreadsheets. Excel .xlsx and .xls, and OpenDocument .ods. Excel macro and binary workbooks, .xlsm and .xlsb, are read only.
• Data files. Parquet, Avro, Arrow and Feather, and QlikView QVX. The .yxdb database format is read only.
• Databases in a file. SQLite, DuckDB, Microsoft Access .accdb and .mdb, including an ESRI personal geodatabase kept in one, and dBase.
• Statistical. SAS transport, SPSS and Stata files, read and written. SAS datasets and SPSS portable files are read only.
• Spatial. Shapefile, MapInfo TAB and MIF, KML and KMZ, GeoJSON, GeoPackage, the ESRI file geodatabase, FlatGeobuf and GML, read and written. GPX, DXF and GeoTIFF, Vertical Mapper and Surfer grids are read only. Shapes arrive as WKT text.
• Archives. Zip, gzip, bzip2, xz and tar are unpacked and read. Most of the formats that are written can also be written gzip or zip compressed.

Databases and APIs

9 kinds of data source answer for themselves in the runtime the installer ships, with nothing extra to download: SQLite, SQL Server and Azure SQL, PostgreSQL, MySQL and MariaDB, Snowflake, BigQuery, Databricks, any ODBC database, and any REST or JSON API. Five driver wheels ship inside the installer to make that true, and they are a good part of why it is 252.2 MB.

Getting results out

Results are written in any of the 35 writable formats, either one file or one file per distinct value of a field. A Write Data tool can also register what it wrote as a table in Dashboards, and running the flow again refreshes that table rather than adding a second one.

Writing Access files needs Microsoft's driver

Writing an Access file, or running SQL inside one, needs Microsoft's 64-bit Access Database Engine on the computer, and Binse does not ship it. Reading a table without the driver falls back to a reader built into Binse, and that reader passes the product's own test for both .accdb and .mdb. The first build of version 2026.9.16.3 failed that test, because it bundled an older copy of the reader's package; the installer was rebuilt the same day with the newer one.

A format in the list is not every file in the wild

The registry says a reader or a writer exists, and the product's own tests exercise samples from every category. That is not the same as every file somebody else's software has written opening cleanly, and a file that does not is a bug report worth sending.

Memory is not small

The peak working set for that streamed run was between 2.92 and 3.10 GB. Streaming means the file is not loaded whole. It does not mean a fixed small footprint, and this page will not describe it as one.

What available means, and what it does not

It means the driver imports and the code path exists. One engine has answered real queries: DuckDB, reading files on your own machine. No warehouse has. For every server dialect, Binse writes that dialect's SQL and the tests check the text of it, and no real BigQuery, Snowflake, Databricks, SQL Server, PostgreSQL or MySQL server has answered a query from this product.

The product's own generated guide also names Oracle, Redshift and Trino. They are not in the source, they are not offered in the interface, and they are not supported. That is a defect in our documentation rather than a feature, and it is on the list to fix.

A flow file can execute code

The Developer category holds a Python Script tool, an R Script tool and a Run Command tool. So a flow is not only data. A flow containing any of those three is a program, and opening somebody else's flow and pressing Run is running their code, on your machine, with your permissions. Binse does not sandbox it, and Binse does not warn about it when the file is opened.

Two things are true in the other direction, and both are worth knowing. Opening a flow does not run it, and the plan pass does not run those tools either, so a canvas can be read before anything executes. And the Python Script tool runs in a separate process with a timeout, so a script that hangs can be stopped and a script that crashes takes only itself down. Treat a flow from a stranger the way a script from a stranger would be treated.

What a count of tools does not tell you

It says how wide the palette is, not how deep any one tool goes. Two of the 110 are not data tools at all: Note is an annotation and Unsupported Step is a placeholder. The conservative count of tools that move or change data is 107.

Two of the twelve categories are small. Optimize has two tools and Parse has five. The list above is printed in full partly so that is visible rather than averaged away.

The scientific libraries that Predictive, Time Series and Optimize need are installed as standard rather than as a separate download, because a tool that sits in the palette and then says it cannot run is worse than a tool that is not there.

One engine, Data Flow and Explore

The language goes down to IF THEN ELSEIF ENDIF and multi-row [Row-1:Field] references. 76 documented functions, and 77 callable names, because ceiling is an alias of ceil.

Data Flow imports the whole of it. Explore, part of Binse Enterprise, imports it as well, offers 73 of the 76 inside a calculation, and brings in a SQL sibling for custom dimensions that have to be pushed down to a warehouse.

Dashboards is the exception

The claim does not stretch over it. The dashboard designer's formula box is a separate implementation that runs in the browser, with 60 functions and 8 aggregates rather than these 76.

It is the same language to write in and a different engine underneath, so a formula that works on the canvas is not guaranteed to work in a dashboard measure. Anyone describing this as one language across the whole of Binse is overstating it, and that includes us if we ever do.

One more limit, printed because it will be met

A Formula Across Rows cannot refer to the field it is creating, with a running count as the one exception. That is the same rule the language has in the product this syntax comes from, and it still surprises people.

Macros

A macro is an ordinary workflow that happens to contain Macro Input and Macro Output nodes. Those mark where data comes in and goes out, and everything between them is the macro's work. Nothing about the file is special, so a macro can be opened, run and debugged exactly like any other flow. That is the point of the design, because the alternative is a second kind of document nobody can inspect.

On another canvas a macro appears as one node, and before anything runs it is expanded. Its nodes are copied into the parent graph, its Macro Input nodes are replaced by whatever the parent had connected, and its Macro Output nodes become the node's outputs. The engine therefore sees a flat graph, which is why caching, cancellation, partial runs and error reporting keep working without knowing that macros exist. Nesting is capped at eight deep.

Batch Macro and Loop Macro run a sub-engine of their own, with caching switched off for the inner passes, so a workflow can run once per file, once per customer or once per month, or feed its own answer back until it settles.

Interface tools

These ask a person a question before the flow runs, and then decide which way it goes. Dropdown, Multi-Choice List, File Picker, Date Picker and Checkbox collect an answer. Apply Setting puts that answer into another tool's settings. Branch, Branch End and If Condition route around parts of the graph, and Stop with Error stops a run that should not have started.

Where a plain Parameter tool is enough it remains the better answer, because it is one node instead of a whole category. The interface tools exist for the cases it cannot cover: choices read from a lookup file, several answers at once, a file browser filtered to one kind of file, a date that defaults to the end of last month.

The awkward part

A macro's ports are ordered by where its marker nodes sit on its own canvas, top to bottom. Move a Macro Output node up past another one and the parent's ports change order. That is predictable once it is known and confusing until it is.

What travels

One record with a handful of text fields, Model_Name, Model_Type, Target, Predictors, Fitted_At, Details, and the model itself as Base 64. Everything else then works unchanged: a model can be browsed, cached, written to a file and read back tomorrow.

Because it is the same shape of record every time, one Apply Model tool applies a regression, a decision tree, a forest or a clustering model, rather than there being four scoring tools that differ only in which thing they will accept.

Spatial work is arranged the same way and needs nothing installed and no map licence: geometry is held as text in an ordinary string field, so it survives being written to a CSV and read back by something else.

The honest part

The model is pickled, because a fitted forest is a live object graph and nothing else round-trips it. Pickling is also how a great many programs have been talked into running code they should not have run.

Unpickling here goes through a whitelist. Only classes from the modelling libraries and a short list of builtins may be reconstructed, so a model field arriving from somewhere else is inert rather than dangerous. That is a guard rather than a guarantee, and it is a smaller guard than refusing the field altogether would be.

Your files stay files

Workflows are saved as plain JSON, with plain names, in a Workflows folder inside Documents. Anything written to CSV, Excel, Parquet or JSON is an ordinary file. Nothing described on this page is held behind a format only Binse can read, and that is the part which survives a decision to stop paying us.

What it costs

Where to go next