# Querying an openEHR CDR with SQL, Cypher, and GraphQL? Yes, it’s possible.

**URL:** https://discourse.openehr.org/t/querying-an-openehr-cdr-with-sql-cypher-and-graphql-yes-it-s-possible/17088
**Category:** Implementation
**Tags:** aql
**Created:** [7 July 2026 18:13 UTC](https://discourse.openehr.org/t/querying-an-openehr-cdr-with-sql-cypher-and-graphql-yes-it-s-possible/17088 "2026-07-07T18:13:17Z")
**Posts on this page:** 1
**Showing post:** 11

<div class="post-metadata">

### Author: ![Sidharth\_Ramesh](https://discourse.openehr.org/user_avatar/discourse.openehr.org/sidharth_ramesh/32/674_2.png) [@Sidharth\_Ramesh](https://discourse.openehr.org/u/Sidharth_Ramesh)
#### Post date: [13 July 2026 06:57 UTC](https://discourse.openehr.org/t/querying-an-openehr-cdr-with-sql-cypher-and-graphql-yes-it-s-possible/17088/11 "2026-07-13T06:57:18Z")

</div>

> [@pablo](#):
>
> Queries are not code. Code is a set of instructions to be executed. Queries are a description of data retrieval.

Won’t ‘description of data retrieval’ also be ‘a set of instructions to be executed’?

I consider SQL / AQL, or any language for data retrieval is code. Even a simple GET request with search params.

And of course, it’s not intended for the end user of an application to actually understand it. But there is always a human in the loop who has to understand / what this means - this is usually the developer of this application. These are the people usually using these tools to help build the queries faster. It’s never the end user or clinician constructing SQL or AQL..

So even if there is a tool that translates a user’s requirements to a machine readable state, why have the output of such tool not be fit for human consumption? The developer needs to look at this and agree on it’s correctness anyway. Why make it more complex than it needs to be?

---

_[View the full topic](https://discourse.openehr.org/t/querying-an-openehr-cdr-with-sql-cypher-and-graphql-yes-it-s-possible/17088)._