Coral translates SQL dialects through a shared intermediate representation

Coral IR sits between dialects instead of translating them pairwise

Most SQL portability work is done by writing pairs of translators, one for every combination of source and target engine, and the number of pairs grows faster than the number of engines. Coral takes the other route. The project establishes a standard intermediate representation, Coral IR, which captures the semantics of relational algebraic expressions independently of any SQL dialect. SQL from one engine is parsed into that representation, transformed there, and emitted in the target dialect. The project description calls Coral a translation, analysis and query rewrite engine for SQL and other relational languages, and the README stresses the practical payoff: with multiple dialects supported, the same SQL statements and views can be translated from one dialect to an equivalent one, which also lets engines and SQL powered data sources interoperate. The value of this design is not speed but reach. A new dialect needs one parser and one emitter rather than a translation layer for every other dialect, and the same rewrite machinery then applies to all of them.

Coral IR exists in two isomorphic forms, AST and logical plan

Coral IR is defined in two forms, and the distinction matters for anyone extending the engine. One form sits at the abstract syntax tree layer, the other at the logical plan layer, and the two are isomorphic and convertible to each other. In plain terms, the tree form keeps the shape of the query as written, while the logical plan form is the relational algebra the engine will actually reason about, with relational expressions such as joins and filters expressed in a form that can be inspected and rewritten. The rewrite APIs operate on Coral IR expressions, and the project describes the purpose as producing semantically equivalent but more performant expressions. Other stated rewrite applications include data governance and policy enforcement, which is the same mechanism pointed in a different direction: instead of making a query cheaper to run, the plan is edited to satisfy a rule. Two forms that convert to each other give you a choice about when to make a change.

Dialect support is asymmetric, and the gaps are stated in the module list

The module list is the honest place to look, because the direction of support is not even. Coral-Hive parses HiveQL, and since Spark SQL is largely Hive compatible, that parser covers Spark SQL too. Coral-Spark generates Spark SQL from Coral IR, typically output that is also valid HiveQL. Coral-Trino generates Trino SQL from Coral IR, but parsing Trino SQL into Coral IR is listed as in progress. Coral-Dbt applies Coral transformations to dbt models, so the engine can be slotted into an existing dbt pipeline rather than run beside it. Two further modules are explicitly marked WIP: Coral-Spark-Plan, which converts Spark plan strings into an equivalent logical plan, and Coral-Benchmark, a cross dialect translation correctness framework that verifies translations through IR round trips, target engine EXPLAIN and result set comparison against real engines. The limits are concrete. If your source of truth is Trino SQL, the parser you need is unfinished, and if your goal is proving that a translation is correct, the framework designed to do that is also unfinished.

Incremental view maintenance is a rewrite, not a separate system

The Coral-Incremental module rewrites a query into an incremental form for view maintenance, and the project presents this as the flagship rewrite application: Coral automates incremental view maintenance by rewriting a view definition to an incremental one. The approach is worth understanding as a design decision rather than a feature name. Rather than asking a separate scheduler to diff tables and replay changes, the engine reuses its own parser and emitter to produce a new view definition that computes the same result incrementally. Because the rewrite happens on Coral IR, the same transformation can target different output dialects, and the dbt module can apply it to models rather than to raw SQL. Related pieces fit around that idea. Coral-Schema derives the Avro schema of a view from its logical plan and the Avro schemas of its base tables, so a rewritten view still has a defined contract for downstream consumers. A talk listed in the resources section covers Coral and Iceberg for advanced incremental view maintenance, which suggests the intended deployment shape is a lakehouse table format with a maintained view on top.

Building Coral needs Java 8 and Python 3 on the machine

The build documentation is short and specific. You clone the repository first:

git clone https://github.com/linkedin/coral.git

The project then warns that it requires Python 3 and Java 8 to run, and asks you to set JAVA_HOME to the home of an appropriate version before building:

./gradlew clean build

If you would rather not touch your environment variable, the same build is expressed with the org.gradle.java.home gradle property pointing at the Java home you want:

./gradlew -Dorg.gradle.java.home=/path/to/java/home clean build

The Gradle wrapper is checked into the repository, so no separate Gradle installation is needed. Note the version constraint: the documented requirement is Java 8, which means a team running a modern JDK needs to point the wrapper at an older Java home rather than assume the newest runtime works. A first useful step after a successful build is to point the REST service at a HiveQL or Spark SQL view and inspect the rewritten output, because the translation and the rewrite are the two things this project exists to do. The documentation does not describe a distribution package or a published artifact, so a build from source is the path it documents.

Coral ships as a library, a REST service and a visualizer

Coral can be used as a library inside other projects, or as a service, and the service route is handled by the Coral-Service module, which exposes Coral over REST APIs. For teams that do not want to embed a Java library in every caller, a service boundary is the more practical shape, and the rewriting work does not change when it runs behind HTTP. Two smaller modules extend the reach. Coral-Visualization renders Coral SqlNode and RelNode trees to an image, which matters because the plan and the tree are separate views of the same query and a picture is often faster to reason about than a Java object graph. Coral-Pig appears in the top level directory listing of the repository, and the source tree also includes a coral-spark-catalog module alongside the named dialect modules, a coral-common module, a coral-data-generation module and a shading directory that holds the packaged artifacts. A Slack community link is offered in the README for discussion with other users, and contributions are invited under a separate Contribution Agreement document.

Version numbers carry the migration cost, and the licence is permissive

The project describes its versioning scheme in terms of what breaks rather than what is added, which is a useful warning. It adheres to semantic versioning, where the format x.y.z represents major, minor and patch version upgrades, and it asks integrators to consider the changes required when integrating different versions. A major version upgrade introduces backward incompatibility by removal or renaming of classes. A minor version upgrade introduces backward incompatibility by removal or renaming of methods. So a patch release is the only tier that promises compatibility, and anyone embedding Coral as a library should plan for a code change on a minor bump, not just a major one. The licence field on the repository says BSD-2-Clause, which is permissive, but the repository also carries a NOTICE file, and the top level includes a NOTICE alongside the LICENSE, so distribution terms deserve a look before you redistribute anything. On maintenance, the repository is not archived and the last push was on 2026-10-01, with releases v2.5.11 on 2026-10-01, v2.5.10 on 2026-09-22 and v2.5.9 on 2026-09-04.

Where Coral is the wrong tool

Several realistic situations point away from this project. A team with one SQL engine and no dialect spread gets nothing from an intermediate representation, and adds a build, a Java dependency and a service boundary for no translation problem to solve. A team whose queries are written in Trino SQL hits the unfinished parser, and there is no documented workaround in the project beyond writing the view in HiveQL or Spark SQL first. A team that needs proof that every translation preserves semantics hits the second WIP module, since the benchmark framework that would compare result sets against real engines is not finished. Workloads that need a general purpose query optimizer rather than a dialect and rewrite layer are also a mismatch, because the stated rewrite targets are specific: incremental view maintenance, data governance and policy enforcement. And anyone who wants a self contained SQL dialect validator, a linter or a query formatter should look elsewhere, since that is not what the AST and logical plan layers are offered for.

Editorial conclusion

Coral is worth adopting when your estate mixes HiveQL, Spark SQL and Trino and you need the same view definition to exist in more than one dialect, or when you want a view rewritten into an incremental form. It is the wrong choice for a single-dialect workload, for anyone who needs Trino SQL parsed into Coral IR, or for a team unwilling to track major and minor version changes, since the project states that a major release can remove or rename classes and a minor release can remove or rename methods. Before adopting, check the Trino parsing status in the coral-trino module, confirm your Java 8 and Python 3 toolchain matches the build, and read the release notes attached to the v2.5.x line before upgrading.

Frequently asked questions

Official sources

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