SpacetimeDB

Interesting, it seems that it's Source Available but converts to Open Source (AGPL) in 2031. First time I've seen licensing like that. https://github.com/clockworklabs/SpacetimeDB/blob/master/LIC...

I concede that we do have a big lock. But that is only because we did the alternative first and it performed worse, which is what OPs article is about. Reposting what I posted below regarding the strn.cat article: I'm a cofounder of SpacetimeDB (and the author of OPs article). The https://strn.cat/posts/spacetime/ article has several substantial errors. I've spoken with Vicent directly about them. Most notably, almost the entire commentary about durability is incorrect. SpacetimeDB does not acknowledge anything before data is fully persisted to disk, even though he claims it does. Clients CAN chose to listen before that, but you can do the same thing in Postgres if you want. There is no 50 ms delay to writing to disk. The article is mostly nonsense. Ask Claude yourself: https://github.com/clockworklabs/SpacetimeDB He spent 15 minutes look

I'm a cofounder of SpacetimeDB (and the author of OPs article). The https://strn.cat/posts/spacetime/ article has several substantial errors. I've spoken with Vicent directly about them. Most notably, almost the entire commentary about durability is incorrect. SpacetimeDB does not acknowledge anything before data is fully persisted to disk, even though he claims it does. Clients CAN chose to listen before that, but you can do the same thing in Postgres if you want. There is no 50 ms delay to writing to disk. The article is mostly nonsense. Ask Claude yourself: https://github.com/clockworklabs/SpacetimeDB He spent 15 minutes looking at our code (by his own admission), having never written a database storage engine before AFAIK, and made a pronouncement that SpacetimeDB wasn't a good database. Crazy stuff.

There is Spacetimedb https://github.com/clockworklabs/spacetimedb Specifically targeting your use case with high fps. Downside: db lives in memory and has to be stored separately for long term use (as of now, may change laterl

Have a look at something like spacetimeDB - caveat, I've only read about it and not directly used it: https://github.com/ClockworkLabs/SpacetimeDB

Feel like the logical extreme of this is a database built for multiplayer games, something like: https://github.com/clockworklabs/SpacetimeDB Though there, you are still writing the main game logic in Rust or C#

SpacetimeDB is open source[1], the open source version doesn't currently have all the features of maincloud, but most of those features are solely for scalability. I've done all of my work on my own local servers. I would even suggest paying for your own server up front until you're ready to scale out. I believe the 4 years is when the license changes to a more open license. And the scalability features on local are coming, they're just not here yet. [1] https://github.com/ClockworkLabs/SpacetimeDB

This is indeed interesting, but FYI this is a BSL-covered project with somewhat onerous times: only one instance per service (i.e. don't scale out, if I understand correctly) [0]. [0] https://github.com/ClockworkLabs/SpacetimeDB?tab=License-1-o...

Yes? I can't use the licensed model to train content? In the same way I can't use BSL to use the software in the cloud or Meta's model license when I can't be a big company. * BSL - https://github.com/clockworklabs/SpacetimeDB/blob/master/LIC... * Meta - https://github.com/meta-llama/llama-models/blob/main/models/...

We just released 1.0 of SpacetimeDB, a database designed for real-time games and applications built in Rust and using WebAssembly stored procedures for running server-side logic.