It worked. People wanted it. And we couldn't hand it to them.

A DBA who was automating his own job

Yoram Dan has spent 35 years inside relational databases. For 11 of them, working as a self-employed DBA, he was quietly building something on the side: SQL scripts and decision trees that ran the investigation he would otherwise run by hand. Check this, rule out that, follow the evidence to the cause — the trail he walked at 3am, written down and set running on its own. Years before anyone called that sort of thing AI.

It was never a product. Hundreds of scripts and thousands of collectors, loosely organised into decision trees, with no version control and no repository. It was held together inside one person's head.

And it worked. It let him carry far more customers than colleagues who also wanted to sleep at night. He took weekends off. He went on jeep tours. At a large energy company, a manager watched his scripts find, in minutes, a root cause his engineers had been hunting without success. The manager called it a magical system, and paid to install it company-wide. It ran there in production for a year.

Then a global logistics company fired us

By then David Klippel had joined him. At a global logistics giant, Yoram spent three months and fixed a great deal. And their people asked for the product every single day we were on site. The demand was never in question.

They never got it. What they got was a spreadsheet: long stretches of SQL nobody could read, a list of what had been done and what hadn't, and an invoice for hours.

The word product meant two different things, and it took us far too long to see it. To Yoram, the product is the surface he works on: tables and execution plans, filtered down to what interests him. That is a genuinely powerful thing to hand a DBA. It is not a thing you can hand a CTO.

So for thirty days David sat there and did the missing half by hand — taking Yoram's output and turning it into structured, readable reports the customer could actually act on. It worked. It also cost a great deal of unpaid time, which is exactly why he stopped: you cannot bill hours for the part that should be software.

But those thirty days bought the thing this company was actually missing. Not a customer, and not a spec anybody handed us. An understanding of what the report needed to contain, learned the only way it can be learned — by producing it manually, badly, until it was right:

• the problem, and the fix;
• the risk of doing nothing — is this going to hurt me, and when;
• the risk of doing it — can a junior run this, or does it need a senior? Does it need staging and testing first? Can it be rolled back?
• the explanation, and the proof;
• and a history to show management, so someone can demonstrate that things are getting better.

When David stopped producing that by hand, the output went back to being Yoram's working surface. And the CTO cancelled.

"You really improved the system here in three months, and it's in a better state. But we don't understand what you're telling us, so we can't continue working with you."

He wasn't wrong. The value was real, and it was illegible. That is a product problem, not a database problem — and we had been billing by the hour for a thing they were ready to buy outright.

That list above is the specification we have been building against ever since. It is why a dbexpertAI finding today carries a severity, a resolution path with a risk level and a rollback, a note on whether it's reversible and how long it takes, the evidence and the queries behind it, and reports you can put in front of your own management. Nobody wrote that spec down for us. We paid for it in unpaid hours, and then in four years of building.

The proof that the demand was real

Next came a proof of concept at a national electricity provider, running the first front end David built out of everything the logistics engagement taught us. It wasn't good enough yet, so we didn't take it to a sale. We also put it in at a national retail chain.

The pattern never changed: people who saw it wanted it, and we could not give it to them in a form they could use. Their DBA still checks in with David from time to time. He's retired now.

What David actually built

David has spent 23 years in automation and machine learning — the systems that run other systems, and the models that make calls inside them. So he knows precisely where machine learning earns its keep, and where it starts guessing confidently about things it doesn't know. A production database at 3am is firmly the second kind of problem.

His job was never to point a model at Yoram's databases. It was to translate Yoram — from an expert's working surface into something a manager, a junior DBA and a change-review board can all read off the same page:

• A taxonomy — and then the detection paths themselves. Yoram's atomic units — he called them metrics — became a structured vocabulary of root causes and detection steps. David wrote and tested the paths that run on it: with AI assistance first, then on real production servers, with real DBAs. Yoram builds decision trees on top of them and runs them in production. A private thicket became something you can reason about, test, and extend.
• Resolution steps, as a deliverable. Because that is what customers were already paying for: the problem, the evidence, and the fix, handed over for their own team to apply.
• A gate. Nothing ships on a hunch. Additions go through a testing process and are hashed and signed before release. If it isn't signed, it doesn't ship. Expert intuition is where a detection path starts; it is not where it ends.

That last one is the part we'd defend hardest. The reason you can trust a dbexpertAI diagnosis isn't that a brilliant DBA stands behind it. It's that the reasoning was written down, tested against real production databases, signed, and shipped with its evidence attached — so you can check it, instead of trusting anyone. Including us.

And we'll say the unfashionable part out loud: the detection paths were written with AI assistance. We build with AI; pretending otherwise would be exactly the sort of thing this page exists to avoid. What matters is the line we draw after that — they are tested on real servers by real DBAs, signed before release, and then executed with no model in the loop at all. AI helped write them. Nothing guesses when they run.

Which is also the honest division of labour between the two of us. Yoram is the one who knows what to look for and can get to an answer faster than anyone we've met. David is the one who makes that reliable enough to put in someone else's production estate. Neither half is the product on its own. That was the whole lesson.

Why you're only hearing about us now

Two to three years ago the two of us stopped treating this as Yoram's side project and started building it properly. David Shalts joined a year ago to run the commercial side.

Yoram wanted to keep going out to customers — more engagements, more sites, the way he always had. David wouldn't do it. No more of that until we had actually built the thing customers had already told us they would pay for. The specification had been handed to us twice, in plain language, by people ready to hand over money. Walking back in with anything less would have wasted their time and ours.

So we went quiet and built it. Vetted detection paths. Root causes and resolution steps that arrive together, with the evidence and the queries attached. A signing gate so that what ships is what was tested. It is now installed at Beit Balev.

Now it's ready.

Get in touch

Founders answer email faster than support queues: the contact page goes straight to David. If you're evaluating dbexpertAI for a serious estate, you'll be talking to the people who built it — and Yoram gets pulled in the moment the question is one for a DBA with 35 years of scar tissue.