Data quality in 2026: revisit Great Expectations, Soda Core and Elementary before you trust another dashboard number

When a dashboard loads and the chart looks clean, many teams treat the number as truth. The next habit is worse: if finance, sales and product argue about different figures, somebody opens a spreadsheet and “fixes” the number by hand for the meeting. Both habits skip the slower question. Did the rows arrive on time? Did a join quietly duplicate them? Did a null slip into a key column that used to be clean?

Data quality work is not a catalog, a schema migration tool or an orchestrator. Those jobs matter, but they answer different questions. This post revisits three tools that working engineers still meet when they want to check whether warehouse tables deserve the trust dashboards give them: Great Expectations (GX Core), Soda Core, and Elementary. The aim is not to crown a winner. The aim is to help you pick a practical way to catch missing rows, stale loads and broken assumptions before the next review meeting.

The short version

• GX Core (Great Expectations): Apache-2.0 Python library for defining Expectations as tests for data, running validations in your pipelines, and publishing human-readable Data Docs. Fivetran announced stewardship of the open-source community and GX Core project in May 2026. GX Cloud was acquired by FICO and stopped public availability around 1 June 2026. Strong when you want a rich, programmable expectation library inside Python jobs.
• Soda Core: source-available data contracts engine under the Elastic License 2.0 since January 2026 (it was Apache-2.0 before). Version 4 replaced the older checks language with YAML data contracts. Strong when you want contract-style rules beside tables and are fine with ELv2 for internal use.
• Elementary: Apache-2.0 OSS CLI and dbt package that sits on top of dbt tests, run results and artifacts, with a self-hosted observability report. Elementary Cloud is the commercial managed product. Strong when your warehouse work already lives in dbt and you want freshness, volume and test visibility without inventing a second stack.

What the data quality job actually is

Before comparing tools, separate three jobs that sales decks often mix together.

• Validation answers “does this batch meet the rules we wrote”. Rules can be “row count above N”, “order_id is unique”, “status is in this set”, or “freshness within two hours”. You run them in a pipeline and fail or warn when they break.
• Observability answers “is the system drifting”. It looks at history of volume, freshness, null rates and test failures, and alerts when something unusual appears, not only when a hard rule fails.
• Contracts answer “what does this table promise to consumers”. A contract is a shared definition of schema and quality guarantees that producers and consumers can both execute.

None of these replaces lineage catalogs such as OpenMetadata or DataHub, schema migration tools such as Atlas, Flyway or Liquibase, or orchestrators such as Airflow, Prefect or Dagster. A dashboard that loads only proves that a query returned. It does not prove the query was fed trustworthy rows.

A small Indian SaaS example helps. Imagine a Bengaluru billing product that loads nightly orders into a warehouse mart used by a Jaipur finance team. Last Tuesday the mart row count looked “about right”, so the revenue dashboard went green. On Wednesday finance noticed that refunds had doubled in the chart. The root cause was a late upstream change that duplicated refund lines after a join. The dashboard did its job. The warehouse did not. A few checks on uniqueness, freshness and row-count bands would have failed the load before the chart went live.

Great Expectations (GX Core): Expectations as tests for data

History and licence. Great Expectations grew as a community project for data quality. The open-source library is commonly called GX Core. The code lives at fivetran/great_expectations (the older great-expectations/great_expectations path redirects there) under the Apache License 2.0.

Two corporate moves in May 2026 reshaped the project map. On 6 May 2026, Great Expectations published a community update stating that Fair Isaac Corporation (FICO) had completed a definitive agreement to acquire GX Cloud, and that GX Cloud would no longer be publicly available beginning 1 June 2026. The same update said Fivetran would become steward of the open-source community and the GX Core project. Fivetran’s press release on 13 May 2026 confirmed that planned stewardship: GX Core continues as an open-source, community-driven project, with Fivetran intending to support maintenance, ecosystem integrations and community engagement. Treat GX Cloud history as closed for new public users, and treat GX Core as the open path that still ships.

How it works. GX Core is a Python library. You install it with pip install great_expectations, create a Data Context, connect to data (pandas, SQL engines, Spark and others), define Expectations, and validate Batches. Expectations are the heart of the model: expressive checks such as expecting a column between two values, uniqueness, set membership or regex matches. You group them into Expectation Suites, tie suites to data through Validation Definitions, and run Checkpoints that produce Validation Results. GX can render those results as Data Docs, which are HTML reports people can read without opening a notebook. The official docs list Python 3.10 through 3.14 for current GX Core.

At the time of writing, the latest release on GitHub is 1.24.1 (22 October 2026).

Where it is strong.

• Teams that already live in Python pipelines and want unit-test style language for data.
• Organisations that need a large gallery of Expectations and the option to write custom ones.
• Groups that value Data Docs as a shared artefact for analysts and engineers.

What to watch.

• GX Core is powerful and can feel heavy for a two-person team that only needs five freshness checks.
• After the FICO and Fivetran moves, do not assume GX Cloud docs or sign-up flows still apply; start from GX Core docs and the Fivetran-hosted repository.
• Expectation sprawl is real. Without owners and severity levels, suites become noise that people ignore.

Soda Core: data contracts as the default engine

History and licence. Soda Core is the engine behind Soda’s data quality product line. The repository is sodadata/soda-core. On 27 January 2026, Soda published a licence update: Soda Core moved from the Apache License 2.0 to the Elastic License 2.0 (ELv2). In Soda’s own words, the software remains source-available and free for internal use in your organisation, including production, as long as you do not offer it to third parties as a hosted or managed service that exposes a substantial set of Soda Core features. You may still read, modify and fork the code and offer consulting or training around it. The restriction is about competing managed offerings, not about running checks on your own warehouse.

How it works. Version 4 is a breaking change. Soda’s 4.0 announcement and the Core release notes for soda-core 4.0.5 (28 January 2026, first public release of version 4) state that Data Contracts become the default way to define data quality for tables, replacing the older checks language (often called SodaCL). A contract is YAML that can carry schema and quality checks together. You verify contracts locally or remotely, including through Soda Cloud when you use it. The engine supports many SQL warehouses and lake engines; the v4 notes list sources such as Postgres, Snowflake, BigQuery, Databricks, Redshift, SQL Server, Fabric, Synapse, Athena and DuckDB, with more added in later releases. Soda Cloud is the commercial companion for collaboration, diagnostics and managed workflows. Label product claims about AI-generated checks or self-driving platforms as the vendor’s own.

At the time of writing, the latest release on GitHub is v4.30.0 (5 November 2026).

Where it is strong.

• Teams that want readable YAML contracts next to table ownership, not only Python in a library.
• Data platform groups that already talk about producer and consumer contracts and want those contracts to execute.
• Organisations that can accept ELv2 for internal production use and do not plan to resell a hosted Soda Core service.

What to watch.

• ELv2 is not Apache-2.0. Legal and procurement teams should read the licence before you embed Soda Core in a product you sell as a service.
• Moving from v3 checks to v4 contracts is a migration, not a flag flip. Plan conversion time for existing check files.
• Soda Cloud features are commercial; do not confuse Core capabilities with Cloud screenshots.

Elementary: dbt-native observability and tests

History and licence. Elementary focuses on data observability around the modern warehouse stack, with a strong dbt centre of gravity. The open-source pieces are an Apache-2.0 dbt package (elementary-data/dbt-data-reliability, published as elementary-data/elementary) and an Apache-2.0 CLI (elementary-data/elementary). Elementary’s own docs split the offering clearly: Elementary OSS is the self-hosted CLI plus dbt package for a single dbt project; Elementary Cloud is the commercial managed platform with wider stack coverage and extra features.

How it works. For OSS, you add the Elementary package to packages.yml, configure an elementary schema in dbt_project.yml, run dbt deps and dbt run --select elementary, then keep running your normal dbt test / dbt build flow. The package stores test results, run results and artifacts in Elementary tables. The CLI (edr) reads that metadata and can produce the self-hosted observability report, plus basic alerting integrations documented upstream. OSS coverage, in Elementary’s comparison docs, includes dbt test results, table-level lineage, test coverage views and basic alerts. Freshness and volume anomaly tests are part of the OSS story; richer ML anomaly detection, column-level lineage to BI, multi-project coverage and governance features sit on the Cloud side. Cloud can connect to a warehouse directly and does not require dbt, though dbt remains a common integration. Treat Cloud AI-agent claims as the vendor’s own.

At the time of writing, the latest CLI and dbt package releases checked for this post are both v0.26.1 (11 October 2026).

Where it is strong.

• Teams whose transforms and tests already live in dbt and who want observability without a second quality DSL on day one.
• Groups that want a report stakeholders can open after each run, built from the tests they already wrote.
• Organisations that prefer Apache-2.0 for the self-hosted path and can evaluate Cloud later if they outgrow one project.

What to watch.

• Elementary OSS assumes a dbt project. If you have no dbt, look at GX Core or Soda Core first, or evaluate Elementary Cloud on its own terms.
• OSS is scoped to a single dbt project in the vendor comparison. Multi-project estates need a clear ownership model or Cloud.
• Anomaly tests still need enough history and stable schedules. A noisy hourly job will teach any tool bad baselines.

Side by side, without a table

Primary job

• GX Core: programmable Expectations and validations inside Python data pipelines, with Data Docs.
• Soda Core: executable YAML data contracts for schema and quality checks across warehouses.
• Elementary OSS: dbt-native collection of tests, runs and artifacts, plus a self-hosted observability report.

Licence (as stated upstream)

• GX Core: Apache-2.0; open-source stewardship planned under Fivetran (announced May 2026).
• Soda Core: Elastic License 2.0 since January 2026; was Apache-2.0 before. Free for internal use with ELv2 limits on offering it as a competing hosted service.
• Elementary OSS (CLI and dbt package): Apache-2.0. Elementary Cloud: commercial.

Latest releases checked for this post (November 2026)

• GX Core: 1.24.1 (22 October 2026).
• Soda Core: v4.30.0 (5 November 2026).
• Elementary CLI and dbt package: v0.26.1 (11 October 2026).

Best fit shape

• GX Core: Python-first pipelines, custom Expectations, Data Docs as the shared report.
• Soda Core: contract-first YAML beside tables, multi-warehouse CLI verification, ELv2-acceptable internal use.
• Elementary OSS: dbt already in place, reuse dbt tests, add freshness or volume monitors and a run report.

Cloud companion

• GX: GX Cloud public availability ended around 1 June 2026 after the FICO acquisition; do not plan new work on it.
• Soda: Soda Cloud is the commercial platform beside Core.
• Elementary: Elementary Cloud is the commercial managed platform beside OSS.

We did not run install drills or benchmarks for this post. Use the official guides on a non-production warehouse or clone before you fail a production load on a new check.

A practical way to start this week

For an Indian data or analytics engineering team that is about to trust another dashboard number, a calm sequence looks like this:

1. Write down the real pain: late facts, duplicate keys, nulls in join columns, or a chart that disagrees with the operational database.
2. List five critical tables or marts. For each, name the owner, the freshness promise, and one uniqueness or row-count rule in plain language.
3. If the team already runs dbt, add Elementary OSS on a staging target: install the dbt package, run the elementary models, keep existing tests, and generate the report after a few runs.
4. If the team lives in Python jobs without dbt, start with GX Core on one pandas or SQL batch: three Expectations, one Checkpoint, Data Docs linked from the pipeline failure message.
5. If the team wants contracts that non-Python owners can read, trial Soda Core v4 on one Postgres or Snowflake table: one YAML contract with schema plus missing, duplicate and freshness-style checks, verified in CI.
6. Wire failures to the same place you already watch (Slack, Teams, pager, CI). A check nobody sees is decoration.
7. For one week, fix only the failures on those five tables. Do not expand the rule set until owners respond.
8. Only then decide whether you need a commercial cloud product for collaboration, multi-project views or managed anomaly detection.

How to choose

• If dbt is already your centre of gravity, start with Elementary OSS and the tests you already have.
• If Python pipelines own the loads and you want a large expectation library plus Data Docs, start with GX Core.
• If you want YAML data contracts and your counsel is comfortable with ELv2 for internal use, evaluate Soda Core v4.
• If someone proposes buying a dashboard “data reliability” suite before any checks exist on the five critical tables, pause. Buy after the first week of failing checks has an owner.
• Do not run GX, Soda and Elementary on the same tables for months without a clear split of duties. Pick one system of record for “this table is fit for the dashboard”.

Revisit checklist

• Which five tables would embarrass us if they were wrong in tomorrow’s leadership review?
• Do those tables have named owners, freshness promises and at least one uniqueness or volume check?
• Are we confusing a catalog, a migration tool or an orchestrator with data quality checks?
• For GX: are we on GX Core under the current repository and docs, not on retired GX Cloud assumptions?
• For Soda: have we read ELv2, and have we budgeted migration from v3 checks to v4 contracts if needed?
• For Elementary: is dbt actually how we build these marts, and is OSS enough for one project?
• When a check fails, who is paged, and who is allowed to mark it as accepted risk?
• Does the dashboard deployment wait on quality gates, or can a green chart ship on a red load?

Closing

Trusting a dashboard because it loaded is a habit worth unlearning. Revisit data quality with the mindset that fits this site: learn what validation, observability and contracts each cover, unlearn the idea that a chart equals truth, re-learn ownership of a few critical tables, practise with GX Core, Soda Core or Elementary on a staging path, and apply a commercial cloud product only where the open tools leave a clear gap.

Sources

• GX Core repository (Fivetran stewardship host): https://github.com/fivetran/great_expectations
• GX Core releases (1.24.1): https://github.com/fivetran/great_expectations/releases
• GX Core try / introduction docs: https://docs.greatexpectations.io/docs/core/introduction/try_gx
• Great Expectations community update (FICO acquires GX Cloud; Fivetran steward for GX Core; 6 May 2026): https://greatexpectations.io/blog/an-update-from-great-expectations/
• Fivetran press release on GX Core stewardship (13 May 2026): https://www.fivetran.com/press/fivetran-to-become-steward-of-the-great-expectations-open-source-community-and-gx-core-project
• Soda Core repository: https://github.com/sodadata/soda-core
• Soda Core releases (v4.30.0): https://github.com/sodadata/soda-core/releases
• Soda Core licence update to Elastic License 2.0 (27 January 2026): https://soda.io/blog/soda-core-license-update-moving-to-elastic-license
• Soda 4.0 announcement (data contracts): https://soda.io/blog/introducing-soda-4.0
• Soda Core release notes (4.0.5 first public v4, 28 January 2026): https://docs.soda.io/release-notes/soda-core
• Elastic License 2.0 text: https://www.elastic.co/licensing/elastic-license
• Elementary CLI repository: https://github.com/elementary-data/elementary
• Elementary CLI releases (v0.26.1): https://github.com/elementary-data/elementary/releases
• Elementary dbt package repository: https://github.com/elementary-data/dbt-data-reliability
• Elementary dbt package releases (0.26.1): https://github.com/elementary-data/dbt-data-reliability/releases
• Elementary OSS vs Cloud: https://docs.elementary-data.com/cloud/cloud-vs-oss
• Elementary dbt package quickstart: https://docs.elementary-data.com/oss/quickstart/quickstart-cli-package