Okay, so I was deep in my usual Saturday pipeline refactoring rabbit hole, and I hit a snag. I needed to generate some analytics for our deployment success rates, but the data's all stored in this monolithic Postgres instance with a schema that's... let's call it "historically grown." I knew *what* I wanted: "the average lead time for deployments in the last quarter, grouped by environment, but only for services that had at least one rollback." But writing that JOIN with the proper conditions felt like a chore that would break my flow.
On a whim, I popped into a Notion page where I keep my personal DevOps notes and threw the description into Notion AI. I just typed:
> "Write a SQL query to get the average lead time for deployments in the last quarter, grouped by environment, but only for services that had at least one rollback."
And you know what? It spat out a shockingly decent first draft. It wasn't perfect for my specific schema, but it was a 90% complete skeleton. Here's what it gave me:
```sql
SELECT
environment,
AVG(lead_time) as average_lead_time,
COUNT(*) as deployment_count
FROM
deployments d
WHERE
d.deployment_date >= DATE_TRUNC('quarter', CURRENT_DATE - INTERVAL '3 months')
AND d.deployment_date = d.deployment_date - INTERVAL '30 days'
)
GROUP BY
environment
HAVING
COUNT(*) > 0
ORDER BY
average_lead_time DESC;
```
The logic was all there: the date range for "last quarter," a correlated subquery to find rollbacks for the same service, the grouping, and even a sensible HAVING clause. I just had to tweak the table name, date column, and status value to match our actual schema. It saved me a solid 15 minutes of thinking about SQL syntax and let me focus on the *logic*.
This got me thinking beyond just ad-hoc queries. Imagine using this in a CI/CD context:
* **Documentation in PRs:** "Hey, this migration needs a specific query to backfill data." Could the AI generate a baseline from a plain-English comment in the PR description?
* **Generating test data setups:** "Create 50 rows in the 'users' table with realistic names and emails." Feed that to a seed script.
* **Quick analytics for dashboards:** Instead of digging through old queries, just describe the new metric you need.
Of course, it's not magic. The generated query assumed a table called `deployments` with columns `environment`, `lead_time`, `deployment_date`, `service_id`, and `status`. If your schema is wildly different, it'll be wrong. You absolutely need to understand SQL to validate and correct the output—this is a starting point, not a production-ready artifact.
But as a productivity booster for breaking through mental blocks? It's fantastic. I'm now wondering if I could hook this concept into a custom GitHub Action or a GitLab CI job that could take a natural language description and generate a data validation query as part of a pipeline. The security implications of letting an AI loose on your production schema are... non-trivial, to say the least. But for isolated, read-only analytics databases? Maybe.
Has anyone else tried using Notion AI (or any other AI assistant) for this kind of code-adjacent scaffolding? I'm curious if you've found other neat applications in the DevOps/data engineering space.
pipeline all the things
That's a neat trick for getting past the initial mental block. Did you find it was mostly correct on the structure, like the JOIN clauses and WHERE logic, but just got the column names wrong? That's where I'd see myself spending the extra time anyway - fixing the schema details.