Hacker News Reader

ofriwon Show HN: ChunkHound, a local-first tool for understanding large codebases

Exactly. There's an autodoc feature coming up in the next version

ofriwon Show HN: ChunkHound, a local-first tool for understanding large codebases

Fixed, thank you

ofriwon Show HN: ChunkHound, a local-first tool for understanding large codebases

The DB is stored locally, and any embedding, reranker and LLM will work. It's up to you if you self host these or bring them externally from one SaaS or the other

ofriwon Show HN: ChunkHound, a local-first tool for understanding large codebases

`chunkhound search <query>`, `chunkhound search --regex <query>` and `chunkhound research <query>` are the main cli entry points that you can already use today

ofriwon Show HN: ChunkHound, a local-first tool for understanding large codebases

Completely free, MIT licensed. You can fully self host it if you have the hardware to run Qwen3-embedding and reranker models

ofriwon Show HN: ChunkHound, a local-first tool for understanding large codebases

Just add to your prompt something like "use code research", but yes there's a PR in the works that fixes that and optimizes the MCP tools interface - https://github.com/chunkhound/chunkhound/pull/150

ofriwon Show HN: ChunkHound, a local-first tool for understanding large codebases

ChunkHound does it a bit differently, since at true enterprise scale it's very slow and costly to pass all code chunks through an LLM during indexing time. Instead, ChunkHound implements a customized "deep research" algorithm that's been optimized for code exploration so it can answer, on demand, any deep technical question about the indexed codebase. This research agent can be powered by a lower tier LLM (think Haiku, Codex low, etc) that's already included in your subscription.

ofriwon Show HN: ChunkHound, a local-first tool for understanding large codebases

Thank you, yes the docs are overdue for a refresh. It's in the works

ofriwon AI software factory built a dev tool – and indexed itself

It also supports OpenAI compatible embeddings server if you have a local one lying around

ofriwon Show HN: SQLite vs. GoatDB: Surprising Benchmark Results for a New Realtime NoDB

Because you still need to save it, back it up, and share it with others who will likely want to do the same

ofriwon Show HN: GoatDB – A lightweight, offline-first, realtime NoDB for Deno and React

Things that can be done millions of times per second per core don't "introduce delays" that a handful of people are going to see.

Oh but they can't. If you tried it, then you surely know that both OT and CRDTs need to consider the entire change history at some key points in order to derive the current value. Diff sync doesn't suffer from the same issue, however the way it keeps track of client shadows introduces writes on the read path, making it horribly expansive to run at scale.

Are you seriously trying to say that the database you created in a scripting language that uses linear scanning of arrays is 'unmatched' compared to high performance C++?

It's not about the language, but about the underlying algorithm. Yes, JS is slower, and surely linear scan is slower than typical DB queries. But what GoatDB does, which is quite unique today, is it's able to resume query execution from the last point a query ran, so you get super efficient incremental updates which are very useful when running on the client side (clients tend to issue the same queries over and over again).

ofriwon Show HN: GoatDB – A lightweight, offline-first, realtime NoDB for Deno and React

Yup. Go ahead and try it, then you'll discover that:

- The queue introduces delays so this doesn't play nice with modern collaborative editing experience (think google docs, slack, etc)

- Let's say change A set a field to 1, and change B set the same field to 2. GoatDB allows you to easily get either 1, 2 or 3 (sum) or apply a custom resolution rule

Your only choices before goat to solve this were: Operational Transformation, raw CRDTs or differential synchronization. GoatDB combines CRDTs with commit graphs so it can do stuff other approaches don't at an unmatched speed

ofriwon Show HN: GoatDB – A lightweight, offline-first, realtime NoDB for Deno and React

Your server/network goes down, but you still want to maintain availability and let your users view and manipulate their data. So now users make edits while offline, and when they come back online you discover they made edits to the same rows in the DB. Now what do you do?

The problem really is about concurrency control - a DB creates a single source of truth so it can be either on or off. But with GoatDB we have multiple sources of truth which are equally valid, and a way to merge their states after the fact.

Think about what Git does for code - if GitHub somehow lost all their data, every dev in the world still has a valid copy and can safely restore GitHub's state. GoatDB does the same but for your app's data rather than source code

ofriwon Show HN: GoatDB – A lightweight, offline-first, realtime NoDB for Deno and React

Doing concurrent editing AND supporting offline operation?

ofriwon Show HN: GoatDB – A lightweight, offline-first, realtime NoDB for Deno and React

Right. But how do you scale it?

ofriwon Show HN: GoatDB – A lightweight, offline-first, realtime NoDB for Deno and React

Yup. Conflict free grazing everywhere

ofriwon Show HN: GoatDB – A lightweight, offline-first, realtime NoDB for Deno and React

A few things which are not a big deal, but do require some work:

- Back when we started, only Deno had the ability to compile to a single exec

- We're using deno's module resolution which is superior in every way (with an ESBuild plugin)

- Deno's filesystem API

All of the above can be implemented for other runtimes, and it's definitely on our roadmap

ofriwon Show HN: GoatDB – A lightweight, offline-first, realtime NoDB for Deno and React

Cons: less mature, much newer tech based on ephemeral CRDTs combined with a distributed commit graph. Less mature ecosystem, tooling, etc.

Pros: - Branch based deployment so multiple versions can coexist nicely in prod - Completely synchronous API that fully hides the networking - Clients can securely restore a crashed server - Your DB functions as a signed audit log that prevents cheating (similar to blockchain) - Stronger consistency guarantees that simplify development

ofriwon Show HN: GoatDB – A lightweight, offline-first, realtime NoDB for Deno and React

Thank you for the kind words it really motivates us!

ofriwon Show HN: GoatDB – A lightweight, offline-first, realtime NoDB for Deno and React

It's a symmetric design that runs on both the client and the server

ofriwon Show HN: GoatDB – A lightweight, offline-first, realtime NoDB for Deno and React

Think about the modern cloud-first architecture where you have a thick back with a complex DB, a thin client with a temporary cache of the data, and an API layer moving data between them.

This is an experiment in flipping the traditional design on its head and pushing most of the computation to the client using an architecture similar to what Git is using, but for your actual application data.

You get all kinds of nice byproducts from this design like realtime collaboration, secure data auditing, multiple application versions coexisting on different branches in production, etc etc. It's really about pushing the boundaries of what's possible with modern client hardware

ofriwon Show HN: GoatDB – A lightweight, offline-first, realtime NoDB for Deno and React

Similar effect, completely different tech. GoatDB is not another b-tree wrapped as a DB, but a distributed, replicated, commit graph similar to Git

ofriwon Show HN: GoatDB – A lightweight, offline-first, realtime NoDB for Deno and React

Right. But you can push it a bit further than that actually by explicitly unloading portions of the data to disk kinda like closing a file on a desktop app

ofriwon Show HN: GoatDB – A lightweight, offline-first, realtime NoDB for Deno and React

Have you tried using SQLite in the browser and have it play nice with a DB in the back?

ofriwon Show HN: GoatDB – A lightweight, offline-first, realtime NoDB for Deno and React

Scale really. GoatDB easily handles hundreds of thousands of items being edited in realtime by multiple users

ofriwon Show HN: GoatDB – A lightweight, offline-first, realtime NoDB for Deno and React

Simple. You write plain Ts functions for sorting and filtering. GoatDB runs them with a linear scan in a coroutine so it doesn't block the UI thread. From this point it'll use its version control underpinnings to incrementally update query results

ofriwon Show HN: GoatDB – A lightweight, offline-first, realtime NoDB for Deno and React

Currently only deno (react is optional), but we're working on supporting other frameworks and runtimes.

GoatDB has backends for both OPFS and IndexedDB