sling is an extract and load tool for small to medium pipelines

Extract and Load, deliberately not Transform

The repository description is one sentence: Sling is a CLI tool that extracts data from a source storage or database and loads it in a target storage or database. The README adds the positioning. Sling is a passion project turned into a free CLI product which offers an easy solution to create and maintain small to medium volume data pipelines using the Extract and Load approach. The word small to medium is doing the work. There is a whole category of teams who need to copy a table from one place to another every night, or land an API response into a warehouse, and who find a full transformation framework too much machinery for the job. Sling is the tool for that case. The Extract and Load framing is also a boundary. In a classic ETL tool there is a Transform stage where rows are reshaped, joined and aggregated inside the engine. Here the transformation is a SQL query, which means the logic lives where the data already is, in the database, and the moving part stays simple. The supported directions are listed explicitly. Database to database, file system to database, database to file system, API to database and API to file system. Notice what is missing: there is no API to API, and no file system to file system. The shape of the matrix is what a data movement tool looks like when it starts from a warehouse as the destination. The audience is data engineers and analysts who need a repeatable, reviewable copy job rather than a platform.

Connections as strings, environment variables, or dbt profiles

How you tell sling where the data lives turns out to be one of the more interesting parts of the design. The feature list mentions managing, viewing, testing and discovering your connections with the sling conns sub-command, and using an environment variable as a connection if you prefer.

export MY_PG='postgres//...

That is a connection string with an embedded scheme, and the point of the scheme is that the tool can work out which driver to use from the string itself. The sling conns sub-command then exists so that you can inspect, test and create those strings interactively rather than writing them blind. The second source of connections is an existing one. Sling reads your existing dbt connections, from the dbt profiles.yml file, which is a significant shortcut for anyone already using dbt, because the credentials you already maintain become the credentials sling uses. That gives three ways in, and they compose well. dbt profiles for the warehouse you already have, environment variables for anything secret that should not live in a config file, and the conns command for the rest. The practical consequence is that a connection is a value rather than a configuration section, so the same connection identifier can be used from a YAML file, from the command line or from an environment variable. For a tool whose configurations are meant to live in git, that matters.

Custom SQL as the source, and YAML that can hold variables

The source of a pipeline can be a SQL statement rather than a table, and the README gives the example.

--src-stream='select * from my_table where col1 > 10'

Calling it a stream rather than a query is a hint about the implementation. The query is executed and consumed as a stream of rows, so a pipeline can push a filtered or joined result through without materialising it as a table first. The second half of the story is configuration. Sling provides YAML or JSON configurations, described in the README as perfect for git version control, and those configurations can use your environment variables.

select * from my_table where date = '{date}'

That is the whole configuration story in two capabilities. A pipeline definition in a file you can review, diff and approve, with a parameter substituted at run time. Two smaller features round it out. Transformations are available in the configuration, with the flatten option named as an example, which auto-creates columns from nested fields, so a JSON payload with nested structure can land as a table without a hand written schema. And there are pre and post SQL commands, which is how you truncate a target before loading or run something after the copy. For an EL tool the interesting design decision is that the pipeline definition is a document rather than code. That is what makes it reviewable, and it is also the limitation: when the transformation needs logic that a SQL query and a flatten option cannot express, this is the wrong tool.

Replication: one wildcard instead of many pipelines

Copying one table is a normal job for any tool. Copying a hundred tables is where pipelines become a maintenance problem, and replication is sling's answer. The README describes powerful replication logic to replicate many tables with a wildcard, and the example given is a schema pattern such as my_schema.*. That is a large reduction in effort. A schema level wildcard means one configuration entry covers every table in a schema, and the tool handles the discovery, which in a database context means reading the metadata and enumerating what is there. There is also a separate replication defaults test in the repository's justfile, run as its own recipe with the go test invocation for TestReplicationDefaults, which suggests the default behaviour is pinned by a test rather than left to drift. For a nightly job that loads a whole schema into a warehouse, this is the feature that turns sling from a tool you use once into a tool you keep. For a single table copy it is irrelevant, and the wildcard is the sort of thing worth testing carefully before pointing at a production schema, because a misconfigured pattern can pick up more than you intended.

The connector list is the real scope of the project

The connectors section of the README is long, and it is the most honest description of what the tool covers. The database connectors include adbc, azuredwh, azuresql, azuretable, bigquery, bigtable, clickhouse, d1, databricks, dbase, duckdb, dynamodb, elasticsearch, opensearch, exasol, fabric, firebolt, mariadb, mongodb, motherduck, mysql, odbc, oracle, postgres and prometheus, among others. The data lake connectors are athena, Ducklake, iceberg, S3 Tables and lancedb. The file system connectors include azure, b2, dospaces, gs, local, minio and r2. Two entries tell you something about the architecture. adbc is the Arrow database connectivity standard, and iceberg-go and arrow-go are in the dependency list, so the internal representation of rows is Arrow based. That is a deliberate choice: a columnar in memory format means one path for pulling from a database, from an API or from Parquet on disk and pushing to a file or a warehouse. The second is that duckdb, d1 and motherduck are all present, which are analytical engines rather than operational databases. The list is weighted towards analytical and lakehouse destinations, which is consistent with the positioning as a loading tool. The dependency list in go.mod backs this up. It is long, and it includes the cloud provider SDKs for Google, Azure and AWS, ClickHouse, Databricks, Apache Arrow, Apache Iceberg, and the Bubble Tea, Lip Gloss and Huh libraries from Charm, which are the toolkit behind a polished terminal interface for the conns command.

One binary, several release targets

The distribution story is the first item in the feature list: single binary deployment, built with Go. That is the reason there are no configuration files to install and no runtime to provision. You download the binary, point it at a connection, and it runs. For a tool that has to run in CI, in a cron job or inside a container image, a single artefact with no dependency tree is worth more than it sounds. The repository carries the release configuration to match. There are separate goreleaser files for Linux on amd64, Linux on arm64, macOS and Windows, plus a goreleaser.notes.md file for the release notes and a .golangci.yaml for linting. The presence of a separate arm64 Linux configuration alongside the amd64 one is a good sign, since the same pipeline on a build machine that happens to be an ARM Mac is a common source of broken releases. The module path is github.com/slingdata-io/sling-cli and it requires Go 1.26.0, which is a recent toolchain requirement and worth checking against your build environment before you plan a pipeline around it. The docs live at docs.slingdata.io, and there is a Discord community linked from the README. The package is also distributed on PyPI as sling and as a Docker image, since the README carries badges for pip downloads and for Docker pulls of slingdata/sling.

GPL version 3, frequent releases, and a large test matrix

The licence is GPL-3.0, which the README links to in the badge row. For a CLI tool that people install on their own machines, GPL version 3 is a reasonable default and it means that if you modify and redistribute the binary you have to publish the source of your modification. It is a constraint on distribution rather than on use, so most teams never encounter it. The release cadence is regular. v1.6.5 came out on 2026-10-08, v1.6.4 on 2026-09-28 and v1.6.3 on 2026-09-13, and the last push was on 2026-10-15. The repository is not archived. The test setup is more interesting than the release numbers. The justfile in the repository root runs a matrix of suites, and the aggregate recipe lists them all.

test-all: test-cli test-connections test-dbio test-core test-python test-cdc test-eval

So there are separate suites for the CLI itself, for connections, for the database IO layer, for core functionality, for the Python components, for change data capture and for evaluation. The database suite runs with a parallelism of 4 and a 35 minute timeout, which tells you that the connection tests actually talk to live databases rather than mocks. The build recipe is minimal by comparison.

(cd cmd/sling && rm -f sling && go build .)

The repository also carries a justfile rather than a Makefile, a context7.json file, a .infisical.json for secrets management in CI, and an api/ directory alongside cmd/ and core/, which suggests the CLI is a thin layer over a reusable core.

Editorial conclusion

Adopt sling when you need repeatable small to medium data copies between a database, a file system or an API and a warehouse, and you want the pipeline definition to live in git as YAML. Do not adopt it when the transformation needs a full transformation engine, because the approach is Extract and Load with a SQL query and a flatten option, not a programmable pipeline. Before you point a schema wildcard at production, run the replication defaults check and confirm which tables the pattern picks up, and check that your build environment meets the Go 1.26.0 requirement in go.mod.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. slingdata-io/sling-cli on GitHub