facebook/Haxl: automatic batching and caching for Haskell data sources

The problem Haxl solves, and who actually has that problem

Fetching data from several remote systems inside one piece of application logic tends to produce code that mixes two concerns: what data is needed, and how to fetch it efficiently. The README states that Haxl can automatically batch multiple requests to the same data source, request data from multiple data sources concurrently, cache previous requests, and memoize computations. The claim is that handling these behind the scenes lets data-fetching code stay cleaner than code that optimizes fetching by hand.

The intended user is a Haskell developer building a service that talks to a database, a web API, or a cloud service. Haxl does not ship connectors for those systems. The README says you will likely need to build one or more data sources, described as the thin layer between Haxl and the data you want to fetch. So the audience is narrower than the description suggests: this is infrastructure for people who are prepared to write that layer, not a library you import and point at Postgres.

How the batching and concurrency actually work

The core idea, as the ICFP'14 paper title puts it, is an abstraction for efficient, concurrent, and concise data access. Application code describes the data it needs; the framework collects those requests and decides how to issue them. That is why the README's list of four capabilities is phrased as things Haxl does automatically rather than functions you call.

Two mechanisms are named in the repository. The core framework lives in the haxl package, and the repository also contains haxl-facebook under example/facebook, an incomplete example data source for the Facebook Graph API built on the existing fb package. The README points to a generic data source in Haxl.DataSource.ConcurrentIO for performing arbitrary IO operations concurrently, given some boilerplate defining the IO operations you want to perform. That module is the practical starting point when your backend is not Facebook: you describe the operations, and Haxl decides when to run them together.

Caching and memoization are listed as automatic, but the README does not document cache invalidation, scope, or eviction. If you need per-request cache lifetimes, that is something you will have to establish from the source or the Hackage documentation, not from the README.

Installing Haxl and building a first data source

The README does not give install commands. It points to Haxl Documentation on Hackage at hackage.haskell.org/package/haxl, and the repository ships a stack.yaml at the top level, so Stack is the build path the repository itself uses. Cloning and building the repository is the way to get the examples compiling before you write your own data source.

git clone https://github.com/facebook/Haxl.git
cd Haxl
stack build

Because the repository contains two packages, haxl and haxl-facebook under example/facebook, expect the build to cover both. After that, the README's recommended next step is the walkthrough of an example Facebook data source, which it says queries the Facebook Graph API concurrently. For a backend that is not Facebook, the SQLite-backed blog engine in Fun with Haxl (part 1) is the more relevant walkthrough, since it starts from scratch rather than from an existing client library.

The N+1 Selects Problem document in example/sql is where the batching claim becomes concrete: the README says it explains how Haxl can address a common performance problem with SQL queries by automatically batching multiple queries into a single query, without the programmer having to specify this behaviour. Read that before designing your own data source, because the shape of your operations determines whether batching is possible at all.

Where Haxl is the wrong tool

Haxl is not a database driver and not an ORM. If your application issues one query per request and never fans out across related entities, there is nothing to batch and the framework adds a layer between your code and the client library you would otherwise call directly. The batching benefit depends on many small requests arriving close together in the same computation.

The second constraint is the data source work itself. The README is explicit that you will likely need to build one or more data sources, and the only complete-ish example in the repository is described as incomplete. That is a real cost: you are writing the layer that translates Haxl operations into calls against your database or API, including whatever error handling and retry semantics your backend needs. The README does not document error handling or retry behaviour at all, so those decisions are yours.

Third, the release history is thin. The most recent release listed is 0.5.1.0 from 2017-07-25, while the last push to the repository was on 2026-03-15. Commits continue, but there is no recent tagged release to pin against, which matters if your build process depends on released versions rather than a commit.

Haxl compared with plain concurrent Haskell

The obvious alternative is not another library but doing it yourself: async and friends, plus an explicit batching layer or a connection pool. That approach gives you direct control over when requests are issued, how failures are retried, and how results are cached, and it requires no new abstraction. The difference in approach is that with plain concurrency you decide the grouping at each call site, whereas Haxl collects the requests from the computation and groups them for you. The README's selling point is precisely that the programmer does not have to specify the batching behaviour.

The trade-off is legibility. With explicit concurrency, a reader can see where the parallelism happens. With Haxl, the parallelism is a property of how the computation is assembled, so reasoning about it means understanding the framework's scheduling, not reading a mapConcurrently call. If your team is small and the data-fetching code is short, the explicit version is easier to debug. Haxl pays off when the same fetch pattern repeats across many call sites and hand-optimizing each one is the actual maintenance burden.

Maintenance, releases, and the BSD-3-Clause licence

The repository is not archived, and the last push was on 2026-03-15. The most recent release shown is 0.5.1.0 from 2017-07-25, so the gap between tagged releases and repository activity is wide. Plan for building from a commit or a Git dependency rather than expecting a fresh Hackage release, and check the changelog.md in the repository for what changed between the release you pin and the commit you build.

Haxl uses the BSD 3-clause License, as found in the LICENSE file. That is a permissive licence, which in practice means you can use the library in closed-source applications provided you keep the copyright notice and licence text, and you do not use the names of the copyright holder or contributors to endorse your product. This is a description of the licence text, not legal advice; if the attribution requirements matter for your distribution, have counsel read the LICENSE file rather than this paragraph.

Upgrade cost is dominated by the data source layer, not by Haxl itself. When the framework changes, your DataSource instances are the code that has to be revisited, and the repository's tests directory is the place to check what behaviour is actually covered before you rely on it.

Editorial conclusion

Adopt Haxl if you are writing Haskell services where the same request pattern repeats across a graph of data sources and you are willing to implement the DataSource instances yourself; the example/facebook and example/sql directories are the fastest way to see what that costs. Do not adopt it if you want a ready-made client for a specific database or API, since the repository ships only the core framework plus an incomplete Facebook example. Before committing, verify that Haxl.DataSource.ConcurrentIO covers the IO operations you need, and read example/sql/readme.md to confirm the batching behaviour matches your query shape.

Frequently asked questions

Official sources

1. facebook/Haxl on GitHub
2. Issues
3. License: BSD-3-Clause
4. README
5. Releases