[HN Gopher] Show HN: GoatDB - A lightweight, offline-first, real...
___________________________________________________________________
Show HN: GoatDB - A lightweight, offline-first, realtime NoDB for
Deno and React
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!
Author : justagoat
Score : 57 points
Date : 2025-02-25 16:56 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| rglullis wrote:
| What is the story for querying? Can it filter and rank objects?
| ofriw wrote:
| 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
| tkone wrote:
| 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/
| agrippanux wrote:
| But how many goats does pouchdb have? I'm betting 0.
| tkone wrote:
| you can fit a lot of goats into a pouch, depending on the
| size of the pouch
| stuartjohnson12 wrote:
| "A pouch is most useful when it is empty" - Confuseus
| usuck10999 wrote:
| why do anything amirite
| creshal wrote:
| 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
| ofriw wrote:
| Scale really. GoatDB easily handles hundreds of thousands of
| items being edited in realtime by multiple users
| tkone wrote:
| so can couch/pouch? (pouch is a facade 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.
| CyberDildonics wrote:
| Hundreds of thousands of items and multiple users could be
| done on a $5 PI zero 2 w (1Ghz quad-core A53) with the C++
| standard libary and a mutex.
|
| People were working at this scale 30 years ago on 486 web
| servers.
| koolala wrote:
| 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 wrote:
| 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 wrote:
| I'm a bit confused, if it runs in the client why does it
| require deno?
| ofriw wrote:
| It's a symmetric design that runs on both the client and
| the server
| sgarland wrote:
| > 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 wrote:
| In the age of docker anything almost anything can be a single
| file binary if you don't mind pushing gigs of data around.
| ofriw wrote:
| Have you tried using SQLite in the browser and have it play
| nice with a DB in the back?
| sgarland wrote:
| 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.
| ofriw wrote:
| 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
| gr4vityWall wrote:
| 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.
| nexuist wrote:
| This is clearly intended for use in web applications so a JS
| runtime comes for free and the package is only 8.2kb
| gr4vityWall wrote:
| 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 wrote:
| Similar effect, completely different tech. GoatDB is not
| another b-tree wrapped as a DB, but a distributed, replicated,
| commit graph similar to Git
| theultdev wrote:
| This is nice as long as your data doesn't exceed allowed memory.
| ofriw wrote:
| 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
| monideas wrote:
| I was thinking about CRDTs last night and now this. This is
| awesome.
___________________________________________________________________
(page generated 2025-02-25 23:01 UTC)