Etl.Net: a reactive ETL engine for .NET, and the gaps its author admits to

A LINQ shaped alternative to SSIS, and why that framing matters

Etl.Net describes itself as an implementation of a mass processing engine to use in a similar way to LINQ, with every SSIS feature and much more. It is fully written in .NET for multi platform use and for straightforward integration into any application.

The framing matters because SSIS, the SQL Server Integration Services packages that .NET developers reach for when a data flow outgrows a script, are a different world. They are designer driven, they run on the SQL Server estate, and they are hard to unit test. An ETL that lives inside your application, written as a pipeline of LINQ style operations, can be tested, versioned and deployed with the rest of the code.

The claimed properties of the implementation are specific. The reactive approach is said to ensure parallelised multi streams, high performance and a low memory footprint even with million rows to process. Those are the three numbers an ETL buyer actually cares about, and they are the reason the project is worth looking at for a bulk data path inside a .NET application rather than a separate integration server.

The repository topics back up the positioning: business intelligence, csv parser and reader and writer, dotnet, dotnet core, dotnet standard, entity framework, etl job, extract, load, sftp and transform. The last one, load, is worth noticing. Etl.Net is not only an extract-and-transform library that hands you a file. It writes into databases, object stores and file systems, which is what makes it a full ETL rather than a reader.

The licence is MIT, with the LICENSE file at the repository root, and the documentation site is paillave.github.io/Etl.Net.

Roughly twenty NuGet packages, one per kind of endpoint

The package table in the README is the clearest description of the scope, because it is a list of every kind of system the engine can talk to.

The core is Paillave.EtlNet.Core, with Paillave.EtlNet.Autofac sitting alongside it as the dependency injection integration, which is the standard way you would wire an ETL engine into an application that already uses a container. Paillave.EtlNet.ExecutionToolkit is the piece that runs the jobs.

Then come the connectors, and they are the interesting part. There is a package per destination and per source: Paillave.EtlNet.SqlServer for SQL Server, Paillave.EtlNet.S3 for Amazon S3, Paillave.EtlNet.AzureStorageAccount for Azure Blob Storage, Paillave.EtlNet.Sftp and Paillave.EtlNet.Ftp for file transfer, Paillave.EtlNet.ExcelFile for spreadsheets, Paillave.EtlNet.EntityFrameworkCore for an ORM destination, Paillave.EtlNet.TextFile and Paillave.EtlNet.JsonFile for flat files, Paillave.EtlNet.Dropbox, Paillave.EtlNet.GraphApi for Microsoft Graph, Paillave.EtlNet.Mail for email, Paillave.EtlNet.Http for HTTP endpoints, Paillave.EtlNet.Pgp for encryption, and Paillave.EtlNet.FromConfigurationConnectors for connecting from configuration rather than code.

That last package is the one to notice. It implies the pipeline can be described declaratively, in configuration, rather than entirely in C#. For a business intelligence team that wants ETL definitions to live in a config file and change without a redeploy, that is a feature worth evaluating.

The connector packages are where the design choices show. The engine is not trying to be an ORM or an HTTP client, it is trying to be the thing that moves rows between systems, and each connector is a small package you take only if you need it.

The maintainer asks for help with documentation and tests

The README has a section at the top headed with a request for help, and it is the most important thing on the page for anyone evaluating the project.

Two things are asked for. The first is documentation. The website contains what is needed to start and get in touch, but the author states that a dramatic amount of serious features is not documented there. The second is unit tests, with the reasoning spelled out: a proper test code coverage is the only real way to be taken seriously when it is about selecting the right open source library.

Then the history: there was a time when some unit tests existed only for the reactive engine of the core, Paillave.EtlNet.Core, but the author says he had to decommission them in the event of the V2 release.

That is the honest version of the project's maturity, and it deserves to be read as a statement of fact rather than as modesty. A data pipeline library with no meaningful test suite is a different kind of dependency from one with tests, regardless of how good the code is. The reactive core with parallelised multi streams and a claimed low memory footprint is exactly the kind of code where a regression is expensive and hard to spot in production.

The author asks for contributors by email, and the repository carries a CODE_OF_CONDUCT.md, a `docs/` and a `documentation/` directory, an `azure-pipelines.yml` for continuous integration, and a `src/` directory holding the source of the packages listed above.

Getting it in, and what you are signing up for

There is no install script and no getting started section in the visible documentation. The packages are distributed on NuGet under the `Paillave.EtlNet` prefix, and the table in the README links each one to its package page.

The packages you would actually reference look like this:

Paillave.EtlNet.Core
Paillave.EtlNet.Autofac
Paillave.EtlNet.ExecutionToolkit
Paillave.EtlNet.SqlServer

The core package carries the engine, the Autofac package carries the container integration, the ExecutionToolkit carries the job runner, and the connector package carries the endpoint you are reading from or writing to. You take the connectors you need and nothing else.

The repository itself is built with the standard .NET tooling. There is a `.sln` style workspace file named `Paillave.Etl.code-workspace`, a Visual Studio `.vs/` directory, a `.vscode/` directory, and an `azure-pipelines.yml` at the root for the build. The `src/` directory is the source of the packages, and `docs/` and `documentation/` sit alongside it.

What you should expect on first contact is that the documentation site gets you started, and that the depth is in the source. The author's own note about a dramatic amount of serious features being undocumented is the thing to plan around, not around.

On versions, the recent release tags tell a story worth reading. The v2.2.0-beta tag is dated 2026-04-29 and named for addressing memory leaks and new extensions, while v2.2.0 itself is dated 2026-05-04. A beta whose title names the problem it fixes, followed by the release, is a good sign of process. The earlier v2.1.9-beta is dated 2023-06-29, so the gap between the two 2.x lines is measured in years, which tells you the 2.2.0 work was a substantial rewrite rather than an increment.

What this engine is not, and where the alternatives sit

Three boundaries matter when you are choosing an ETL approach for .NET.

The first is that this is an in-process library, not a scheduling or orchestration platform. It moves rows between systems on your behalf; it does not run jobs on a schedule, retry them, alert on failure, or give you a lineage view. The `etl-job` topic and the ExecutionToolkit package suggest job execution inside your application rather than a job server. If you need a scheduler, you provide one, and you inherit the operational burden of it.

The second is the shape of the data it moves. Etl.Net is a stream processing engine, which means it is built for flows where you can process rows as they pass rather than loading a whole table into memory. That is the right shape for an extract of ten million rows and the wrong shape for a reconciliation that needs random access to a whole dataset. The reactive design is the source of both the claimed performance and the constraint.

The third is the maintenance risk, which the README itself raises. A library maintained by one person, with the tests removed at the last major release and the documentation admittedly incomplete, is a dependency you are taking on with your own engineering.

The alternatives split into two families and the difference in approach is clear. The first is the legacy integration server, SSIS itself, which stays the right answer when your team is already a SQL Server shop with a BI group that maintains packages in the designer and you need the operations tooling that comes with it. The second is a general purpose ETL framework for .NET with a larger ecosystem and a community, which trades the LINQ shaped embedding for a wider set of maintained connectors and a conventional test story. Etl.Net's pitch is the third option, a reactive engine you call directly from your own code, and the case for it is strongest when the pipeline is part of an application rather than a separate system.

Editorial conclusion

Adopt Etl.Net if you are a .NET team that has outgrown SSIS and wants an in-process, LINQ shaped ETL with connectors for the sources you already run, and you are prepared to read the source rather than the documentation. Do not adopt it as a product on a critical pipeline without reading the caveats, because the maintainer states that the documentation omits serious features and that the unit test suite was decommissioned at the V2 release. Verify first which connector packages your sources need, that the reactive core's memory behaviour suits your row counts after the 2.2.0 changes, and that you can support the project yourself.

Frequently asked questions

Official sources

1. License: MIT
2. paillave/Etl.Net on GitHub
3. Project website
4. README
5. Releases