DEV Community: Mads Hansen

AI support triage does not need your entire inbox

Mads Hansen — Wed, 29 Jul 2026 01:21:52 +0000

The support lead asks: what needs attention right now?

The dangerous implementation gives an AI assistant raw ticket tables.

Those tables contain names, emails, internal notes, copied logs, attachments, security details, and sometimes secrets that should never have been pasted there.

The useful workflow returns less.

Start with a governed summary:

overdue count
unassigned count
reopened count
age bands
approved urgency categories
data freshness

Then make drill-down progressive:

aggregate summary
bounded worklist with ticket IDs and controlled fields
separately authorized, redacted detail for one case

Each expansion is a new policy decision.

Keep tenant and queue scope in authenticated context. Keep metric definitions in approved views or a semantic layer. Keep raw notes, contact details, attachments, and unrestricted free text outside the first result.

And separate analysis from action.

A tool that identifies five tickets needing owners should not automatically gain authority to assign them, send replies, or close cases. Those are separate operations with validation, idempotency, and approval where needed.

The goal is not to expose the inbox.

It is to expose the smallest decision signal that helps the team act.

Full workflow: ChatGPT database query for support triage

Your MCP pagination cursor is a security boundary

Mads Hansen — Wed, 29 Jul 2026 01:21:51 +0000

An AI agent rarely consumes a large PostgreSQL result in one call.

It reads a page, reasons, calls another tool, and comes back.

Meanwhile, rows change.

LIMIT/OFFSET describes a position in a changing list. Inserts can duplicate rows across pages. Deletes can skip them.

For MCP tools, use a deterministic keyset such as:

ORDER BY created_at DESC, id DESC

Then return an opaque cursor bound to:

the last ordering values
tenant and environment
normalized filter hash
sort and query version
page-size ceiling
snapshot rule
expiry

The server should reject a cursor when any of that scope changes.

Also document consistency. Does the next page reflect live committed data, a captured high-water mark, or a materialized short-lived result?

Keyset pagination prevents position drift. It does not magically create a snapshot across separate tool calls.

Every page should carry has_more, returned count, filters, freshness or snapshot time, truncation state, and a trace ID. Otherwise the model may present page one as the complete answer.

Finally, retry the same cursor after a timeout. It should produce the same logical page under the contract—not silently advance or restart.

Full implementation guide: MCP server for Postgres: make pagination a stable data contract

A database failover can preserve uptime and break the answer

Mads Hansen — Tue, 28 Jul 2026 01:21:53 +0000

A PostgreSQL MCP server can remain available during failover and still return the wrong answer.

The connection retries against a replica.

The replica is behind.

A conversation combines a pre-failover result with a post-failover follow-up.

Every query succeeds, so the final answer looks complete.

Before production, give each workflow a consistency contract:

eventual with a disclosed lag budget
monotonic within one conversation
read-your-writes
point-in-time across multiple queries
primary-only

Then make source identity, schema version, snapshot marker, observed time, and freshness part of material results.

Test more than promotion:

idle pooled connections
active transactions
prepared statements and DNS caches
interrupted multi-query answers
bounded retries
conversation continuity
schema and policy versions
paused replay and catch-up
failback

Never concatenate partial rows from the old primary with rows from the new one. If the answer cannot prove one consistency boundary, discard the partial result and return a structured retryable failure.

Availability is a transport property.

Trustworthy answers need a data contract.

Full test guide: MCP server for Postgres: test failover consistency, not only availability

Your AI database access review needs a revocation test

Mads Hansen — Tue, 28 Jul 2026 01:21:52 +0000

An access review that checks only group membership can approve a connection that no longer exists—and miss one that is still usable.

A ChatGPT Enterprise database connection crosses several control planes:

enterprise identity
workspace roles
connector policy
MCP tool exposure
database credentials and grants
row-level policies
caches and active sessions
emergency access

Review the effective path from a real user to a real result.

Then test revocation.

Create a controlled user, establish an active conversation, queue a request, and populate relevant caches. Disable the user and remove the role. Verify:

new and existing sessions
queued calls and retries
refresh tokens
connector caches
pooled database connections
exports and scheduled workflows

A directory change is not complete revocation if an old session can still execute.

Break-glass access deserves the same treatment. Approve one bounded query, let the permission expire, and prove that both the credential and active session are unusable.

The review should change effective access, not just produce a signed spreadsheet.

Full checklist: ChatGPT Enterprise database connection: run an access review that tests reality

Your PostgreSQL MCP server is only as current as its schema context

Mads Hansen — Mon, 27 Jul 2026 01:22:44 +0000

A PostgreSQL MCP server can work perfectly on Friday and become confidently wrong after Monday's migration.

The database is available.

The tool connects.

The SQL may even execute.

But a migration can still change:

a view's grain
a status enum
a timestamp's business meaning
a join's cardinality
exposed permissions
the authoritative metric source

Schema-change readiness therefore needs more than rediscovery.

Test renamed and removed objects, executable-but-semantic changes, permission drift, stale caches, multiple MCP replicas, representative query plans, in-flight conversations, and interrupted rollout states.

Bind every test to:

database migration version
exposed object and policy versions
semantic definition
MCP tool schema
server build
discovery timestamp

If context freshness cannot be proven, affected tools should fail with a structured stale-schema result instead of guessing.

And use expand-and-contract for tool contracts too: add the new version, run old and new against deterministic fixtures, migrate clients deliberately, observe the compatibility window, then remove the old contract.

“The new view exists” is not a production gate.

“The new meaning is tested, versioned, authorized, observable, and recoverable” is.

Full test guide: MCP server for Postgres: test schema-change readiness before production

The missing column in every ChatGPT connector comparison: who owns the failure?

Mads Hansen — Mon, 27 Jul 2026 01:22:33 +0000

The connector demo is usually the easy part.

A user asks a question, the tool finds a source, and ChatGPT returns a plausible answer.

Production starts when:

an employee leaves
a reporting view changes
a replica becomes stale
a query overloads the source
sensitive data appears in a trace
the model or connector changes underneath the workflow

That is why connector comparisons need an ownership matrix, not only a feature matrix.

For every responsibility, name:

one accountable owner
the system that enforces the control
evidence that proves it ran
the escalation path when it fails

Cover identity and offboarding, semantic definitions, tenant policy, query pressure, result redaction, retention, regression testing, incident response, support, and exit.

“Shared responsibility” is not useful until the hand-off is explicit.

A provider can own the connector gateway while the customer still owns database capacity. A data team can own the revenue definition while identity owns offboarding. Security can own retention while the connector owns redaction before model context.

The point is not to move every responsibility to one vendor.

It is to make sure every production failure has a named owner before the pilot becomes infrastructure.

Full matrix: ChatGPT connector alternatives: compare production ownership before features

Natural-language SQL needs metric contract tests, not just valid SQL

Mads Hansen — Sun, 26 Jul 2026 01:21:59 +0000

Valid SQL can still produce the wrong business answer.

An AI SQL assistant may choose real tables, legal joins, and executable filters while misunderstanding what “active customer,” “revenue,” “churn,” or “open pipeline” means.

So the production test should not stop at:

did the SQL parse?
did the query run?
did it stay read-only?

It should test a versioned metric contract.

For every important metric, define:

entity and grain
eligible population and exclusions
tenant and environment scope
numerator, denominator, and state transitions
time field, timezone, and late-arrival policy
currency and precision
approved sources and joins
freshness budget
expected behavior when the question is ambiguous

Then build a controlled fixture with the awkward cases:

internal and trial accounts
cancellations and reactivations
nulls, refunds, and duplicates
one-to-many joins
month-end and daylight-saving boundaries
stale upstream data
missing conversion rates

Assert more than exact totals.

Useful invariants include:

the part cannot exceed the eligible population
exhaustive segments must reconcile to the total
adding an excluded tenant must not change the metric
reordering rows must not change the answer
truncated input cannot produce an unqualified complete result

And test ambiguity on purpose.

If “active customer” has two approved meanings, the correct output may be a clarification request—not a confident query.

The key is to separate failure classes:

wrong intent
guessed contract
invalid or unsafe SQL
valid SQL with wrong business meaning
missing source evidence
incorrect final summary

One accuracy score hides which boundary failed.

Full guide: Natural language SQL metric contracts: test business meaning before deployment

Your AI database audit log should not become a second database

Mads Hansen — Sun, 26 Jul 2026 01:21:58 +0000

An audit log should explain what happened.

It should not quietly become a second database containing every row the AI was allowed to see.

That is the evidence problem behind many ChatGPT-to-database rollouts.

Teams need enough information to answer:

who requested the data?
which identity and policy applied?
what source and business definition were used?
were row, field, and byte limits enforced?
was the result fresh, complete, or truncated?
what reached the database?

They usually do not need every returned row copied into prompts, traces, tickets, and observability tools.

A better receipt records identity, tool and policy versions, normalized filters, source, freshness, row and byte counts, redaction decisions, structured outcome, and a trace reference.

Keep raw result capture separate:

require an explicit debugging purpose
restrict who can capture and read it
redact before persistence
scope it to the minimum rows and fields
give it an automatic expiry
track every downstream copy

Two details matter more than they first appear.

First, remove sensitive literals from query fingerprints. Email addresses and account IDs do not become safe just because they are inside SQL text.

Second, do not assume hashing solves the problem. Low-entropy values can be guessed, and stable hashes can become identifiers of their own.

The useful split is:

the AI-layer receipt explains intent, policy, and result shape
database-native evidence proves what reached the data system

Together they provide an audit trail without turning telemetry into another store of customer data.

Full guide: ChatGPT Enterprise database connection: retain evidence without retaining the data

Claude Code can propose the Postgres migration. It should not execute it.

Mads Hansen — Sat, 25 Jul 2026 01:21:11 +0000

Claude Code can inspect application code, trace a failing query, and propose a PostgreSQL migration in one session.

That does not mean the same session should execute the migration.

A safer Claude Code + MCP + Postgres boundary:

use a dedicated read-only investigation identity
expose schema, plan, lock, sample, and migration-status tools
keep mutation tools out of that server
bind every call to an explicit environment
return a structured migration plan with preconditions and a digest
validate the plan against current schema and runtime state
approve the exact digest, target, scope, window, and impact
execute through a controlled runner with a short-lived identity
revalidate before execution
return a durable receipt and preserve recovery checkpoints

The key distinction is simple:

Claude Code can investigate.
Claude Code can propose.
A reviewer can approve.
A constrained runner can execute.

Combining those authorities makes a smooth demo.

Separating them makes a production boundary.

Full guide: Claude Code MCP Postgres: separate investigation from migration authority

A successful ChatGPT database query can still be wrong

Mads Hansen — Sat, 25 Jul 2026 01:21:10 +0000

A plausible number is not a verified number.

A ChatGPT database query can run successfully and still answer the wrong business question.

Common causes:

the wrong metric definition
an inherited tenant or environment scope
stale upstream data
a month or timezone boundary
duplicate or late-arriving records
a truncated result
a confident summary of a provisional number

Before sharing the answer, reconcile it:

write the metric, population, exclusions, time window, timezone, and currency
bind it to an approved source and definition version
record source freshness and upstream completion
inspect typed results before the prose
compare with an independent control
explain material differences with a movement bridge
preserve row count, truncation, filters, and trace evidence
require a separate approval before publication

The best outcome is not always “the number matches.”

Sometimes it is: “The difference is explained, the source is late, and this answer is provisional.”

Full checklist: ChatGPT database query reconciliation

Your MCP credential is not revoked when the dashboard says disabled

Mads Hansen — Fri, 24 Jul 2026 01:21:36 +0000

An MCP credential is not revoked when the control plane says “disabled.”

It is revoked when every path that could still accept it stops accepting it.

That includes:

new client connections
existing MCP sessions
gateway policy caches
refresh and exchanged tokens
queued jobs
background workers
database connection pools
downstream APIs

Define a revocation SLO from the authoritative change to the final protected operation.

Then run a drill:

issue a uniquely tagged, narrowly scoped credential
open fresh and persistent sessions
queue a bounded job
record the revocation timestamp
retry through every supported path
terminate downstream sessions as designed
search for successful calls after the deadline
restore access with a new credential
prove the old one remains invalid

The most important timestamp is not when the dashboard acknowledged the change.

It is the last successful protected operation.

Full guide: MCP credentials: test revocation propagation before production

Do not connect ChatGPT to the MySQL writer first

Mads Hansen — Fri, 24 Jul 2026 01:21:35 +0000

The risky part of connecting MySQL to ChatGPT is not the first successful answer.

It is proving that a new question workload can reach live data without competing with checkout, support, billing, or other production traffic.

A better first production path:

choose one bounded question family
create a dedicated read replica or isolated reporting path
use a purpose-built MySQL identity
expose typed business operations, not arbitrary SQL
measure replica freshness explicitly
run answer-parity and negative contract tests
set connection, query, row, byte, and lag budgets
shadow representative questions
enable a small cohort with a kill switch

The result contract should include the source, filters, observation time, freshness state, row count, truncation, and trace ID.

If the replica is outside the workflow's freshness budget, return a structured stale-data result. Do not quietly turn old data into a confident answer.

A read replica is not the whole security model. It is a separate failure domain that makes load testing, canarying, and rollback much easier.

Full tutorial: How to connect MySQL to ChatGPT with a read-replica cutover