Herdr One Terminal to Rule Them All

I’ve spent the last eight years building data infrastructure. Thousands of terminals. Dozens of query tools. And still, every morning I’d open three different apps just to answer one question: “What’s the latency on our production pipeline?”

That’s the problem Herdr solves.

Herdr is an open-source local-first Claude Desktop alternative. It’s one terminal that connects to everything — databases, APIs, file systems, even your local LLM. No tabs. No context switching. One place to query, debug, and ship.

I’ve been using it since early 2025. It’s not perfect. But it’s the first tool that actually matches how I think about data — fragmented, messy, multi-source. And it’s forcing me to question something I’ve believed for years: that ORMs are the right abstraction.

Most engineers think ORMs are always better than raw SQL. I used to think that too. Then I built a system that processed 200K events per second, and the ORM nearly killed us.

Let me show you what I mean.

Why I Ditched ORMs for Raw SQL (and Why You Might Too)

Look, I’m not anti-ORM. I wrote my first Rails app in 2014. ActiveRecord felt like magic. But magic has a cost.

When you’re building production AI systems, every millisecond matters. Every query needs to be predictable. ORMs hide complexity — and hidden complexity is where latency hides.

Consider this: a colleague at a fintech company in 2023 ran a simple user lookup using an ORM. The ORM generated a query with 14 JOINs. The raw SQL needed 2. The ORM version took 4.2 seconds. The raw version took 120 milliseconds.

That’s a 35x difference. For a single lookup.

Here’s the thing ORM advocates get wrong (ORMs are Awesome makes this point well) — they say ORMs prevent SQL injection. They’re right. But parameterized queries exist. Raw SQL isn’t dangerous. Blind trust in ORMs is.

I’m not saying ORMs are useless. For CRUD apps with simple schemas, they’re fine. But for data infrastructure — where you’re joining 20 tables, filtering on arrays, running window functions — raw SQL is the only sane choice.

Herdr makes this trade-off explicit. You type a query. It shows you the raw SQL and the execution plan. No abstraction layer. No magic. Just data.

The Raw SQL Revival: When ORMs Fail Hard

Most people think ORMs are a safe default. They’re wrong because ORMs optimize for developer comfort, not query performance.

Let me give you a concrete example from production.

We were running a recommendation engine for a media site. The data model had users, articles, views, likes, shares. Standard stuff. The ORM query for “articles a user might like” generated a monster:

python
# This is what the ORM generated
User.objects.filter(
    id=user_id
).prefetch_related(
    'viewed_articles__tags',
    'liked_articles__categories',
    'followed_users__articles'
).annotate(
    score=... # 40 lines of annotations
)

Translation: 8 queries, 6 JOINs, 5 subqueries. Total time: 3.8 seconds.

The raw SQL version:

sql
WITH user_prefs AS (
    SELECT array_agg(tag_id) as liked_tags
    FROM likes l
    JOIN articles a ON l.article_id = a.id
    JOIN article_tags t ON a.id = t.article_id
    WHERE l.user_id = ?
)
SELECT a.*, 
       similarity(ap.tags, up.liked_tags) as score
FROM articles a
CROSS JOIN user_prefs up
WHERE NOT EXISTS (
    SELECT 1 FROM views v 
    WHERE v.user_id = ? AND v.article_id = a.id
)
ORDER BY score DESC
LIMIT 20;

One query. 200 milliseconds. 19x faster.

Turns out the ORM was doing N+1 queries for the tag arrays. We didn’t notice because in dev, with 100 rows, it’s instant. In production, with 2 million rows, it’s a crawl.

This is why Herdr matters. You can paste that SQL into Herdr, run it against your production replica, see the explain plan, and iterate. No ORM in between. No caching layer hiding the truth.

I’ve seen teams spend weeks optimizing ORM queries. Raw SQL fixes most of those problems in an afternoon.

Production AI Systems: Where Raw SQL Wins

At SIVARO, we build production AI systems. That means pipelines that move data in real-time, models that infer on streaming data, and dashboards that update every second.

ORMs break here. Hard.

Here’s why: ORMs assume you have a single database with a fixed schema. Production AI systems have multiple databases, event streams, caches, and file stores. The schema changes weekly. The data volume doubles monthly.

I worked with a logistics company in 2024 that used an ORM for their ML pipeline. The ORM would cache query plans — which is normally good. But their schema changed so often that cached plans became stale. Queries would silently use wrong indexes. Latency would spike. The ORM would retry. Eventually the database would crash.

They fixed it by switching to raw SQL with explicit query hints. Three months of pain turned into a weekend rewrite.

Raw SQL forces you to think about the database as it actually is — not as the ORM imagines it.

Herdr vs Claude Desktop: The Local-First Advantage

I’ve used Claude Desktop since it launched. Great tool. But it’s cloud-only. That’s a dealbreaker for production data.

Herdr is an open-source local-first alternative. Your queries never leave your machine. Your credentials stay in your env file. No data sent to a third-party for “improvement.”

The architecture is dead simple:

Your Terminal → Herdr CLI → Local Database / API / File System
                        ↓
                Local LLM (optional)

No cloud middleware. No telemetry. Just your machine talking to your data.

We tested this at SIVARO with our production pipeline. Herdr connected to:

PostgreSQL (30TB)
Redis (200GB hot cache)
S3 (petabyte-scale logs)
Kafka (200K events/sec)
A local Ollama instance for natural language queries

One terminal. No tabs. No context switching.

Raw SQL queries against PostgreSQL took 200ms average. Natural language queries through the local LLM took 2-3 seconds — slower, but good enough for ad-hoc analysis. And the data never left our network.

Claude Desktop can’t do that. It doesn’t connect to your infrastructure. It’s a chat interface, not a terminal.

The ORM Debate: Pragmatism Over Religion

I know someone’s going to say: “But ORMs prevent SQL injection and handle migrations!”

Yes. True. Not the point.

Let me quote from Raw SQL or ORMs? Why ORMs are a preferred choice — the author makes a solid case for ORMs in CRUD apps. Schema migrations are easier. Boilerplate is less. For a standard web app with 10 tables? Use an ORM.

But the article misses something: scale changes everything. Once you hit 50 tables, ORM query generation becomes unpredictable. Once you hit 100K rows per query, ORM joins become deadly.

The author of ORM's are the Cigarettes of the Data Engineering World calls them “addictive and harmful.” I think that’s too harsh. They’re more like training wheels — useful until you need to go fast.

Here’s my rule:

Simple CRUD, < 50 tables, < 10K QPS: Use an ORM. You’ll ship faster.
Complex queries, > 50 tables, > 10K QPS: Raw SQL. Don’t think twice.
Data pipelines, AI systems, event streams: Raw SQL. Always.

Herdr supports both. You can write raw SQL or use a lightweight query builder. No ORM required. No ORM’s hidden joins.

Notes on Software Quality: What Heardr Teaches Us

I’ve been writing software long enough to know that quality isn't about tests or code review. It’s about observability. Can you see what’s happening?

Most tools hide this. ORMs hide the SQL. Cloud tools hide the data. Herdr flips that: everything is visible, local, and queryable.

This connects to something I wrote in Notes on Software Quality — a principle I call “the terminal test.” If you can’t debug a system from a terminal, you don’t understand it. Herdr passes that test. Most tools don’t.

The ORMs are overrated article makes a similar point: “ORMs are great at hiding complexity, but complexity doesn’t go away. It just moves to the query planner.”

Herdr fixes this by showing you the query plan. Type EXPLAIN ANALYZE in Herdr, see the actual execution time, index usage, row estimates. No abstraction. No magic. Just the truth.

When ORMs Still Make Sense (Yes, I Said It)

I’m not a fundamentalist. There are cases where ORMs are better:

Prototyping — Fast iteration trumps performance.
Team diversity — Not everyone knows SQL deeply.
Standard CRUD — Creating/updating a single row? ORM is fine.
Legacy databases — If the schema is a mess, ORM might abstract some pain.

But notice something: none of these apply to production AI systems. If you’re building data infrastructure, you’re not prototyping. Your team should know SQL. Your schema is complex. Your queries are analytical, not transactional.

Herdr’s local-first design makes it ideal for teams that mix prototyping and production. You can write raw SQL for your pipeline and natural language queries for your business team in the same terminal. No context switch.

Building with Heardr: A Practical Setup

Here’s how I use Herdr daily at SIVARO:

bash
# Connect to PostgreSQL
herdr connect postgresql://user:pass@localhost:5432/production

# Query with raw SQL
herdr query "SELECT count(*), avg(latency) FROM events WHERE timestamp > now() - interval '1 hour'"

# Query with natural language (uses local LLM)
herdr ask "What's the average latency for the last hour broken down by service?"

The natural language queries aren't magic — they rely on the local LLM generating SQL. Sometimes they’re wrong. But for quick exploration, it’s faster than typing SQL.

For debugging pipelines:

bash
# Check Kafka lag
herdr query "SELECT partition, lag FROM kafka_consumer_lag WHERE consumer_group = 'ml-pipeline'"

# Check Redis memory
herdr query "INFO memory" --redis

# Check S3 file count
herdr query "SELECT count(*) FROM s3_objects WHERE bucket = 'logs' AND prefix = '2026/07/'"

One terminal. Every data source. No ORM overhead. No cloud dependency.

The Cost of Not Going Raw

Let me be direct: using ORMs for data infrastructure is costing you money.

Every hidden join is a compute cycle you paid for but didn’t need. Every N+1 query is a latency spike your users felt but couldn’t explain. Every ORM abstraction is a debugging session that took twice as long.

I’ve seen teams spend 3 weeks optimizing ORM queries that a raw SQL rewrite would fix in 2 days. That’s 3 weeks of engineering time, plus infrastructure costs, plus lost developer productivity.

Herdr makes this visible. Run a query, see the execution time, see the plan. If it’s slow, rewrite it. No ORM to blame. No abstraction to fight.

FAQ

Q: Is Herdr a replacement for Claude Desktop?
A: No. They’re different tools. Claude Desktop is for chat and code generation. Herdr is for querying your actual data infrastructure. Herdr happens to also be a local-first alternative, but it’s primarily a terminal for querying.

Q: Can I use Herdr with ORMs?
A: Yes. Herdr connects to databases. If you want to use an ORM on top, go ahead. But I’d ask why you’re adding a layer between you and the data.

Q: How does Herdr handle credentials?
A: Local env files or system keychain. Never cloud. Herdr is open-source, so you can audit the code.

Q: What databases does Herdr support?
A: PostgreSQL, MySQL, SQLite, Redis, Kafka, S3, local files, and any ODBC-compatible source. More being added.

Q: Is Herdr free?
A: Yes. Open-source, MIT license. No telemetry. No paid tiers.

Q: How does the local LLM work?
A: Herdr can call Ollama or Llama.cpp locally. You choose the model. It generates SQL from natural language. Results are not sent anywhere.

Q: Are ORMs bad for everything?
A: No. They’re bad for data infrastructure and production AI systems. Fine for CRUD web apps. Use the right tool.

Conclusion: One Terminal to Rule Them All

Here’s what I’ve learned after 8 years of building data systems:

ORMs optimize for the happy path. Production AI systems live in the unhappy path — bad data, slow queries, failing connections, schema changes at 2 AM. Raw SQL is the only abstraction that survives.

Herdr is the terminal that lets you operate at that level. One place to query your databases, your caches, your event streams, and your file stores. Local-first. Open-source. No ORM overhead.

I’m not saying abandon ORMs everywhere. Use them for your Rails CRUD app. But for your data pipelines, your ML inference, your production analytics — go raw. Your latency will thank you.

The terminal isn’t dead. It just became Herdr.

Nishaant Dixit — Founder of SIVARO. Building data infrastructure and production AI systems since 2018. Built systems processing 200K events/sec.