Souffle: a Datalog dialect that compiles your analysis into parallel C++

A Datalog with records, ADTs and functors, and the reason it exists

Souffle is described as a variant of Datalog for tool designers crafting analyses in Horn clauses, and it synthesises a native parallel C++ program from a logic specification.

The phrase that matters is for tool designers. Plain Datalog is a small, clean logic language, and it is excellent for what it does, but writing a real static analysis in it means fighting the language, because Datalog has tuples, and a real analysis needs records, algebraic data types, and functions.

Souffle adds those, and the feature list is worth reading as a list of the things an analysis engineer asks for. There are recursively defined record types, which are the ADTs, also called constructors, for tuples. There are user defined functors. There are strongly typed types for safety, so a mistake in a rule is a compile error rather than a wrong answer. There is aggregation, subsumption, and the choice construct, which was presented at Aplas in 2021 and gives a way to express a choice among alternatives.

The semantics are also extended beyond Datalog, with unbounded recursions permitted over numbers and terms.

All of this exists in service of one thing: writing an analysis. The project also points at what it is used for, with the topics listing static code analysis and translator, and the paper list naming the tool as a synthesis of program analyzers.

The result is a language that looks like Datalog to someone who knows Datalog and does not look like it to someone who only knows SQL. That is the correct trade for its audience and the wrong one for a general purpose tool.

Two execution modes, and the choice between compiling and interpreting

The features list contains two ways to run a Souffle program, and they appear as separate academic results, which is a clue about how distinct they are.

The first is efficient translation to parallel C++ of Datalog programs, cited to CAV 2016 and CC 2016. The second is efficient interpretation using de-specialization techniques, cited to PLDI 2021.

The compiled path is the headline. You write a logic specification, the compiler synthesises a C++ program, and the result is a native binary that uses the machine's parallelism. That is a fundamentally different deployment story from an interpreter, and it is why the project talks about synthesising a native parallel C++ program rather than running a program.

The interpreted path exists because compiling has a cost, and the de-specialization work in 2021 addresses the case where you want the language's semantics without paying the compilation. The two also have different failure modes. A compiled artefact is fast but it is a build artefact, so it has to be rebuilt when the analysis changes. An interpreter starts immediately but runs the rules rather than the generated code.

The rest of the list is about the data side. There is a specialized data structure for relations, with optimal index selection, cited across PACT 2019, PPoPP 2019, PMAM 2019 and VLDB 2018, which tells you that the relations are not generic containers but a structure chosen for the access patterns of the analysis.

There is also an extended I/O system for relations, including SQLite3 interfaces, and C++ and SWIG interfaces, and provenance and debugging support from TOPLAS 2020, and profiling tools. The provenance piece is the one that matters most for an analysis tool, because a static analyser that cannot tell you why a fact was derived is a static analyser you cannot debug.

Installing it, and the legacy flag you may need

There are two routes, and the packaged one is the one to take if your distribution is covered.

If you are using Ubuntu, Fedora or Oracle Linux, get a packaged version from the Releases section. Otherwise, obtain the source code with git.

git clone https://github.com/souffle-lang/souffle.git

The build instructions are on the project site at souffle-lang.github.io/build, and the developer tutorial is at souffle-lang.github.io/development for working on the language itself.

What the README does not spell out is the dependency list, and for a C++ project of this size that is the part you will spend time on. The repository layout shows the shape: a CMakeLists.txt at the root, a cmake/ directory, src/ for the implementation, tests/ and utilities/ for the test harnesses, a debian/ directory for the Debian packaging, a vcpkg.json for Windows dependency management, a choco-packages.config for Chocolatey, sh/ for shell scripts, man/ for the manual pages, doxygen.in for the API documentation generator, and licenses/ holding the licence texts.

The legacy flag is the other thing to know about up front. If you have written code for an older version of Souffle, use the command line flag --legacy, or add the following line to the start of your source code.

.pragma "legacy"

That pragma is the language telling the compiler to accept the older syntax, and the existence of a per file pragma rather than a global switch tells you that legacy support is a property of a translation unit, which is what you want in a codebase that is mid migration.

The continuous integration setup is visible in the badges and worth knowing about, because it tells you what the project considers supported. There is a CI-Tests workflow, an MSVC-CI-Tests workflow, so Windows is tested as well as the usual platforms, and codecov is wired to the master branch. The project also states that its continuous integration framework enforces coding guidelines with the help of clang-format and clang-tidy, and the .clang-format and .clang-tidy files are at the repository root, so the style rules are enforced rather than documented.

The repository as a research artefact, with papers you are expected to cite

The README has a section addressed to academics, and it is unusual enough to change how you should treat the project.

It says that if you use our work, please cite our work, and points to a list of publications on the project site. The main publications given are the CAV 2016 paper on the synthesis of program analyzers, and the CC 2016 paper on fast large-scale program analysis in Datalog.

That framing tells you two things. The first is that this is not a hobby project with a feature list, it is the artefact of a research programme, and the features you read in the README are the contributions of individual papers, which is why each line carries a citation. The second is that the citation request is a licensing and attribution matter as much as an academic one, and a team using Souffle in a published tool has a reason to read the licences/ directory rather than assume a single licence covers the tree.

The licences directory in the repository root is worth a note for that reason. The README's license line points at a specific file, souffle-lang/souffle/blob/master/licenses/SOUFFLE-UPL.txt, and the top level carries both a LICENSE and a licenses/ directory, which is the convention for a project that ships third party code under separate terms.

The same research character shows up in the contribution workflow, which is unusually explicit for a compiler. The README says to find an issue in the issue list, fork the repo, push your changes to a branch, and submit a pull request from the fork, and the issue list is documented as the place for bug reporting, enhancements, documentation, proposals, releases, compatibility issues and refactoring. A separate discussions board is for questions and engagement with other community members.

For a prospective user, the practical consequence is that the issue tracker is a specification document. Reading the open issues on the language tells you what is planned and what is contested, which is a better signal than a roadmap.

What Souffle is not for, and the Datalog you already have

Three limits, and the second one is the one that catches people.

The first is that this is not a general purpose programming language. It is a logic language for analysis, and while it has records, ADTs, functors and aggregation, the execution model is bottom up evaluation of a Horn clause program, not imperative control flow. If your problem is writing an application, this is the wrong tool and you will feel it.

The second is the build cost. Because the headline path compiles your specification into C++, the analysis is a build artefact. Changing a rule means recompiling, and a project with a large rule set pays that cost on every iteration. This is the practical reason the interpreted mode exists, and it is why the PLDI 2021 de-specialization work is in the feature list at all. If your workflow is write rule, run, inspect, repeat, the compiled model is a cost you have to plan around rather than a pure win.

The third is the size of the change from Datalog itself. Souffle is a superset in the sense that it adds features, but every feature you use is a feature you have to learn, and the semantics of unbounded recursion with numbers and terms, the choice construct, and subsumption are not things a Datalog reference will explain to you.

The alternative worth naming is writing the analysis in Datalog proper and using an existing Datalog engine, or writing the analysis directly in a general purpose language with a query engine underneath. The difference in approach is where the logic lives. A Datalog engine evaluates a fixed set of facts and rules at runtime, and your analysis is data. Souffle takes the same rules and turns them into code, and your analysis becomes a program with the rules baked in, which is why it can be parallelised at the C++ level and why it can use specialised relation structures with an index selected for the access pattern.

If you need the analysis to change at runtime, that difference decides the question, and it decides it in favour of the engine.

Editorial conclusion

Souffle fits a static analysis engineer who wants to write a dataflow or type analysis as Horn clauses and get a native binary rather than an interpreter, and it fits a team with a large corpus of code to analyse where the compiled artefact pays for itself. It does not fit a general purpose programming task, and it does not fit a project that needs incremental reanalysis, because the compilation model means the cost is paid per build. Check three things before you commit. Check which execution mode you want, because the project documents both efficient translation to parallel C++ and efficient interpretation using de-specialization techniques, and they have different operational profiles. Check the licence, because the code is under UPL-1.0 with the licence text in the repository and a separate file per component, which is a different regime from a standard permissive licence. And check whether you need the extended semantics, since unbounded recursions with numbers and terms, choice construct, aggregation and subsumption are what separate Souffle from plain Datalog and each has a cost. The last push was on 2026-10-02, the newest listed release is 2.5 from 2025-03-24, and the project is developed through a researcher led academic lineage.

Frequently asked questions

Official sources

1. License: UPL-1.0
2. Project website
3. README
4. Releases
5. souffle-lang/souffle on GitHub