Why I Built QueryBear
I'm an engineer by trade. And when I look a couple years ahead, the landscape looks completely different than it does today.
Right now, AI is a tool that augments engineers. An idea comes from somewhere – a brain, a backlog – and an engineer prompts the AI to build it. That thing ships. The cycle repeats. It's still very much a human-driven loop.
I don't think that's where we'll be in two years.
I think the loop flips entirely. The agent becomes the true owner of the development process. The human's job shifts to final verification and steering – not building.
What that actually requires
For an agent to work that way, it needs to do more than write code. It needs to operate like an engineer.
That means reading the logs when something breaks. Understanding what customers are complaining about. Knowing what's on the roadmap. Seeing how users are actually moving through the product.
And critically – it needs to be able to query the database.
Without that, the agent is flying blind. It can't verify what's happening in production. It can't check the state of a record. It can't debug why something went wrong. It's not a user – it can't just open the app and poke around. So when something breaks, a human has to step in and do that investigative work themselves.
That's the bottleneck I kept running into. And it's not where humans should be spending their time.
My first attempt
My initial solution was simple: a proxy to our production read replica. Point the agent at it, let it run queries, move on.
It worked. But the risk never stopped nagging at me. A misconfigured query, a runaway join, an agent that decides to pull down the entire users table – there's enough that can go sideways that I never felt fully comfortable with it.
So I started building QueryBear. The goal was simple: give agents database access I could actually trust. Where I'd never have to wonder if something could go wrong.
Harder than I expected
Getting there required a lot more layers than I anticipated.
Before any query reaches the database, QueryBear runs it through a gauntlet of validation and sanitization:
Read-only enforcement — Every query gets checked to ensure it's purely read access. No writes, no deletes, no mutations, period.
Query complexity limits — There are certain SQL patterns that look innocent but can quietly spin up long-running queries. We ban them outright. Agents don't need complex joins to get useful data – they can do the stitching themselves.
Result capping — We limit how many rows come back. Flooding an LLM's context window with thousands of rows isn't useful and can actually make the agent worse at interpreting the results.
Schema introspection — QueryBear reads your database schema and hands it to the LLM before it writes a query. No guessing at table names or column types.
Business context — You can annotate your tables and columns with plain-English descriptions. Things like "this tracks whether the user completed onboarding" or "this is the user's current plan tier." The richer the context, the better the queries.
Timeout protection — Queries that run too long get cut off automatically. Your database never hangs waiting on an agent.
Rate limiting — Even if an agent is running unsupervised overnight and hammering the connection, it can't do damage. There's a hard ceiling on throughput.
The goal: invisible by design
QueryBear's entire purpose is to never harm your data or your database. Full stop.
If it's working correctly, you shouldn't think about it at all. It should just be there – quietly giving your agent what it needs, staying out of the way.
I've been running it internally for months now. At some point I stopped thinking about it entirely. It became one of those parts of the stack that just works.
That's exactly what a product like this should feel like.
If this resonates, I'd love to talk. Whether you want a demo, want to trial it immediately, or just want to think through how to give your agents database access safely – reach out.