DEV Community: Muhammad Awais

We Gave Claude Code Access to Our Production Database. Here's How It Doesn't Go Wrong.

Muhammad Awais — Sat, 08 Aug 2026 09:27:33 +0000

We Gave Claude Code Access to Our Production Database. Here's How It Doesn't Go Wrong.

Every team building with AI agents eventually hits the same wall: the agent needs to query a real database to be useful, and every way of doing that looks bad. A DATABASE_URL in the agent's config is a credential sitting on a laptop. A shared read replica with a shared login means "who ran that query" is unanswerable. And a hand-rolled MCP wrapper around your DB driver is a security review waiting to happen. We built db-mcp-gateway to make that a solved problem instead of a judgment call. It's a self-hosted, MIT-licensed gateway, written in Rust,that sits between your AI agents and your databases. The agent never holds a credential not once, not cached, not in a log line.

The one-minute model

Deploy the gateway once. Developers add one URL to their MCP config:

claude mcp add --transport http db-gateway --scope project https://db.internal.acme.com

That's the entire client-side setup. First call to any gateway tool returns
401, the agent surfaces an SSO login link, you authenticate through your
org's actual identity provider (Okta, Google Workspace, Entra, Authentik,
Keycloak), and the token lands in your system keychain — never in a config
file, never in the agent's context.

┌─────────┐    MCP/HTTPS    ┌──────────────┐    pg wire    ┌──────────┐
│ agent   │ ──────────────▶ │   gateway    │ ────────────▶ │ target   │
│ (Claude │   bearer: jwt   │              │  ro role per  │  DBs     │
│  Code)  │ ◀────────────── │  authz+audit │ ◀──────────── │          │
└─────────┘   tool result   └──────┬───────┘   result rows └──────────┘
                                   │
                                   ▼
                            ┌──────────────┐
                            │ state DB     │
                            │ (sessions +  │
                            │  audit log)  │
                            └──────────────┘

Permissions are YAML, reviewed by PR not a UI

There's deliberately no admin UI. Access lives in a config file your team
reviews the same way you review any other production change:

permissions:
  - group: data-analysts        # matches an SSO group from the IdP claim
    grants:
      - server: prod
        database: "*"
        action: query_read      # SELECT + schema reads, never writes
        constraints:
          require_reason: true  # agent must justify the query → audit log
          row_limit: 1000       # gateway truncates beyond this
          statement_timeout_ms: 5000

Actions are hierarchical (query_write ⊇ query_read ⊇ schema_read), and
when multiple grants match, the most restrictive constraint wins. Writes are
opt-in per grant and, even then, capped hard: a query_write grant permits
a single INSERT/UPDATE/DELETE per call, through the same timeout and
row-cap path as a read. CREATE, ALTER, DROP, TRUNCATE, GRANT,
REVOKE, and multi-statement bodies are rejected with forbidden_sql —
always, regardless of grant. The gateway never issues DDL, full stop.

What the agent actually sees

You:    What databases can I see through db-gateway?

Claude: [calls list_servers → list_databases]

        You have access to:
        • staging (postgres) — staging/app, staging/billing
        • prod (postgres)    — prod/billing (read-only, reason required)

You:    How many users signed up in staging/app over the last 7 days?

Claude: [calls run_query staging/app]
          select count(*) from users where created_at > now() - interval '7 days';

        → 412 (returned in 38ms)

Cross a boundary and the failure is explicit, not silent: forbidden if
your group's grant doesn't cover it, timeout if the query exceeds
statement_timeout_ms, row_limit_exceeded/truncated: true if the result
is bigger than the grant allows, or a reason_required prompt if the grant
demands one — typically anything touching prod. The agent asks you for the
reason and it lands verbatim in the audit row. "checking stuff" versus
"verifying SUPPORT-4421 root cause" is the difference between an audit log
that's useless in six months and one that isn't.

Every run_query call writes that audit row user, SQL, reason, row
count, duration, outcome — before the result comes back to the agent, not
after. Hot retention lives in Postgres; there's an optional archive sink to
S3/GCS/Azure and streaming export via OTLP/syslog/stdout for teams who
already have a SIEM.

The stack, if you're curious

Rust, tokio for async, axum for HTTP, sqlx for the DB layer, config in
YAML validated at boot with line:column error pointers on typos. The
gateway also speaks the MCP Authorization spec (OAuth 2.1 + PKCE) itself —
it is the authorization server, brokering your IdP login internally, so
Claude Code and other MCP clients authenticate with zero manual credential
wiring on the client side.

What's not done yet

In the interest of not doing the thing every "launch" post does: this is a
young project (first commit May 2026) and a few pieces referenced in the
docs aren't real yet. There's no Helm chart docker-compose or hand-rolled
k8s manifests today. vault:/aws-sm:/gcp-sm: secret backends are
recognized in config but rejected at boot until they land; use ${ENV:...}
or ${FILE:...} refs for now. Session revocation is a manual psql insert
into a denylist table until the planned gateway admin CLI ships. None of
that blocks running it in production we do but it's not the finished
enterprise product yet, and I'd rather say that here than have someone find
out from the roadmap doc after trying it.

Why this exists

db-mcp-gateway is built and maintained largely by AI agents at
developerz.ai, under human review, with every change going through CI
before merge. It's also, not coincidentally, a small working demo of the
same idea developerz.ai sells as a product: agents should never hold raw
credentials, and every action they take should be attributable and
auditable. The gateway is the free, self-hosted version of that philosophy.

docker pull ghcr.io/developerz-ai/db-mcp-gateway:1.1.1

MIT-licensed. Repo, docs, and the full permissions reference are at
github.com/developerz-ai/db-mcp-gateway.

You Don't Need Sidekiq Pro for Batch Jobs, Rate Limiting, or Cron Here's a Free Drop-In

Muhammad Awais — Fri, 07 Aug 2026 15:37:19 +0000

If you've built anything non-trivial with Sidekiq, you've probably hit the wall where the feature you actually need batch job callbacks, rate limiting,scheduled jobs lives behind Sidekiq Pro or Enterprise. That's a reasonable business model, and it's funded years of full-time development on Sidekiq. If your company can afford the license, it's worth paying for. But a lot of teams can't justify the line item for a side project or an early startup. So I want to show what those features actually look like, and then show
a free, MIT-licensed, wire-compatible way to get them: wurk.

developerz-ai / wurk

Drop-in replacement for Sidekiq + Pro + Enterprise. 100% API-compatible, free forever, meaningfully faster. Mountable Rails engine.

Wurk ⚡

Wurk, wurk. 🪓 Ready to work. Zug zug.

A 100% drop-in replacement for Sidekiq + Sidekiq Pro + Sidekiq Enterprise. Free forever.

Wurk is wire-compatible with Sidekiq — same Redis keys, same job JSON, same Ruby DSL. Swap one line in your Gemfile and your existing jobs, batches, limiters, cron entries, and live Redis data keep working untouched. The Pro and Enterprise feature sets ship in the same free gem, with no license check and no tiers.

On speed: Wurk is not currently faster than stock Sidekiq — it runs at roughly 0.87×–1.02× depending on workload shape, with parity on CPU and I/O but still behind on framework overhead (noop) and boot time. Numbers, method, and the reproduction command are in docs/benchmarks.md; run them yourself with rake bench:vs_sidekiq.

Install

# Gemfile
gem "wurk"

# ...or drop in over an existing Sidekiq stack — delete these, add

…

View on GitHub

The migration is one line

Wurk speaks the same Redis protocol as Sidekiq same keys, same job JSON, same
Ruby DSL. If you're already on Sidekiq:

- gem "sidekiq"
- gem "sidekiq-pro", source: "https://gems.contribsys.com/"
- gem "sidekiq-ent", source: "https://enterprise.contribsys.com/"
+ gem "wurk"

bundle install, restart, done. Sidekiq::Worker, Sidekiq.configure_server,
your existing job classes — none of it changes. Your in-flight Redis data keeps
working untouched.

Batches, without the license check

Sidekiq::Batch lets you fire off a group of jobs and run a callback when the
whole group finishes — the classic use case is "process these 500 records, then
send one summary email."

batch = Sidekiq::Batch.new
batch.description = "Import customer CSV"
batch.on(:success, MyCallback, "to" => "ops@example.com")

batch.jobs do
  rows.each { |row| ImportRowJob.perform_async(row.id) }
end

Batches nest, too — a parent batch's callback only fires once every child batch
has finished, which is what you want for multi-stage pipelines. In stock
Sidekiq this whole API is Pro-only. In wurk it's just... there.

Rate limiting five different ways

Sidekiq::Limiter — an Enterprise feature — ships five limiter types, because
"rate limit" means different things depending on what you're protecting:

# concurrent: at most N jobs of this type running at once
limiter = Sidekiq::Limiter.concurrent("api-calls", 10)

# window: at most N calls per rolling time window
limiter = Sidekiq::Limiter.window("api-calls", 100, 1.hour)

# leaky bucket, bucket, and points limiters cover the rest —
# see docs/rate-limiting.md for when to reach for which
limiter.within_limit do
  ThirdPartyApi.call
end

If you've ever hand-rolled a Redis INCR + EXPIRE rate limiter and hit an
edge case at 2am, this is the version that's already handled the edge cases.

Cron jobs that actually run once

Periodic jobs are the other Enterprise feature, and the part that's easy to get
wrong yourself: if you run multiple worker processes, a naive cron
implementation fires the job once per process, not once total.

Sidekiq::Periodic.register("0 9 * * *", DailyReportJob)

Wurk's periodic scheduler is leader-elected across the cluster, so this fires
exactly once regardless of how many worker processes you're running.

Encrypted job arguments

If a job argument is a customer's SSN, an API secret, or anything else you'd
rather not sit in plaintext in Redis or your logs, Enterprise's answer is
transparent AES-256-GCM encryption with key rotation:

class ChargeCardJob
  include Sidekiq::Job
  sidekiq_options encrypt: true
end

The argument is encrypted before it hits Redis and decrypted only inside the
worker process. Wurk implements the same interface.

The dashboard, without a Node build

Wurk's Web UI mounts as a Rails engine, and the frontend ships precompiled
inside the gem — installing it doesn't pull Node into your build pipeline:

# config/routes.rb
authenticate :user, ->(u) { u.admin? } do
  mount Wurk::Engine => "/wurk"
end

There's a live, read-only demo if you want to poke at it before installing
anything: wurk.demo.developerz.ai

How this is built

The honest context, because it's relevant if you're deciding whether to trust
this in your stack: wurk is built and maintained largely by AI agents, working
under human review, against a documented parity spec of Sidekiq's public API
(what we call a clean-room implementation — the interface, not the source).
There's a ≥90% line coverage gate enforced in CI, and the parity specs
themselves are written against Sidekiq's own documented OSS/Pro/Enterprise
surface, so behavior drift shows up as a failing test regardless of who wrote
the code.

It's new one production app running on it internally so far, plus the public
demo. I'm not going to oversell that. If you run Sidekiq at real scale and want
to try wurk against a staging environment, I'd genuinely like to know what breaks.

Repo: https://github.com/developerz-ai/wurk
Docs: https://developerz-ai.github.io/wurk/

What would stop you from trying this — licensing worry, missing feature,
something else? Curious to hear in the comments.