Hi @seefoods,
Just came across this post. In case you are still looking for an answer, I see these as complementary rather than overlapping tools.
A practical approach would be to keep the data contract as the source of truth in datacontract.yaml, use the Data Contract CLI docs for linting, testing, and contract evolution in CI/CD, and then use DQX inside Databricks for runtime enforcement, profiling, dashboards, and richer Spark-native quality checks.
The nice connection point is that Data Contract CLI can export contracts to odcs, and DQX now has a public guide for data contract quality rule generation, which makes it a good fit for turning contract definitions into Databricks-side validation rules.
So the pattern I would suggest is:
- Define and version the contract in datacontract.yaml.
- Run datacontract lint, datacontract test, and datacontract breaking in CI/CD.
- Export to ODCS if needed.
- Use DQX in Databricks to execute the operational quality checks close to the data.
If this answer resolves your question, could you mark it as โAccept as Solutionโ? That helps other users quickly find the correct fix.
Regards,
Ashwin | Delivery Solution Architect @ Databricks
Helping you build and scale the Data Intelligence Platform.
***Opinions are my own***