Egglog: Datalog + Equality Saturation

• Egglog is a unified fixpoint reasoning system that merges Datalog’s incremental execution with equality saturation’s term rewriting and congruence closure.
• It employs a canonicalization process that alternates fact propagation with rebuilding, ensuring efficient processing and avoiding quadratic performance issues.
• Egglog’s Python interface, via egg-smol, integrates typed e-graphs and declarative rewrites to support advanced optimization, analysis, and proof search.

Egglog is a fixpoint reasoning system that unifies Datalog and equality saturation, combining efficient incremental execution, cooperating analyses, lattice-based reasoning, term rewriting, efficient congruence closure, and extraction of optimized terms (Zhang et al., 2023). In related ecosystem usage, especially in "Egglog Python," the name also denotes a Pythonic interface to the experimental egg-smol library, where typed e-graph sorts, functions, and rewrite rules are expressed through familiar Python constructs while remaining backed by Rust (Shanabrook, 2023). Across these usages, the common substrate is the e-graph: a compact representation of many equivalent expressions, supporting equality saturation and later extraction of a preferred representative (Shanabrook, 2023).

1. Origins and conceptual position

Egglog was introduced to bridge a practical gap between two traditions that were each strong in areas where the other was weak. Modern Datalog engines provide scalable, incremental, relational reasoning, but do not natively offer efficient equivalence reasoning over terms. Equality-saturation systems provide e-graphs, congruence closure, and rewrite-driven optimization, but have been weaker at expressing richer semantic analyses and conditional rewrites inside the same declarative framework. The 2023 egglog paper identifies this mismatch through two motivating applications: a unification-based pointer analysis in Datalog and an EqSat-based floating-point term rewriter, both of which were hampered by features missing from the other camp (Zhang et al., 2023).

The system is described as “essentially a Datalog engine with two main extensions”: a built-in, extensible notion of equality, and built-in support for functions, including a :merge mechanism for repairing functional dependency violations when equivalent inputs would otherwise force conflicting outputs (Zhang et al., 2023). Its central conceptual move is to treat both Datalog and equality saturation as fixpoint systems: Datalog reaches a least fixpoint by repeated rule application over facts, while EqSat reaches saturation by repeated rewrites over an e-graph (Zhang et al., 2023).

A distinct but closely related usage appears in "Egglog Python" (Shanabrook, 2023). There, “Egglog” names the Python-facing way of working with the experimental egg-smol e-graph library rather than a new e-graph algorithm. The paper is explicit that egg-smol is not simply the original egg: it was inspired by egg, but is primarily exposed through a custom s-expression or Lisp-like text language, uses concrete types rather than arbitrary Rust objects through traits, and has built-in support for typing functions and expressions. Max Willsey is quoted as characterizing egg-smol as a “clean slate approach” to shortcomings of egg, with no promise that it will stabilize or merge into egg (Shanabrook, 2023). This distinction is essential because it prevents “Egglog” from being misread as merely a wrapper around the original egg.

2. Fixpoint semantics and execution model

The formal semantics of egglog are given in explicitly fixpoint-theoretic terms. For a Datalog program $p$, the immediate consequence operator is

$$T_p(\mathsf{DB}) = \bigcup_{r \in p} T_r(\mathsf{DB}),$$

and evaluation iterates that operator to the least fixpoint (Zhang et al., 2023). Egglog generalizes this picture to a richer state containing both a database and an equivalence relation. An instance is written as $I = (DB, \equiv)$, where $DB$ is a set of function entries and $\equiv$ is an equivalence relation over uninterpreted and interpreted values, with interpreted constants only equivalent to themselves (Zhang et al., 2023).

Canonicalization is central. The system chooses a representative for each equivalence class and keeps the database canonical with respect to the current equivalence relation. Execution then alternates between an inflationary immediate consequence step and a rebuilding step. The paper defines the full operator as

$F_P = R^\infty \circ T_P^\uparrow,$

and program meaning as

$[\![P]\!] = F_P^\infty(I_\bot),$

where $I_\bot$ is the empty database with identity equivalence (Zhang et al., 2023). Rebuilding closes the equivalence relation under new equalities, canonicalizes entries, and invokes function-specific merge behavior when canonicalization creates output conflicts (Zhang et al., 2023).

This semantics supports a term-centric yet relational execution model. Nested terms are flattened into database entries, rewrites add equal terms rather than destructively replacing old ones, and congruence closure is maintained by union-find over user-defined sorts (Zhang et al., 2023). The result is that joins ordinarily occur over canonical representatives rather than over explicit “join modulo equivalence” encodings, which is one of the main reasons egglog avoids the quadratic behavior that can appear in naive Datalog formulations of equality (Zhang et al., 2023).

Efficiency depends heavily on semi-naive evaluation. Egglog tracks a differential database $\Delta DB_i$ across iterations, rewrites rules into delta rules, rebuilds to restore canonical form, and updates the differential state after each step. The paper states a correctness theorem: semi-naive evaluation of an egglog program produces the same database as naive evaluation (Zhang et al., 2023). This makes the system a fixpoint engine in the Datalog sense while preserving the term-merging behavior characteristic of EqSat.

3. Core language mechanisms and interfaces

At the language level, egglog generalizes relations into partial functions backed by maps; a relation can be understood as a function returning unit (Zhang et al., 2023). The system distinguishes interpreted constants such as integers and strings from uninterpreted constants that serve as ids for user-defined sorts and equivalence classes (Zhang et al., 2023). Functions may have a :default value; for functions returning user-defined sorts, the default behavior can create a fresh id, whereas for base types the default crashes unless otherwise specified (Zhang et al., 2023). The :merge facility is more novel: when two equivalent inputs would force distinct outputs, egglog resolves the conflict by applying a merge expression, which can encode a minimum, a lattice join, or a union over user-defined sorts (Zhang et al., 2023).

Rewriting is integrated directly into this function-and-equality substrate. A rewrite does not delete the old term; instead it adds the new term and unifies it with the old one. This embeds EqSat-style non-destructive search inside a Datalog-like rule language (Zhang et al., 2023). Because analyses are also written as ordinary rules over functions and relations, cooperating analyses and rewrites can share a single runtime rather than being mediated by custom host-language code (Zhang et al., 2023).

The Python interface described in "Egglog Python" is designed to feel familiar to Python developers. It relies on functions, classes, methods, type annotations, operator overloading, decorators, and normal Python control and data definitions; native Python classes and functions are translated into egg-smol sort definitions and function definitions (Shanabrook, 2023). A lower-level module, egg_smol.bindings, exposes Rust primitives directly, and the bindings are created with PyO3 (Shanabrook, 2023).

Typing is not incidental in that interface. Variables in Python are required to be typed because all expressions need a known type so that the library can do static analysis and disambiguate method dispatch (Shanabrook, 2023). This design enables editor and checker support: because classes and decorated functions retain their Python types, the bindings support MyPy and PyLance, and rewrites can be type-checked so that the left-hand side and right-hand side must have the same type (Shanabrook, 2023). The intentionally verbose rewrite(lhs).to(rhs) form exists partly to make that check fit Python’s typing constraints (Shanabrook, 2023).

The interface is also deliberately more opinionated than earlier Python e-graph tools such as snake-egg. Rather than allowing arbitrary Python objects to be mapped into e-graphs, it restricts definitions to provided function and class wrappers, producing a uniform meta-representation that is intended to support rewrites not only within one library but between libraries (Shanabrook, 2023). The paper specifically motivates this with Dask and Ibis, both of which require high-level expression systems with rewrite-based optimization (Shanabrook, 2023). Jupyter notebooks are highlighted as a natural environment for experimentation, teaching, and possible visualization, with auto-completion helping users discover methods relevant to rewrites (Shanabrook, 2023).

4. Applications in optimization, analysis, and proof search

The original egglog paper evaluates the system on a microbenchmark and on the two motivating case studies (Zhang et al., 2023). On an EqSat-style math benchmark, a non-incremental egglog variant was already faster than egg, and with semi-naive evaluation the gap widened; by iteration 100, egglog achieved a reported 9.27× speedup over egg for the larger exploration and 3.34× for the exact same e-graph growth in the non-incremental comparison (Zhang et al., 2023). In the Steensgaard-style pointer analysis case study, egglog reported a 4.96× average speedup over the best sound patched Soufflé encoding, while also simplifying the encoding and fixing bugs found in earlier formulations (Zhang et al., 2023). In the Herbie case study, egglog enabled a sound rewrite system through interval and non-equals analyses; across 289 benchmarks, the egglog-based version took 73.91 minutes versus 81.91 minutes for the original unsound ruleset, and in 104 cases the sound egglog version found a more accurate program (Zhang et al., 2023).

The 2026 JijModeling 2 paper extends this picture into industrial mathematical optimization (Ishii, 18 May 2026). There, the internal representation is based on simply typed $\lambda$-calculus, and egglog is used in two distinct roles. First, it reconstructs human-readable comprehension syntax from higher-order stream terms such as map, flat_map, and filter, then performs equality saturation and extraction with a custom cost model to minimize temporary variable rebindings (Ishii, 18 May 2026). Second, it acts as a declarative engine for constraint detection, replacing an older multi-stage egg-based pipeline with datalog-style rules that infer multi-step patterns such as SOS1 constraints entirely inside egglog (Ishii, 18 May 2026). The paper is explicit that egglog is not only an equality saturation engine in this setting; it is also a declarative fact database and inference engine over symbolic optimization models (Ishii, 18 May 2026). For practical instances with around 50 variables and 30 constraints, the readability-oriented optimization can still take about 5 seconds, while a problematic detection case was improved from minutes or nontermination within an hour to about 3 seconds by ensugaring and splitting a huge rule premise before saturation (Ishii, 18 May 2026).

Egglog has also been used as a proof-search substrate. In "Synthesizing Backward Error Bounds, Backward," the eggshel tool is implemented in egglog to search a syntactic fragment of the category $$T_p(\mathsf{DB}) = \bigcup_{r \in p} T_r(\mathsf{DB}),$$0, whose morphisms encode structured backward-error proofs for floating-point programs (Zielinski et al., 17 Apr 2026). The search space includes algebraic rewrites, context rearrangements, and structural lens constructions such as share and push products, allowing proofs to be synthesized even for programs with variable reuse, a case that standard definitions of backward stability handle poorly (Zielinski et al., 17 Apr 2026). The paper proves soundness of the egglog search relation and reports that many reuse-heavy examples can be handled quickly, often in fractions of a second for the harder cases, though larger instances can run out of memory as equality saturation over context rearrangements grows expensive (Zielinski et al., 17 Apr 2026).

Taken together, these case studies show egglog operating as an optimizer, a declarative inference system, and a proof-search engine, all within the same underlying fixpoint-and-equivalence framework.

5. Extensions, integrations, and active research directions

One line of current work treats egglog as the Datalog side of a larger saturation-and-extraction pipeline. "Answer Set Programming for Egg Extraction and More" argues that exact term extraction from e-graphs is NP-hard because DAG sharing introduces global dependencies: local choices alter the reusability and cost of shared subterms, so tree-cost intuition does not transfer directly to exact DAG extraction (Yang et al., 9 Jun 2026). In that paper, egglog is characterized as computing the equivalence-closed search space as a Datalog least fixpoint, while ASP handles the nonmonotone choice, constraints, and optimization required for extraction (Yang et al., 9 Jun 2026). The practical result is that, with suitable Clingo configuration, ASP encodings become competitive with ILP baselines; asp-td is described as the best balanced method overall, while asp-bu is sometimes slightly better in solution quality on outlier instances but usually slower (Yang et al., 9 Jun 2026). Conceptually, the paper places egglog at the boundary between monotone saturation and global optimization.

A second direction concerns contextual reasoning. "Towards Relational Contextual Equality Saturation" starts from the observation that egg and egglog do not natively support contextual equalities: equalities valid only under a branch condition, a physical property, or the body of a lambda (Hou et al., 16 Jul 2025). The paper surveys explicit ASSUME nodes, contextual subgraph copying, and colored e-graphs, then proposes a set-theoretic model in which contexts form a lattice $$T_p(\mathsf{DB}) = \bigcup_{r \in p} T_r(\mathsf{DB}),$$1 and contextual equality is an order-preserving map $$T_p(\mathsf{DB}) = \bigcup_{r \in p} T_r(\mathsf{DB}),$$2 into the space of equivalence relations on expressions (Hou et al., 16 Jul 2025). The attraction of this model is that a relational implementation could represent a hierarchy of equivalence relations without fully copying the graph for every context. The main difficulty is preserving the monotonic, relational semantics on which egglog relies while hiding representation changes such as shrinking quotient sets (Hou et al., 16 Jul 2025).

A third extension studies bottom-up recursive analysis directly inside egglog. "Folding an e-graph in pure egglog" shows how to implement a general catamorphism without Rust-side custom code by splitting analysis into an ongoing accumulation of e-node results and a final fold over the e-class (Ren et al., 2 Jun 2026). The paper introduces AllAnalyzed, TotalNodes, and NodesDone so that the finalization rule fires only when all relevant e-node analyses have been computed (Ren et al., 2 Jun 2026). This staged-rule trick is presented as a reusable way to avoid re-propagation of stale values, and it exploits two properties emphasized by the authors: memoization comes for free, and subproblems are defined over e-classes rather than over concrete subterms (Ren et al., 2 Jun 2026).

Beyond direct egglog implementations, the broader egglog style has also begun to influence adjacent areas. In symbolic regression, for example, EGG-SR adopts a rewrite-driven, equality-saturation engine over symbolic expressions and is described as “egglog-like” in spirit even though it is not a direct library dependency (Jiang et al., 8 Nov 2025). This suggests a widening conceptual footprint for egglog’s underlying abstractions.

6. Limitations, misconceptions, and open problems

A recurring misconception is that “Egglog” names a single stable artifact. The literature instead uses the term in at least two closely related senses: the core fixpoint reasoning system that unifies Datalog and equality saturation (Zhang et al., 2023), and the Python-facing interface to the experimental egg-smol library (Shanabrook, 2023). The latter is explicitly exploratory. The Python paper states that the work has not yet been tested in production use cases and depends on egg-smol, which is still experimental and may change (Shanabrook, 2023). It also emphasizes that the bindings do not simply wrap egg; they bind a more structured, typed, and text-oriented interface (Shanabrook, 2023).

The Python work lists several concrete open problems. These include embedding existing Python types as leaf nodes in the e-graph, smoothing the pipeline from native Python object to rewritten result and back, validating the approach through an upstream integration with a library such as Ibis, supporting import and export between Python and the s-expression language or another machine-readable format such as JSON, improving module and state management so definitions can be shared across files, and building interactive visualization in Jupyter by introspecting the internal e-graph state (Shanabrook, 2023). The paper’s broader motivation is that a shared standard e-graph library in Python could reduce duplicated maintainer effort and permit cross-library rewrites between systems such as Dask and Ibis (Shanabrook, 2023).

Other research directions expose limitations at the semantic and algorithmic levels. The contextual-equality work identifies a tension between layered equivalence relations and egglog’s monotonic relational model, especially when users might observe representation changes caused by quotient refinement or coarsening (Hou et al., 16 Jul 2025). The ASP extraction work notes that Clingo’s weak-constraint optimization is integer-oriented, so the current encoding does not directly support non-integer costs, and that solver portfolios and multi-threading were explored only lightly (Yang et al., 9 Jun 2026). The pure-fold work presents its counter-based readiness mechanism as a preliminary result and notes that it is sensitive to how egglog is evaluated under the hood (Ren et al., 2 Jun 2026).

These limitations do not diminish the central identity of egglog; rather, they clarify it. Egglog is not merely an e-graph library, nor merely a Datalog engine with a convenience wrapper, but a family of systems and research directions organized around a single idea: equational reasoning, relational fixpoint computation, and extraction or analysis should inhabit the same declarative substrate.