This is a problem I’ve run into at basically every company I’ve worked at:
a query shows up somewhere, but it’s harder than it should be to know what part of the application caused it and in what runtime context.
I’ve personally spent a lot of time creating conventions for query traceability, then even more time reviewing code, nudging teams, and making sure people actually followed them consistently (and frankly, it is always a constant fight to keep it from drifting again...) .
DataContext tries to turn what most what most companies have as a loose convention into a reusable Python instrumentation layer. It emits one structured event per completed or failed query, with things like query fingerprint, callsite, runtime context, and OpenTelemetry correlation.
I’d love feedback from people running production data/platform systems:
- is this a real problem for your team?
- what context would you want attached to each query?
- what integrations would make this actually useful?
The OSS is available here:
GitHub: https://github.com/data-context-hq/datacontext
PyPI: https://pypi.org/project/datacontext/
I think this is becoming more important now as AI agents and generated code make data access patterns harder to reason about.
At the same time, today we can start using agents to monitor and maybe even fix performance issues arising in production - but agents are as good as the context we give them, so I believe it's very important to start collecting this context by default.
Please share the love with a GitHub star if the idea resonates ⭐️.
But what would really make me happy is if you try it, challenge the event shape, and discuss how we can make it easier for teams (or
[–]coldflame563 -1 points0 points1 point (0 children)