The Compliance Fix That Backfired on Our Own Team
I ran security and compliance. Michael ran DevOps. Restricting database access was my requirement, but the cost of it landed on his team. This is the story of how the two of us ended up building the same tool from opposite ends of the same problem.
I'm going to tell you how QueryDesk started, because the origin is the clearest version of the argument the rest of this series makes at length. It's also honest about something founders usually launder out of these stories: the idea wasn't mine. It was Michael's. My role in the story is the one that created the problem.
Two seats, one problem
At the company where Michael and I worked (around 300 people), I owned security and compliance, and Michael led DevOps. On paper, we were on opposite sides of a familiar tension. My job was to restrict access to sensitive customer data and to prove, after the fact, who had touched it. His job was to keep engineers moving. The first of those makes the second harder, and we both knew it.
The requirement itself was not controversial. Customers were asking how we protected their data, an audit was on the horizon, and the honest answer to "who can read the customers table" was "more people than should be able to." So we did the responsible thing. We stopped allowing engineers to connect to production using standing credentials.
Michael turned to Google Cloud's Privileged Access Manager. The model is grant-based: an engineer requests temporary elevated access, an approver grants it for a window, and the grant expires on its own. Again, on paper, it is exactly what a compliance lead wants. Access is no longer standing. Every elevation is requested and approved. There is a record. I signed off on it because from where I sat, it checked every box.
The tax
Here is what it looked like in practice, every day.
An engineer needed to run a query against production. To do that, they requested a PAM grant. The grant had to be approved, and the approver was another DevOps engineer. So every production query cost the time and effort of two people: one to request the access and do the work, and one to stop what they were doing, look at the request, and approve it. Two engineers per query.
The approver was not actually evaluating much. The grant was for an access window, not for a statement, so what they were approving was "let this person into production for the next hour," not "let this person run this specific query." They had no way to assess the thing that carried the risk, because the thing that carried the risk had not been written yet. They were approving trust in a person, with extra clicks. It was rubber-stamping dressed up as a control.
Michael added it up at one point, and it was close to a quarter of his team's time. Not building anything. Requesting access, approving access, and walking engineers and each other through the PAM dance. That much of a DevOps team spent being in a queue.
And from my side of the table, the thing this process was supposed to buy me was not even that good. I had a record that someone had been granted access to a database for an hour. When the audit question came, the one that actually gets asked, "who changed this row, and who approved that change," the grant did not answer it. It told me a window had been opened. It told me nothing about what ran inside the window. I was still correlating grant logs, database logs, and Slack threads to reconstruct what had actually happened. That gap is its own post in this series, so I will not belabor it here. The point is that we were paying a heavy operational tax for an answer that was still incomplete.
That is the part that should bother you if you are standing where I was. We had done everything right. We restricted access, we required approvals, we kept records. And we had still managed to build something that was expensive for engineering and only partly satisfying for compliance. The control worked exactly as designed, yet it still left both of us short.
What Michael saw
Michael is the one who named what was wrong, and the thing he understood that I did not was that we had not configured anything badly. PAM was doing precisely what PAM is built to do. The problem was the unit.
He had seen this before, at more than one company, wearing different costumes. The most common one is not a PAM tool at all. It is the internal "admin portal," the home-built web app that exists specifically so that support, ops, and sometimes half of engineering can get their work done without being handed direct database access. It gets built to satisfy exactly the security and compliance instinct I was operating on. Then it quietly becomes load-bearing, owned by no team in particular, and it turns out to be its own ungoverned access path, because under the hood, the portal itself holds god-mode credentials, and nobody is auditing what flows through it. Michael had watched that pattern calcify at multiple SaaS companies. PAM was just the cleaner-looking version of the same mistake.
His insight was that if you made the query the unit, my problem and his problem were the same problem with the same fix. Safe queries flow through with no human in the loop, so most of the two-engineer dance simply disappears, because most queries never needed the second engineer. The risky ones route to an approver who sees the exact SQL and approves or rejects that statement before it runs, so the approver is finally evaluating something real instead of vouching for a person. And the audit record is the query itself, which is the record I had been trying to reconstruct by hand. I will not re-derive that argument here, because it is the whole subject of another post. The short version is that when the query is the unit, the thing the approver evaluates and the thing the auditor reads are the same object.
We were not the only ones who had hit this, and the market had two other answers. I want to be fair to both, even though neither is what we reached for. Change-management tools like Bytebase govern schema migrations well, but their access model is the same time-bound grant in a different wrapper, which I get into in the Bytebase comparison. And a whole class of tools tells you to put everyone inside their web SQL editor, which holds up right until your best engineers route around it to stay in the client they are fast in, which is its own post, too. We did not run either of those experiments ourselves. We had lived the PAM version, and that was enough to convince Michael the unit was the issue, not the vendor.
What happened next
What happened next was not a launch. Once it was running against real production access, it did what Michael said it would. The two-engineer dance went away for the queries that did not need it, and the ones that did produced an audit record I could actually hand to an auditor without a three-day reconstruction first.
It spreads the way things spread when they are real rather than marketed. Former coworkers and friends at other companies heard what we had built, recognized their own version of the pain, and asked to try it. Nobody was selling. People were just describing the same bottleneck to each other and pointing at the thing that fixed it.
Neither of us is a salesperson. We are a security guy and a DevOps guy. We took the early product to KubeCon mostly because it felt like the thing you are supposed to do, and it took both of us a real act of nerve to stand at the table and explain it to strangers. Then we watched the same thing happen over and over. Someone would start describing their own version of the problem, the two-engineer dance, or the audit they had barely survived, or the admin portal nobody owned, and partway through our explanation, you could see it land. Their expression would change, because we had just described a pain they had assumed was theirs alone. That happened enough times in two days that we stopped wondering whether the problem was real or whether it was just ours.
Why I'm telling you this
I tell the story this way because it is the most honest version of the pitch. We did not start from a market analysis. We started as the two people on opposite ends of the same bad arrangement: the compliance lead who needed the control, and the DevOps lead whose team paid for it. The reason QueryDesk governs the query rather than the session is that the query is the exact point where my problem and Michael's became one.
If you are the engineer approving access requests all day, or the one whose compliance program is technically satisfied but practically miserable, or the one maintaining the admin portal nobody will claim, you have probably felt some version of this. We built the thing we wished we had had on both sides of that table.
If you want to see whether it fixes your version of it, the 14-day trial is free and doesn't require a credit card. We won't blow up your inbox with annoying sales requests; only a few helpful hints on how to use the product. We just want to see this problem solved for as many people as we can. We lived this problem, it sucks. It can be better.
Josh Mackelprang, Co-Founder, QueryDesk