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

Posted by Funny-Anything-791@reddit | programming | View on Reddit | 9 comments

We 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: - Opening large repositories can take longer if everything stays in memory (we’re exploring a zero-copy format to address that). - Simple reads and incremental queries can be blazingly fast, especially with concurrency and real-time syncing. - 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!