Data Stack Index / v 02.06
Verified 2026·05·08
Send a correction
Quality & testing · primary SaaS · Self-hosted Open source acquired

Great Expectations.

Great Expectations
Founded 2017
Status · ● acquired
Verified · ● 2mo ago

Python-native data validation framework — the OSS standard, now in stewardship transition after the May 2026 acquisition.

Capability profile Quality 3/3 primary Catalog 0/3 Lineage 0/3
Annual cost
Free open source · self-hosted
Deployment SaaS · Self-hosted
License Open source
Free tier GX Core is free under Apache-2.0 with no limits. GX Cloud Developer tier was free but is being discontinued 2026-06-01.
dbt integration None
Persona data engineer · analytics engineer
Company size startup → scaleup → mid market → enterprise
Warehouses snowflake · bigquery · redshift · databricks +4
OpenLineage none
01
Verdict

Where it fits — and where it doesn't.

● Ideal for

Python-first data engineering teams who treat data quality as a software engineering problem and want their tests to live in the same repository, version control, and CI as their pipeline code.

GX Core remains the most mature OSS data-validation framework — Apache-2.0, deeply embedded in Airflow, Dagster, and Prefect operators, and supported by roughly 300 built-in Expectations covering schema, value distribution, statistical, and multi-column relationships. Particularly well-suited to healthcare, financial-services, and other regulated buyers who need pure-OSS, on-prem deployment with no SaaS dependency, since the project is permissive Apache-2.0 with no copyleft or relicensing risk.

○ Avoid if

You want a managed product with a roadmap you can rely on through 2027 — the May 2026 acquisition and GX Cloud sunset make that bet very speculative until the new stewards are named and a roadmap is published.

Avoid if your team is dbt-native: GX has never had a serious dbt integration, and Expectation suites live in a separate Python world from dbt models. Avoid also if you want ML-driven anomaly detection on production tables — GX is assertion-based; every check has to be written, and nothing surfaces patterns you didn't think to test.

02
Strengths & weaknesses

The honest scorecard.

  • [+] Largest open-source data-validation community by stars and contributors, with deep first-party Airflow, Dagster, and Prefect operator support
  • [+] Apache-2.0 license with permissive reuse — no source-available games, no rug-pull risk on the OSS path
  • [+] Roughly 300 built-in Expectations cover schema, distribution, statistical, and multi-column relationships — the broadest assertion library in the cluster
  • [+] Data Docs auto-generate human-readable validation results that non-engineering stakeholders can actually read
  • [+] Python-native by design — Expectations are first-class objects, suites version-control cleanly, and CI integration is a few lines of code
  • [−] The May 2026 acquisition set a hard GX Cloud shutdown date of June 1, 2026 — managed-product customers are left without a migration path on the hosted offering
  • [−] No dbt integration in any meaningful sense — Expectations are not dbt tests, suites live outside the dbt project, and the two paradigms don't compose
  • [−] No ML-based anomaly detection on production tables — every check has to be written; nothing surfaces failures you didn't anticipate
  • [−] Configuration verbosity is a long-standing reviewer complaint — even simple validation requires Data Context, Data Source, Data Asset, Batch Definition, Suite, Validation Definition, and Checkpoint
  • [−] No native lineage, catalog, or incident-management surface — the product is a validation library, not a platform
03
Editorial

What Great Expectations actually is.

What Great Expectations actually is

GX Core is a Python framework for declarative data validation: you author Expectations — assertions like expect_column_values_to_be_unique, expect_table_row_count_to_be_between, or custom SQL checks — bundle them into Suites, run them via Checkpoints, and surface results as auto-generated Data Docs for non-engineering reviewers. It runs anywhere Python runs: in CI, in an Airflow DAG, on a notebook, against any SQLAlchemy-supported backend.

The product around it has been less stable than the framework. The hosted GX Cloud, launched to monetize the project, is being shut down as a result of the May 2026 acquisition. GX Core itself, Apache-2.0, is the durable artifact that anyone evaluating today should plan around.

Where it fits against the alternatives

The clearest comparison is to soda. Both are code-first, both author quality checks in declarative artifacts (GX in Python, Soda in YAML/SodaCL), both run in CI and Airflow. The OSS license is the sharpest split: GX Core is Apache-2.0, Soda Core is Elastic License 2.0 (source-available, not OSS). For buyers who specifically want pure OSS, that’s the deciding factor.

Against datafold, GX is the validation-library answer to Datafold’s pre-merge-diff-and-lineage answer. They solve different halves of the problem — GX checks what is true about this table, Datafold checks what changes if I merge this PR — and mature teams not infrequently run both.

Against monte-carlo, bigeye, and anomalo, GX is the assertion-based counterpoint to ML-anomaly-detection. GX catches what you write tests for; the ML tools catch what you didn’t think to test. Different tools, different jobs.

On the May 2026 acquisition

On 2026-05-06 the project published a community update announcing that “GX has been acquired” and that GX Cloud would be discontinued effective June 1, 2026. The acquirer was not named in the announcement; the team committed to introducing “the new stewards” later. This is the dominant fact for any buyer evaluating Great Expectations in mid-to-late 2026.

What it means in practice: GX Core, as Apache-2.0, cannot be killed — the code, contributors, and ecosystem all persist independent of any single corporate sponsor. But the trajectory of the framework — release cadence, feature priorities, supported backends — depends on whoever is now stewarding it. Until that’s public, it is rational to be cautious about new commitments to GX-managed surfaces and to plan around the OSS path.

How to evaluate it

If you’re considering GX Core (the OSS path), the honest test is to write Expectations for a non-trivial table in your warehouse, wire the Checkpoint into your existing CI or orchestrator, and see how the configuration shape feels for your team. Expect the boilerplate burden — Data Context, Data Source, Data Asset, Batch Definition, Suite, Validation Definition, Checkpoint — to be the friction point.

If you’re considering GX Cloud, don’t — it has a sunset date.

04
Capability spec

All capabilities by cluster.

Quality & testing

Primary · strength 3/3
01 dbt-native — not supported
02 ML anomaly detection — not supported
03 Assertion-based testing
04 Pre-merge diffing — not supported
05 Schema drift detection
06 Freshness monitoring — not supported
07 Volume monitoring
08 Custom SQL checks
09 Circuit breaker
10 Data contracts — not supported
11 Column profiling
12 Runs in CI
13 Root cause analysis — not supported
14 Incident management — not supported
Test authoring python
Paradigm assertion based
Monitors at warehouse table · warehouse column · file object
Alerting slack · email · webhook · pagerduty · opsgenie · teams
05
Warehouses & integrations

Where it plugs in.

Native warehouse support

snowflakebigqueryredshiftdatabrickspostgresmysqlmssqlfabric

Orchestrators & pipeline tools

airflowdagsterprefect
01dbt — None
02Airflow — Native
03OpenLineage — none
04API access — full
05Terraform provider
06Public SDK — python
06
Pricing

The honest pricing breakdown.

Pricing model open core
Charged per custom
Published ○ Contact sales required
Free tier ● Yes
OSS self-host ● Available

Free tier GX Core is free under Apache-2.0 with no limits. GX Cloud Developer tier was free but is being discontinued 2026-06-01.

Sales-only tier GX Cloud paid Team and Enterprise tiers are being discontinued 2026-06-01 following acquisition; OSS Core is the only continuing path pending the new stewards' commercial roadmap

Full Great Expectations pricing breakdown — model, cost factors, alternatives by price →

07
Notable missing

What it doesn't do.

ML Anomaly Detection →

Uses machine learning models trained on historical data to detect values, volumes, or distributions outside expected bounds — without requiring the user to write explicit assertions. Reduces the "I didn't know to test for that" class of incident. Trade-off: requires a training window (typically two to four weeks), can produce false positives on seasonal data, and doesn't replace assertions for business-rule validation.

dbt-Native Testing →

Runs as part of the dbt execution context — as a package, post-hook, or artifact consumer — rather than monitoring the warehouse from the outside. Tests are defined in the same codebase as models, run on the same schedule, and fail the same CI pipeline. The alternative is warehouse-side monitoring (Monte Carlo-style) which catches issues dbt misses but reacts rather than prevents.

OpenLineage-Native →

Emits and consumes OpenLineage events as a first-class citizen rather than via a plugin or adapter. Signals commitment to interoperability with other metadata tooling — Marquez, OpenMetadata, Astronomer, and others can consume the same event stream. Increasingly the differentiator between "open" and "proprietary metadata model" observability platforms.

Column-Level Lineage →

Traces data flow at the individual column granularity rather than just between tables. Critical for impact analysis when a column changes, for PII tracking, and for regulatory compliance in financial or healthcare contexts. Column-level lineage is computationally expensive and not all tools that claim "lineage" actually provide it — many stop at table level.

08
Strong at

Drill into one capability.

09
Alternatives & migrations

If not Great Expectations, then what?

Common alternatives

Soda → SodaCL is one of the cleaner data-quality DSLs — readable, version-controllable, and expressive enough for both simple assertions and ML thresholds ↔ Great Expectations vs Soda
Datafold → Pre-merge data diffing is genuinely category-defining; no competitor does this as well ↔ Great Expectations vs Datafold
Elementary → Fully open-source core is genuinely production-grade, not a trial ramp to a paid tier ↔ Great Expectations vs Elementary
Anomalo → ML anomaly detection has a strong reviewer reputation in the cluster — Anomalo's profiling engine is purpose-built for petabyte-scale tables with minimal manual configuration ↔ Great Expectations vs Anomalo

Teams typically migrate to

See all 9 Great Expectations alternatives, scored and compared →
10
Common questions

Quick answers.

Is Great Expectations open source?
Yes. Great Expectations is open source under the Apache-2.0 license, and can be self-hosted at no license cost.
How much does Great Expectations cost?
Great Expectations does not publish list pricing — it is sales-led, so you request a quote. A free tier is available: GX Core is free under Apache-2.0 with no limits. GX Cloud Developer tier was free but is being discontinued 2026-06-01.
How is Great Expectations deployed?
Great Expectations can run as managed SaaS or be self-hosted.
Does Great Expectations work with dbt and my warehouse?
It has no dedicated dbt integration. Great Expectations supports snowflake, bigquery, redshift, databricks, postgres, plus 3 more.

More quality & testing tools

Provenance.

Last verified 2026·05·08 against vendor documentation and, where possible, hands-on trial. Spot something off? Send a correction →

No paid placementNo vendor submissionsRankings never for sale Independence policy →