Show HN: GoatDB – A Lightweight, Offline-First, Realtime NoDB for Deno and React
25 comments
·February 25, 2025gr4vityWall
Seems like the database is reactive on the client, and React components get re-rendered automatically when content changes.
How does it compare to Minimongo?
ofriw
Similar effect, completely different tech. GoatDB is not another b-tree wrapped as a DB, but a distributed, replicated, commit graph similar to Git
rglullis
What is the story for querying? Can it filter and rank objects?
ofriw
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
koolala
Could this be used without Deno or React, just a vanilla webpage? Can it p2p sync two client databases with WebRTC?
Does it use OPFS or IndexedDB?
ofriw
Currently only deno (react is optional), but we're working on supporting other frameworks and runtimes.
GoatDB has backends for both OPFS and IndexedDB
johnnypangs
I’m a bit confused, if it runs in the client why does it require deno?
theultdev
This is nice as long as your data doesn't exceed allowed memory.
ofriw
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
tkone
Why not just use pouchdb? It's pretty battle-tested, syncs with couchdb if you want a path to a more robust backend?
edit: https://pouchdb.com/
ofriw
Scale really. GoatDB easily handles hundreds of thousands of items being edited in realtime by multiple users
tkone
so can couch/pouch? (pouch is a façade over leveldb on the backend and client-side storage in your browser)
have you done benchmarks to compare the two?
i know from personal experience leveldb is quite performant (it's what chrome uses internally), and the node bindings are very top notch.
agrippanux
But how many goats does pouchdb have? I'm betting 0.
tkone
you can fit a lot of goats into a pouch, depending on the size of the pouch
stuartjohnson12
"A pouch is most useful when it is empty" - Confuseus
null
usuck10999
why do anything amirite
creshal
You can do whatever you want, but if you reach out to other people because you want them to use it, you better be able to convince them why
sgarland
> lighter than SQLite
You’re concerned that a < 1 MiB library is too heavy, so you wrote a DB in TS?
> easier to self-host
How is something that requires a JS runtime easier than a single-file compiled binary?
be_erik
In the age of docker anything almost anything can be a single file binary if you don’t mind pushing gigs of data around.
gr4vityWall
shipping SQLite as a WASM module can increase your bundle size significantly, depending on your baseline.
> How is something that requires a JS runtime easier than a single-file compiled binary?
You can compile your JS to bytecode and bundle it with its runtime if you want to, getting a single-file executable. QuickJS and Bun both support this, and I think Node.js these days does as well.
If you expect your user to already have a runtime installed and you're not using QuickJS, you can just give them the script as well.
ofriw
Have you tried using SQLite in the browser and have it play nice with a DB in the back?
sgarland
No, and admittedly I misunderstood the purpose, but I don’t understand the need any better now. I’m not a frontend (nor backend) dev FWIW, I’m a DBRE.
If this is meant for client-side use, that implies a single user, so there aren’t any concerns about lock contention. It says it’s optimized for read-heavy workloads, which means the rows have to be shipped to the client, which would seem to negate the point of “lighter weight.”
If the purpose is to enable seamless offline/online switching, that’s legitimate, but that should be called out more loudly as the key advantage.
null
null
Hey HN,
We've been experimenting with a real-time, version-controlled NoDB for Deno & React called GoatDB. The idea is to remove backend complexity while keeping apps fast, offline-resilient, and easy to self-host.
Runs on the client – No backend required, incremental queries keep things efficient. Self-hosted & lightweight – Deploy a single executable, no server stack needed. Offline-first & resilient – Clients work independently & can restore state after server outages. Edge-native & fast – Real-time sync happens locally with minimal overhead.
Why We Built It: We needed something that’s simpler than Firebase, lighter than SQLite, and easier to self-host. GoatDB is great for realtime collaboration, offline, prototyping, single-tenant apps, or ultra-low-cost multi-tenant setups—without backend hassles.
Would love feedback from HN:
* Are there specific features or improvements that would make it more useful?
* How do you handle similar problems today, and what’s missing in existing solutions?
If you're interested in experimenting or contributing, the repo is here: GitHub Repo: https://github.com/goatplatform/todo
Looking forward to your thoughts!