I remember a friend showing me some stuff about this when they were still trying to pursue the MMORPG route and I am surprised this company is still alive given the amount of unnecessary overengineering that went into that effort.
The model of putting ECS like logic as code and putting all that code as stored procs solves a handful of db transaction issues that none of the major mmorpgs really had issues with 20 years ago when mmorpgs were all the rage and when computers were 100x-1000x slower than today. A lot of engineering is going to solving and cutting out these database round trips that were not even an issue 20 years ago and even less of an issue today.
On the other hand the actual hard parts about building a multiplayer game, such as roll back, physics, collisions, all of that sort of stuff, well this actually doesn't really help with any of that. If anything it makes all of those things even more difficult. I imagine that the developers of this game probably had to come up with some pretty interesting hacks that probably didn't benefit from their DB to get anything resembling physics to work.
Layered on top of that are the known anti-patterns around using stored procs within databases, which spacetimedb does't address at all. You can't really run your tests just on your client because the application logic is split between client and db-server leading to spaghetti code and poor iteration cycles for game design. The database itself also doesn't horizontally scale beyond a single node.
Just take a peek at the steam reviews for BitCraft. The recent ones are actually pretty scathing and it seems like, despite all this engineering, the developers haven't really listened to their playerbase. With all of this effort centered around building a custom database, users still can't, say, build homes for themselves in this game, something that you can certainly do in probably most all other MMORPGs.
I think this will go down as a cautionary example of not listening to your users and spending engineering effort on the wrong types of problems. I think one of the most important skills for an engineer is actually not just having good technical ideas but knowing the right types of problems to solve and, most importantly, listening to your audience, your users, and your stakeholders. I wish the developers the best of luck and hope they can pivot successfully.
I'm almost confident the architecture is the result from some kind of pivot from blockchain gaming.
Previously they talked about "testnet" and you use "energy credits" to pay for services. They also described aspects as being similar to smart contracts.
Naming the game "Bitcraft" circa 2021 is a big tell as well
Oh I'm sure it very enjoyable. This is more on the question of "could it have been a better game with better reviews" if more time had been spent on gamedev versus spacetimedb?
I suspect the answer to that is probably nuanced. Spacetime probably gets more VC funding based on the DB rather than being a game. Trying to make a successful indie MMORPG without pre-existing IP is going to be an uphill battle in 2026 with or without fancy backend innovations.
The SpacetimeDB launch video came up on my YouTube feed - and I was surprised the video didn't go at all into how it was implemented. I assumed it was proprietary magic, but then I was surprised to find it was opensource. That confused me more - to get the kind of semantics they were talking about I had assumed that it was pretty novel and if it was open source they should be leading with that.
Kind of bummed to see its essentially 2015-era React Flux in Rust around a mutex.
Notably, single threaded execution is optimal for performance here. If you don't believe us, maybe you'd believe TigerBeetle which is also single threaded by design.
"Because the system is, well, a hash table with a lock in front of it."
This actually surprises me? I was a very early employee/contractor working on this product but left after 3 months. But this wasn't the shape it had when I was there. It would have been better described as a CoW tree of various sorts, which lets reads and writes advance on separate transactions and reconciles at commit with what I recall was fairly minimal lock-holding time.
When I was there there was no global lock being held while a WASM "reducers" was executing. They operated on their own separate transaction in their own thread.
I haven't looked at their source since -- and I really don't want to because I work on similar things I don't want IP contamination as last I looked they had some sort of weird license -- but there's been .. 3 years? of development on it since and I know Tyler well enough and he hired smart-ish people.
I had a lot of criticisms of what he was making and the way it was being made... but ehh....I would want to confirm in source that this claim is accurate, it makes me a bit suspicious of the accuracy and fairness of the rest of TFA.
Ok, so I had a clanker go look. It actually sounds as bad as the article says. For some reason they apparently lock things while "reducer"s are running.
Robot brain summarized:
"Your historical description may be completely accurate.
Your request that the author substantiate the claim was warranted.
But the source substantiates it extremely clearly.
The blog’s concurrency conclusion is right.
Its “hash table,” fairness, “cannot sync WAL,” and “questionable to call it a database” language is deliberately contemptuous and sometimes technically sloppy."
I think you mean it sounds as good as the article says it is. SpacetimeDB is single threaded by design, just like TigerBeetle by the way. The reason we changed from MVCC to single threaded design is that it's simply faster for almost all workloads. Measurably so! With MVCC we were doing more bookkeeping than actual work and perpetually causing cache coherency issues.
"Technically sloppy" is an understatement. The article just gets several things plan incorrect about the durability guarantees, etc.
The article says that we don't provide strong durability guarantees. Pure ipse dixit. And IIRC he's already cleaned it up a little.
The shamelessness with which people published bogus claims about SpacetimeDB after this was really really astonishing. And so many were quick to dismiss the overall results based on some handwaving arguments. I wasn't prepared for it.
We should have held off on publishing until we had a deep technical blog on the subject.
It seems like an odd choice perhaps, but I had the numbers to prove that it was simply measurably worse overall performance for most OLTP workloads.
IIRC, we don't let pure reads read the committed state while a transaction is underway. We can certainly do that in the future, but we're so far out ahead of typical database performance for most OLTP workloads we haven't even bothered.
I watched a few of their talks, and while I'm somewhat impressed by the results, it's not exactly surprising to me that you can get those numbers when you make the trade-offs they're making. Most applications cannot make those trade-offs and, thus, cannot ever hope to see those numbers. The lack of rigor in database benchmarking in any of the videos I saw was an obvious indicator of something to be wary of.
I appreciate the article from a technical perspective. Is there anyone here who has used it in production regardless of the criticism and has some perspective to share on where it actually falls flat or situations where performance degrades massively? Them having built an MMO around it makes it look like the technical limitations around this pattern might(!) only matter for very specific workloads or for poorly implemented reducers - and my gut feeling is that you can also reach for postgres or sqlite and write very inefficient queries that quickly bog your system down as well. Just curious how it stacked up in the real world.
I’ve been following for a bit, but have intentionally avoided using it. It’s prob fine for vibe coders (increasingly seems to be their target) and proof of concept work.
There seems to have been a fair bit feature churn across their whole stack. I’ve seen a fair few projects and tooling fizzle out cuz of the moving targets. It’s not really clear what is long term stable.
There is a lot of over promising and under delivering (features advertised in their 1.0 still not here). They own your whole stack, so deviating from what they provide is an unhappy path. If you need something beyond what is in their current feature set (not what is promised!) then you will probably have an easier time constructing such a system out of the hundreds of open-source components built for modular construction.
Their hosting has not been stable (no LTS either, so you are forced to live on the edge of their deploy schedule). Limited hosting options (only US iirc). Migrations and long term management don't seem to be in a great state either (external tooling needed). Trying to escape their stewardship and selfhost leaves you with a restrictive license…
It seems they are trying to follow in Michael Stonebrakers footsteps, first with copying VoltDB and now DBOS. It’s not clear what their priorities are, when they haven’t yet delivered a single solid product yet.
I do not really see how their business model is any different than VoltDB which was also open source with gated features. The VoltDB community died off for this reason, not sure why we would expect anything different to happen here. Unless they change their license, I would not expect a thriving community like Postgres or SQLite/LibSQL
There’s also an excellent paper called “Fair Benchmarking Considered Difficult:
Common Pitfalls In Database Performance Testing”.
Benchmarks are genuinely hard. Modern systems and hardware are notoriously complex and have different behaviors across runs and with minor tweaks to performance settings.
Yep, absolutely... and in the end benchmarks aren't going to sell a database anyways. Reliability and provable correctness and ease of integration are probably going to win in the end. It's a dubious marketing edge to lead with.
PostgreSQL itself is remarkably slow in many configurations and leaves a lot of performance on the table due to its architecture and assumptions. But it works and people trust it. So they use it.
As a SpacetimeDB dev, I absolutely agree. Reliability, provable correctness, and ease of integration are higher priority than performance. That doesn't mean we need to accept garbage performance though.
Broadly enjoyed my read, though I do have a nitpick here:
>The absence of side effects or stalls cannot be enforced by the type system ...
Side effects is probably correct, but stalls would imply wasm code that calls out to a long-time blocking function - that's generally quite easy to type-system-ify, and wasm stuff often does so with promise-like constructs. So there would be a need for spacetimedb-side markers for "this func might do HTTP", but that kind of marker for WASM-contact-able code is very much a normal expectation.
If they don't have that kind of marker, and do allow blocking calls in their beta API, then yeah - huge problem with that kind of internal structure (shared global lock), completely agreed.
Doesn't really cover the types used in the beta APIs. Nor would I expect it to though.
Is there a more technical explanation post somewhere? I'm definitely curious how it works, and I like the core idea quite a bit - I'm fairly convinced that WASM uses like this are going to grow immensely, and "it's just a global mutex/single thread" reduces complexity so much that it's always interesting to see where it's possible to use.
The latency+throughout brings many questions though, like "are you holding responding to writes and any reads that occur after until changes are written to disk" and "if so I kinda assume that change log is constantly streamed to disk with a moving high water mark for responses". I can generally see how that'd hit such benchmarks, especially with non-dirty reads being near instant, but details are always interesting.
Is there anything on how a multi-node cluster works (I'm kinda assuming there's something since it makes "single" mentions a few times)? Application-level sharding is always an option (and multiple things I've worked on have used it to great effect), but anything automatic seems likely gnarly and fun to learn about, if it recovers some of the naive perf loss of "just hold the lock while doing rpc to other nodes".
Has anyone benchmarked it against Volt Active Data yet?
They seem comparable in premise and further along in development.
For as long as I’ve known about SpacetimeDB the premise seemed to have its uses, but I don't really trust how new it is nor all the weird marketing behind it
Very cool watching late stage software shops undiscover n tier architecture. Of course, breaking from hard learned wisdom for niche use cases is fine… until you bury the reality in a misleading and edge lord-ish PR sweep.
Leading with unfair benchmarks is the fastest way to lose credibility in the database space. The companies that last are the ones doing honest technical work.
As a SpacetimeDB dev, I absolutely agree. However, these benchmarks are more than fair. Please read our full technical writeup on the benchmarks: https://spacetimedb.com/blog/benchmarking
I appreciate the very even-handed way this was written, not fanning flames but bringing it back to a choice between trade-offs that all DB developers can/should make.
I don’t mean to be unkind. Let me say at the outset that I have zero dogs in this fight and am not qualified to respond to the substance of your rebuttal. However, I think the tone of your rebuttal completely misses the point made by the OP.
Nobody is asking for my advice here, but if I were asked I would tell them they have a blind spot wrt to outside perception. Perhaps they’re too much in their own bubble, or overly locked into an us-versus-them posture.
Yes, of course it did. This article makes factually wrong claims about the database I've spent 6+ years building.
Your comment was about whether SpacetimeDB was "just a hashmap behind a RwLock" and the blog post I linked addresses that question. Namely, it does have a RwLock, but that is by design and produces better results than the alternative.
Better results than the alternative, assuming your use case is to find two accounts by indexed ID, check a balance, and update two rows. And you have a small in-memory dataset, tiny rows, indexed point lookups, very little application computation, no external I/O, no joins, no analytical queries, no large scans, no disk-capacity pressure, thousands of independent requests available for pipelining, and deliberate hot-row contention. Or in other words, you have the perfect conditions for a...hashmap behind an RwLock!
Hm I wonder why people find this benchmark unfair...
One of the problems with running the application code inside the database server is that you need to make application developers use the programming language(s) you prepared for them. The other is that you need to trust them to not do crash out, or do infinite loops. Good luck moving application developers from their choice into the right choice.
This is easy to fix. The SpacetimeDB folks could just add a phase to analyze the application developer’s code before running it to prove that it will definitely halt.
This is why you need to compile your code for spacetimedb to WebAssembly and it runs inside a VM. Use the language of your choice, and assume the code is only semi-trusted with the ability to have a watchdog. That part makes sense.
I remember a friend showing me some stuff about this when they were still trying to pursue the MMORPG route and I am surprised this company is still alive given the amount of unnecessary overengineering that went into that effort.
The model of putting ECS like logic as code and putting all that code as stored procs solves a handful of db transaction issues that none of the major mmorpgs really had issues with 20 years ago when mmorpgs were all the rage and when computers were 100x-1000x slower than today. A lot of engineering is going to solving and cutting out these database round trips that were not even an issue 20 years ago and even less of an issue today.
On the other hand the actual hard parts about building a multiplayer game, such as roll back, physics, collisions, all of that sort of stuff, well this actually doesn't really help with any of that. If anything it makes all of those things even more difficult. I imagine that the developers of this game probably had to come up with some pretty interesting hacks that probably didn't benefit from their DB to get anything resembling physics to work.
Layered on top of that are the known anti-patterns around using stored procs within databases, which spacetimedb does't address at all. You can't really run your tests just on your client because the application logic is split between client and db-server leading to spaghetti code and poor iteration cycles for game design. The database itself also doesn't horizontally scale beyond a single node.
Just take a peek at the steam reviews for BitCraft. The recent ones are actually pretty scathing and it seems like, despite all this engineering, the developers haven't really listened to their playerbase. With all of this effort centered around building a custom database, users still can't, say, build homes for themselves in this game, something that you can certainly do in probably most all other MMORPGs.
I think this will go down as a cautionary example of not listening to your users and spending engineering effort on the wrong types of problems. I think one of the most important skills for an engineer is actually not just having good technical ideas but knowing the right types of problems to solve and, most importantly, listening to your audience, your users, and your stakeholders. I wish the developers the best of luck and hope they can pivot successfully.
I'm almost confident the architecture is the result from some kind of pivot from blockchain gaming.
Previously they talked about "testnet" and you use "energy credits" to pay for services. They also described aspects as being similar to smart contracts.
Naming the game "Bitcraft" circa 2021 is a big tell as well
This explains the grifting. Sorry Cloutier.
On the contrary, even the writer of this blog post told me that BitCraft is "a very enjoyable game"!
Oh I'm sure it very enjoyable. This is more on the question of "could it have been a better game with better reviews" if more time had been spent on gamedev versus spacetimedb?
I suspect the answer to that is probably nuanced. Spacetime probably gets more VC funding based on the DB rather than being a game. Trying to make a successful indie MMORPG without pre-existing IP is going to be an uphill battle in 2026 with or without fancy backend innovations.
The SpacetimeDB launch video came up on my YouTube feed - and I was surprised the video didn't go at all into how it was implemented. I assumed it was proprietary magic, but then I was surprised to find it was opensource. That confused me more - to get the kind of semantics they were talking about I had assumed that it was pretty novel and if it was open source they should be leading with that.
Kind of bummed to see its essentially 2015-era React Flux in Rust around a mutex.
Notably, single threaded execution is optimal for performance here. If you don't believe us, maybe you'd believe TigerBeetle which is also single threaded by design.
If you're interested more in our benchmarking methodology, you can read our technical blog post on the topic: https://spacetimedb.com/blog/benchmarking
"Because the system is, well, a hash table with a lock in front of it."
This actually surprises me? I was a very early employee/contractor working on this product but left after 3 months. But this wasn't the shape it had when I was there. It would have been better described as a CoW tree of various sorts, which lets reads and writes advance on separate transactions and reconciles at commit with what I recall was fairly minimal lock-holding time.
When I was there there was no global lock being held while a WASM "reducers" was executing. They operated on their own separate transaction in their own thread.
I haven't looked at their source since -- and I really don't want to because I work on similar things I don't want IP contamination as last I looked they had some sort of weird license -- but there's been .. 3 years? of development on it since and I know Tyler well enough and he hired smart-ish people.
I had a lot of criticisms of what he was making and the way it was being made... but ehh....I would want to confirm in source that this claim is accurate, it makes me a bit suspicious of the accuracy and fairness of the rest of TFA.
Ok, so I had a clanker go look. It actually sounds as bad as the article says. For some reason they apparently lock things while "reducer"s are running.
Robot brain summarized:
"Your historical description may be completely accurate. Your request that the author substantiate the claim was warranted. But the source substantiates it extremely clearly. The blog’s concurrency conclusion is right. Its “hash table,” fairness, “cannot sync WAL,” and “questionable to call it a database” language is deliberately contemptuous and sometimes technically sloppy."
touche
I think you mean it sounds as good as the article says it is. SpacetimeDB is single threaded by design, just like TigerBeetle by the way. The reason we changed from MVCC to single threaded design is that it's simply faster for almost all workloads. Measurably so! With MVCC we were doing more bookkeeping than actual work and perpetually causing cache coherency issues.
"Technically sloppy" is an understatement. The article just gets several things plan incorrect about the durability guarantees, etc.
Since we're asking clankers:
https://chatgpt.com/c/6a886e34-c784-83ea-8298-2d8215f5994a
https://claude.ai/share/658d00e4-550a-470e-b4a3-7a71a06222cb
> In particular, these statements should not be relied on:
> readers wait “up to 0.5 ms” because of parking_lot;
> all reducers/views are Wasmtime/WASM;
> reads normally happen through Views;
> external side effects are merely something reducer authors must avoid;
> durable/confirmed reads are an unusual opt-in intended only > for non-ephemeral data;
> 50 ms is the normal/current durability delay;
> SpacetimeDB has no meaningful replication;
> the benchmark numbers themselves are simply “not true.”
hey tyler, ltns
yeah my bot also flagged the parking_lot thing :-)
it was a hit piece with an unprofessional tone. but extraordinary claims get extraordinary responses
i do think dropping mvcc is an odd choice. do you at least let pure reads proceed while a single writer is active?
Extraordinary claims perhaps, but correct ones nevertheless: https://spacetimedb.com/blog/benchmarking.
The article says that we don't provide strong durability guarantees. Pure ipse dixit. And IIRC he's already cleaned it up a little.
The shamelessness with which people published bogus claims about SpacetimeDB after this was really really astonishing. And so many were quick to dismiss the overall results based on some handwaving arguments. I wasn't prepared for it.
We should have held off on publishing until we had a deep technical blog on the subject.
If you haven't read https://spacetimedb.com/blog/benchmarking you should give it a read.
It seems like an odd choice perhaps, but I had the numbers to prove that it was simply measurably worse overall performance for most OLTP workloads.
IIRC, we don't let pure reads read the committed state while a transaction is underway. We can certainly do that in the future, but we're so far out ahead of typical database performance for most OLTP workloads we haven't even bothered.
I watched a few of their talks, and while I'm somewhat impressed by the results, it's not exactly surprising to me that you can get those numbers when you make the trade-offs they're making. Most applications cannot make those trade-offs and, thus, cannot ever hope to see those numbers. The lack of rigor in database benchmarking in any of the videos I saw was an obvious indicator of something to be wary of.
I am a creator of SpacetimeDB. Several assertions in this article are simply wrong. You can read our response here: https://spacetimedb.com/blog/benchmarking
In particular, we are not making trade-offs. The assertions SpacetimeDB provides anything less than full durability guarantees is just wrong.
I appreciate the article from a technical perspective. Is there anyone here who has used it in production regardless of the criticism and has some perspective to share on where it actually falls flat or situations where performance degrades massively? Them having built an MMO around it makes it look like the technical limitations around this pattern might(!) only matter for very specific workloads or for poorly implemented reducers - and my gut feeling is that you can also reach for postgres or sqlite and write very inefficient queries that quickly bog your system down as well. Just curious how it stacked up in the real world.
I am the SpacetimeDB developer. Several assertions in this article are simply wrong. You can read our response here: https://spacetimedb.com/blog/benchmarking
I’ve been following for a bit, but have intentionally avoided using it. It’s prob fine for vibe coders (increasingly seems to be their target) and proof of concept work.
There seems to have been a fair bit feature churn across their whole stack. I’ve seen a fair few projects and tooling fizzle out cuz of the moving targets. It’s not really clear what is long term stable.
There is a lot of over promising and under delivering (features advertised in their 1.0 still not here). They own your whole stack, so deviating from what they provide is an unhappy path. If you need something beyond what is in their current feature set (not what is promised!) then you will probably have an easier time constructing such a system out of the hundreds of open-source components built for modular construction.
Their hosting has not been stable (no LTS either, so you are forced to live on the edge of their deploy schedule). Limited hosting options (only US iirc). Migrations and long term management don't seem to be in a great state either (external tooling needed). Trying to escape their stewardship and selfhost leaves you with a restrictive license…
It seems they are trying to follow in Michael Stonebrakers footsteps, first with copying VoltDB and now DBOS. It’s not clear what their priorities are, when they haven’t yet delivered a single solid product yet.
I do not really see how their business model is any different than VoltDB which was also open source with gated features. The VoltDB community died off for this reason, not sure why we would expect anything different to happen here. Unless they change their license, I would not expect a thriving community like Postgres or SQLite/LibSQL
Always a fun time to bring up my favorite writeups in database benchmarking: https://questdb.com/blog/lies-damn-lies-and-database-benchma...
There’s also an excellent paper called “Fair Benchmarking Considered Difficult: Common Pitfalls In Database Performance Testing”.
Benchmarks are genuinely hard. Modern systems and hardware are notoriously complex and have different behaviors across runs and with minor tweaks to performance settings.
Yep, absolutely... and in the end benchmarks aren't going to sell a database anyways. Reliability and provable correctness and ease of integration are probably going to win in the end. It's a dubious marketing edge to lead with.
PostgreSQL itself is remarkably slow in many configurations and leaves a lot of performance on the table due to its architecture and assumptions. But it works and people trust it. So they use it.
As a SpacetimeDB dev, I absolutely agree. Reliability, provable correctness, and ease of integration are higher priority than performance. That doesn't mean we need to accept garbage performance though.
You may be interested in our technical blog post on benchmarking methodology for this benchmark: https://spacetimedb.com/blog/benchmarking
Or if you're in enterprise, whichever company's sales rep some executive has locked you into while 10 drinks in at a fancy dinner.
I am a creator of SpacetimeDB. Several assertions in this article are simply wrong. You can read our response here: https://spacetimedb.com/blog/benchmarking
Broadly enjoyed my read, though I do have a nitpick here:
>The absence of side effects or stalls cannot be enforced by the type system ...
Side effects is probably correct, but stalls would imply wasm code that calls out to a long-time blocking function - that's generally quite easy to type-system-ify, and wasm stuff often does so with promise-like constructs. So there would be a need for spacetimedb-side markers for "this func might do HTTP", but that kind of marker for WASM-contact-able code is very much a normal expectation.
If they don't have that kind of marker, and do allow blocking calls in their beta API, then yeah - huge problem with that kind of internal structure (shared global lock), completely agreed.
I would encourage you to read our technical write up in reply to this article: https://spacetimedb.com/blog/benchmarking
Doesn't really cover the types used in the beta APIs. Nor would I expect it to though.
Is there a more technical explanation post somewhere? I'm definitely curious how it works, and I like the core idea quite a bit - I'm fairly convinced that WASM uses like this are going to grow immensely, and "it's just a global mutex/single thread" reduces complexity so much that it's always interesting to see where it's possible to use.
The latency+throughout brings many questions though, like "are you holding responding to writes and any reads that occur after until changes are written to disk" and "if so I kinda assume that change log is constantly streamed to disk with a moving high water mark for responses". I can generally see how that'd hit such benchmarks, especially with non-dirty reads being near instant, but details are always interesting.
I don't really have a deep technical explanation blog post out, but we should definitely publish one.
I can say that your last paragraph is essentially correct though. It works exactly that way.
Is there anything on how a multi-node cluster works (I'm kinda assuming there's something since it makes "single" mentions a few times)? Application-level sharding is always an option (and multiple things I've worked on have used it to great effect), but anything automatic seems likely gnarly and fun to learn about, if it recovers some of the naive perf loss of "just hold the lock while doing rpc to other nodes".
I'm a SpacetimeDB developer and this post has many inaccuracies. I have actually asked Vicent to fix them and he's agreed to address them.
Please read our reply to this and other criticism here: https://spacetimedb.com/blog/benchmarking
*Founder…
Has anyone benchmarked it against Volt Active Data yet? They seem comparable in premise and further along in development.
For as long as I’ve known about SpacetimeDB the premise seemed to have its uses, but I don't really trust how new it is nor all the weird marketing behind it
Very cool watching late stage software shops undiscover n tier architecture. Of course, breaking from hard learned wisdom for niche use cases is fine… until you bury the reality in a misleading and edge lord-ish PR sweep.
I would encourage you to read our technical blog post in reply to this article: https://spacetimedb.com/blog/benchmarking
Leading with unfair benchmarks is the fastest way to lose credibility in the database space. The companies that last are the ones doing honest technical work.
As a SpacetimeDB dev, I absolutely agree. However, these benchmarks are more than fair. Please read our full technical writeup on the benchmarks: https://spacetimedb.com/blog/benchmarking
> The companies that last are the ones doing honest technical work.
If only that were true...
I appreciate the very even-handed way this was written, not fanning flames but bringing it back to a choice between trade-offs that all DB developers can/should make.
I am a creator of SpacetimeDB. Several assertions in this article are simply wrong. You can read our response here: https://spacetimedb.com/blog/benchmarking
I don’t mean to be unkind. Let me say at the outset that I have zero dogs in this fight and am not qualified to respond to the substance of your rebuttal. However, I think the tone of your rebuttal completely misses the point made by the OP.
Nobody is asking for my advice here, but if I were asked I would tell them they have a blind spot wrt to outside perception. Perhaps they’re too much in their own bubble, or overly locked into an us-versus-them posture.
They're calling a hashmap behind a RwLock a "database"? Damnit I wish I had the capacity for grifting, I could be rich by now.
If you don't believe me, perhaps you'd believe the TigerBeetle team who also made their database single threaded by design.
Perhaps you'd be interested in reading our technical response: https://spacetimedb.com/blog/benchmarking
My comment was unrelated to benchmarking and I don’t see anything in that blogpost addressing my comment.
Also you’re spamming the same comment up and down this thread. Did this post upset you?
Yes, of course it did. This article makes factually wrong claims about the database I've spent 6+ years building.
Your comment was about whether SpacetimeDB was "just a hashmap behind a RwLock" and the blog post I linked addresses that question. Namely, it does have a RwLock, but that is by design and produces better results than the alternative.
Better results than the alternative, assuming your use case is to find two accounts by indexed ID, check a balance, and update two rows. And you have a small in-memory dataset, tiny rows, indexed point lookups, very little application computation, no external I/O, no joins, no analytical queries, no large scans, no disk-capacity pressure, thousands of independent requests available for pipelining, and deliberate hot-row contention. Or in other words, you have the perfect conditions for a...hashmap behind an RwLock!
Hm I wonder why people find this benchmark unfair...
One of the problems with running the application code inside the database server is that you need to make application developers use the programming language(s) you prepared for them. The other is that you need to trust them to not do crash out, or do infinite loops. Good luck moving application developers from their choice into the right choice.
This is easy to fix. The SpacetimeDB folks could just add a phase to analyze the application developer’s code before running it to prove that it will definitely halt.
the halting problem?
i think that's the joke, my friend
This is why you need to compile your code for spacetimedb to WebAssembly and it runs inside a VM. Use the language of your choice, and assume the code is only semi-trusted with the ability to have a watchdog. That part makes sense.
I'm a SpacetimeDB dev. We do not need to trust them, we employ a system like Ethereum's gas limits to prevent infinite loops.
Do SurrealDB next
I think surrealdb is actually nice, just a bit missmanaged
based design
[dead]