Database administrators used to be the engineers who knew a system’s internals cold—reading query plans, planning capacity, and spotting trouble before it became an outage. As that specialized role has faded from most engineering teams, the responsibilities haven’t disappeared; they’ve simply been absorbed by developers and SREs who are already stretched across a dozen other priorities. NeverBlink was built to close that gap, packaging deep, engine-specific database expertise into a platform designed to watch clusters continuously, diagnose problems at the root, and hand engineers a fix—without ever touching production itself.
In this Q&A, NeverBlink CEO Itamar Syn-Hershko walks through what sets an “AI Database Administrator” apart from generic observability tools or general-purpose LLMs, why the company just added support for ClickHouse, and how NeverBlink decides which database engines to tackle next. He also digs into the real-world payoff for engineering teams: fewer incidents, meaningfully lower database costs, and significant time savings that let developers get back to building product instead of firefighting infrastructure.
++
VMblog: NeverBlink claims to be the world’s first AI Database Administrator. Can you give us some more information on what that means?
Itamar Syn-Hershko: A DBA was never just someone who watched dashboards. They knew the engine deeply: analyzed query plans, reviewed schemas, planned capacity, looking for potential problems before they became outages, and could tell you why something broke, not just that it did. That role has largely disappeared from modern engineering teams, but the work didn’t disappear with it, it just landed on developers and SREs who have twenty other jobs. When the AI revolution hit, this became an even bigger issue; now everyone is expected to do more with less, and engineers are closer to production than ever before, deploying databases, writing custom queries and making schema changes.
NeverBlink is that role rebuilt as a product. The AI does the continuous investigation: it watches every cluster around the clock; correlates metrics, logs, queries, and configuration; diagnoses root causes and hands your team the fix, often down to the exact SQL. What makes it a DBA rather than another monitoring tool is that it carries real engine-specific expertise, it explains its reasoning on every recommendation, and it never touches production on its own. Engineers stay in control of what gets applied.
VMblog: Why do companies need a dedicated platform to manage their databases? Can’t they just use traditional observability solutions perhaps combined with LLMs?
Syn-Hershko: Observability tools are deliberately generic, and they are mostly graph-based. Looking at a dashboard and seeing some spikes is one thing; understanding if it’s a problem or not, what caused it if it is, and what is the fix is another.
Grafana can show you a rising line; it can’t tell you that a growing part count means ClickHouse is about to throttle your inserts, or that a merge backlog is a workload problem rather than a CPU problem. The knowledge of which fifteen metrics out of a thousand actually predict outages – and what to do when one turns red – isn’t in the dashboard. It’s in the heads of specialists most teams can’t hire.
As for pointing an LLM at your database…databases are mission-critical, and there’s no wiggle room for hallucinations, and no shadow mode to protect you from AI slop. A raw LLM has no ground truth about your cluster’s state, no engine-specific diagnostic method, no history tacking, context and speciality, and no accountability.
NeverBlink is different by construction: purpose-built watchers for how each database engine actually fails, analysis grounded in live data from the cluster itself, reasoning attached to every recommendation, agentic playbooks that were crafted by actual experience, and a hard rule that nothing changes production without an engineer’s decision. We complement observability tools rather than replacing them. An alert in PagerDuty or Datadog will contain our analysis and a link back to us to complete the in-depth diagnosis and remediation.
VMblog: NeverBlink just announced support for ClickHouse. Can you explain why you chose to focus on that technology?
Syn-Hershko: Two reasons.
First, adoption: ClickHouse has become the default engine for real-time analytics, powering demanding workloads at companies like Anthropic, Meta, Tesla, and Lyft, and increasingly sitting directly behind customer-facing dashboards. More and more of the teams we work with run it alongside their search and transactional databases; and they added 1,000 new customers in early 2016 alone.
Second – and this is the interesting part – ClickHouse has a tendency to fail quietly. When it stalls, everything might still look fine on the dashboards. Inserts get quietly throttled before they fail. A materialized view drops data mid-insert and every rollup downstream under-counts. Replicas serve stale data by default rather than erroring. Nobody gets paged for any of it – teams find out weeks later when a customer asks why the numbers don’t match. That gap between “looks healthy” and “is healthy” is exactly what NeverBlink was built to close, which made ClickHouse a natural next engine after Elasticsearch and OpenSearch.
VMblog: How does NeverBlink approach each database it chooses to support? For example, is building support for ClickHouse totally different from building support for say Postgres?
Syn-Hershko: The platform is shared – the collector architecture, the health scoring, alerting, query analytics, the recommendation engine, the guardrails, etc. And then for every new engine we support, we encode how it actually breaks in production, and of course all the tools to help diagnose it before and after. This is knowledge that comes from many years of running and rescuing these systems for customers. That’s why we add engines deliberately rather than announcing twenty integrations at once.
VMblog: What are the primary value drivers of the NeverBlink platform? What is it helping teams accomplish that would be difficult to do without it?
Syn-Hershko: First, incidents that never happen: continuous analysis catches problems while they’re still warnings, before customers notice and before anyone gets paged. Second, cost: database spend is driven by a handful of levers: bytes scanned, storage growth, over-provisioned compute “just in case”. NeverBlink customers report 25–30% lower database costs from query optimization, schema fixes, and right-sizing instead of the default answer of scaling up. Third, time: customers report 80-90% less time spent on database management, which goes back into building product.
Underneath all three is a talent problem. Database experts are scarce, expensive, and hard to retain. AI-assisted development is multiplying the load on the data layer, with code, schemas, and queries shipping at machine speed. Teams can’t hire their way out of that. NeverBlink packages that scarce expertise into a platform that’s always on, with real humans behind it when it matters. LinearB is a good concrete example: their customer-facing dashboard queries went from 8 seconds to subsecond, and their engineers stopped worrying about the database daily by using NeverBlink.
##
