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!
madman1969@reddit
Hmmm, "with its own unique tradeoffs" seems a tad hand-wavy for my tastes.
Is it web-scale :)
Funny-Anything-791@reddit (OP)
Here the detailed benchmark results, and you're more than welcome to replicate them in your own environment :)
And no, we're not yet web scale, but are getting there soon. We're working on some upcoming improvements and benchmarks that'd demonstrate web-scale deployments and compare to other NoSQL systems
Enip0@reddit
I know I can Google this but what's a "noDB"? Is it a "not database" that "not saves" data or something?
(second sentence is a joke, I'm legit interested in learning what a noDB is)
No-Concern-8832@reddit
I'm confused as well. I wonder if they meant NoSQL, nodb is literally just files. TBH goatdb looks like a document db. It would make more sense to benchmark it against redis or mongo.
Funny-Anything-791@reddit (OP)
You're absolutely right. Conceptually GoatDB is to SQLite what Mongo is to PostgreSQL. Similar architectural tradeoffs in principal
Funny-Anything-791@reddit (OP)
To its user, a NoDB feels kinda like a DB and will probably replace one, but internally it's built differently than traditional DBs. Specifically GoatDB is more like realtime version control for data than a true database (think git for your application's data)
usernamedottxt@reddit
I think it’s meaning that is can run entirely client side in the browser using the browser cache as a DB.
It can then sync changes to server side DB when it comes available.
backfire10z@reddit
It runs client side. There is no dedicated db instance.
reshef@reddit
I’ve heard it as shorthand for non-relational database, but that doesn’t seem to be what this is?
Maybe it’s shorthand for in-memory dbs?