Show HN: SQLite vs. GoatDB: Surprising Benchmark Results for a New Realtime NoDB
goatdb.devWe introduced GoatDB just three weeks ago and have been blown away by the community’s response. Your feedback and excitement genuinely exceeded our expectations—so first and foremost, thank you from all of us!
For anyone just hearing about it: GoatDB is a real-time, version-controlled NoDB for Deno and React that’s edge-native, meaning it requires only minimal backend infrastructure without heavy server components. It’s designed for prototyping, self-hosting, single-tenant apps, and even ultra-light multi-tenant setups if you want to keep your backend minimal.
One of the biggest requests we heard was, “Where are the benchmarks?” We’re thrilled to share them now. The numbers tell an interesting story: in some tests, our distributed-commit-graph architecture can be significantly slower than SQLite; in others, it’s surprisingly faster. This is what happens when you put synchronization and collaboration first (instead of disk I/O). But let’s be crystal clear: GoatDB isn’t a drop-in SQLite replacement. It has a fundamentally different architecture designed for real-time distributed scenarios and cryptographic auditing, so it comes with its own unique tradeoffs.
Key Takeaways:
- Simple reads and incremental queries can be blazingly fast , especially with concurrency and real-time syncing.
- Opening large repositories can take longer if everything stays in memory (we’re exploring a zero-copy format to address that).
- It’s not just a SQLite wrapper—this is a fundamentally different approach with its own unique tradeoffs.
We’ve documented how to run these same benchmarks in our documentation if you’re curious. Once again, thank you so much for the excitement and support. We’re a small team on a mission to reimagine what a lightweight database can do, and your feedback keeps us inspired. We can’t wait to see what you build with GoatDB!
Checkout our Github Repo: https://github.com/goatplatform/goatdb
Not surprising that it is faster if you first load the entire thing in memory, but why then use a DB?, and not have your app just keep the data in memory?
Because you still need to save it, back it up, and share it with others who will likely want to do the same