Dataobservability
Blog / Tooling 7 min read

Great Expectations in 2026: What Happened to GX Cloud

August 2026 · Dataobservability

SNOWFLAKE · PROD
247 tables |
Break a monitor:

Alerted #data-eng 0.8s ago.

Downstream impact · consumers at risk

INCIDENT #1042 OPEN · owner @you

Live console · pick a break, watch it get caught

Two separate things happened to Great Expectations in 2026 and they point in opposite directions, which is why the answer you get depends on who you ask. GX Cloud, the commercial hosted product, was acquired by FICO to become the foundation of its next generation data quality capability, and it stopped being publicly available on June 1, 2026. GX Core, the open source Python library, is alive: Fivetran became steward of the project and the community in May 2026, it remains Apache-2.0, and version 1.20.0 is the current release on PyPI. So Great Expectations is still maintained, and the managed version you could buy is gone.

That distinction decides what you should do next, and most comparison content written before this summer gets it wrong in both directions. Some articles still recommend GX Cloud as the easy on-ramp. Others have written the whole project off as abandoned. Neither is true.

What changed, exactly

WhatStatus as of August 2026
GX Core (the Python library)Open source, Apache-2.0, actively released. Current version 1.20.0, supporting Python 3.10 through 3.13.
Who maintains GX CoreCommunity driven, with Fivetran as steward since May 2026, supporting maintenance, ecosystem integrations, and community engagement.
GX Cloud (the hosted product)Acquired by FICO. No longer publicly available beginning June 1, 2026.
What a new buyer can adoptGX Core, self hosted, only. There is no managed Great Expectations to purchase.

Read the last row carefully, because it is the one with a budget attached. If your plan was to let analysts define checks in a UI while engineers stayed out of the loop, that plan needs replacing. The library is a Python API, and it always was.

Is Great Expectations still safe to build on?

Yes, with a caveat worth stating plainly. The signals of project health are good: an active release cadence, a permissive license that cannot be revoked, a corporate steward with an obvious commercial interest in data quality tooling continuing to exist, and one of the largest installed bases of any data validation framework. Apache-2.0 also means the code you are running today stays yours to run regardless of what any company decides later, which is the entire practical argument for open source in a stack you depend on.

The caveat is that stewardship is not the same as a product roadmap. Fivetran has committed to maintenance, integrations, and community, which is meaningful and is not a promise that the library grows in whatever direction your team needs. If your evaluation assumed a vendor would build the missing pieces for you, adjust it. With GX Core you own the missing pieces.

What you actually lose without GX Cloud

The library validates data. That is the whole job, and it is worth being specific about everything the hosted product was doing around it that you now do yourself:

  • A place for it to run. Validation needs compute and a scheduler, usually Airflow or an equivalent, plus someone to keep those jobs healthy.
  • Somewhere to put results. A validation run produces output. Deciding where that lives and how it is queried is your design decision now.
  • Alerting. GX Core does not page anyone. A failing Expectation is a result object, not a Slack message, until you build the path between them.
  • A UI for non engineers. Expectations are written in Python and reviewed in pull requests. That is a feature for engineering teams and a blocker for analyst led teams.
  • Suite maintenance. Expectations describe the data as it was when you wrote them. Tables change, and a suite that is no longer accurate passes cleanly while telling you nothing, which is worse than no tests because it feels like coverage.

None of this is a criticism of the project. A library should be a library. But teams that adopt GX Core to save money routinely underestimate the operational surface, and the infrastructure alone is enough of a lift that many end up standing up dedicated scheduling and server provisioning and deployment automation just to keep validation jobs running reliably. Count those hours before you count the license, because the license is the only part that is free.

The gap nothing in Great Expectations ever filled

There is a more fundamental limit that has nothing to do with the FICO deal, and it is the reason many teams were already looking elsewhere. An Expectation only fires on a table you configured, for a rule you wrote, when you scheduled a run. That structure catches the failures somebody anticipated. It cannot catch:

  • A table that silently stopped refreshing at 2pm, hours after your 6am validation run passed.
  • A vendor sync that paused over a holiday weekend, touching no code and violating no assertion.
  • A distribution sliding two percent a week, where every day looks fine next to the day before and no static range ever trips.
  • Anything at all on the tables nobody wrote Expectations for, which in most warehouses is the large majority of them.

That last one is the quiet killer. A validation suite reports zero failures on a table it has never heard of, and zero failures is indistinguishable from healthy on a dashboard. This is the structural difference between testing and monitoring, and it is why the two layers coexist in mature stacks rather than replacing each other. Testing asserts what you know. Monitoring learns what normal looks like and tells you when reality departs from it, on every table, continuously, without anyone writing a rule.

Three honest paths from here

Stay on GX Core and self host. Right if you have Python engineers, a working orchestrator, and specific business rules you can state precisely, such as an order total equaling the sum of its line items. No statistical system infers logic like that, and no monitoring tool should try. Cost is zero in license and real in engineering time.

Buy an enterprise observability platform. Right if you have a large estate, governance requirements, and procurement. Monte Carlo is the category leader here; its public AWS Marketplace listing shows a 12 month contract at 50,000 dollars, which sets the order of magnitude even though the company publishes no pricing on its own site. We break the tradeoff down in detail in Great Expectations vs Monte Carlo.

Buy a self serve platform that publishes its price. Right if your actual problem is that data breaks and you find out from a stakeholder, and you cannot sign a five figure contract to fix it. This is the middle ground the first two options leave empty, and it is unusually hard to shop for because only three of the thirteen tools data teams commonly compare publish a price at all.

Whichever path you take, the evaluation question is the same one that trips people up on feature grids: how much coverage do you get before anyone writes a rule? A framework answers zero, by design. That is not a flaw, it is the category. It just means something else has to cover the rest.

Questions people ask about this

Is Great Expectations still maintained?

Yes. Fivetran became steward of the Great Expectations open source community and the GX Core project in May 2026, supporting ongoing maintenance, ecosystem integrations, and community engagement. GX Core remains Apache-2.0 and is actively releasing, with 1.20.0 current on PyPI. The product that was discontinued was GX Cloud, the commercial hosted offering, not the library.

What happened to GX Cloud?

FICO acquired GX Cloud to serve as the foundation of its next generation data quality capability, and GX Cloud stopped being publicly available on June 1, 2026. For new buyers this means the managed, UI driven version of Great Expectations can no longer be purchased. The open source library is unaffected, so the remaining options are self hosting GX Core or moving to a different managed platform.

Is Great Expectations free?

GX Core is free under the Apache-2.0 license, self hosted, with no seat or table limits. The license is free; the deployment is not. You supply the compute, the orchestrator, the engineering time to write and maintain Expectation suites, and the alerting layer, since the library produces validation results and does not notify anyone on its own.

Is Great Expectations a data observability tool?

No, and the distinction matters when you are choosing. Great Expectations is a data validation framework: it evaluates assertions you wrote, against data you pointed it at, when you ran it. Data observability platforms monitor continuously, learn each table's normal freshness, volume, and distribution, and raise incidents for anomalies nobody wrote a rule for, with lineage showing downstream impact. Many teams run both layers.

What should I use instead of GX Cloud?

It depends which part of GX Cloud you valued. If it was the hosted convenience, you want a managed platform, and the choice is between enterprise tools sold by quote and self serve tools that publish pricing. If it was the assertion authoring, GX Core still does that and always will. If you are unsure, start by asking how much of your warehouse is currently covered by any check at all, because for most teams the honest answer reframes the whole search from replacing a testing tool to adding a monitoring layer.

Does Great Expectations do data lineage?

No. Great Expectations validates data and does not map how tables and columns feed each other, so it has no lineage graph and cannot tell you which dashboards a broken table affects. Lineage has to come from an observability platform or a data catalog. If you are comparing options on that axis, our roundup of data quality tools covers which ones include column level lineage and which gate it behind a premium tier.

Where this leaves the decision

Great Expectations is a healthy open source project that lost its commercial front end. If you have the engineering capacity to run it, keep it: free, precise, and versioned alongside the transformations it protects. What it will never do is watch the tables nobody configured, which is where most incidents actually originate, and no amount of stewardship news changes that.

Dataobservability covers that second layer. It connects read-only to Snowflake, BigQuery, Databricks, or Redshift, generates freshness, volume, schema, and distribution monitors on every table without anyone writing a rule, includes column level lineage rather than gating it behind an upgrade, and routes grouped incidents to Slack and PagerDuty. It publishes what it costs: 99 dollars a month for Starter, 299 for Team, 799 for Scale, with a 14 day trial and no credit card. It does not replace your Expectation suites, and it is not meant to. It covers what they structurally cannot. If you are still mapping the landscape first, our guide to data quality management tools compares the categories side by side before you shortlist anything.

Catch broken data before your stakeholders do

Connect your warehouse and get all five pillars monitoring from one read-only connection. Transparent pricing, no credit card.