top | item 37146952

Show HN: SpacetimeDB – A database that replaces your server

80 points| cloutiertyler | 2 years ago |github.com | reply

We just released our database, SpacetimeDB, on GitHub under the BSL 1.1 license. It converts to a free software license after a few years.

The point of the database is that you upload application logic into the database as a WebAssembly stored procedure, so instead of clients connecting to a webserver they connect directly to the database. The database itself does authentication and you write your own authorization logic just like you would inside a webserver.

We’ve developed our game, BitCraft (https://bitcraftonline.com) entirely in this way. All of the game state is stored and synchronized with clients via SpacetimeDB, including player positions and movement.

We also plan to allow you to horizontally scale your applications in two ways:

1. By having multiple databases that can send messages to each other (i.e. the actor model) 2. By having distributed databases which partition data over multiple machines, similarly to CockroachDB, although this approach would cause a commensurate increase in latency in accessing data

Curious to hear your thoughts!

https://spacetimedb.com

19 comments

order
[+] bob1029|2 years ago|reply
Very cool concept!

I really like the idea of mainframe-style deployment models these days. My patience for 'devops' has zeroed out as of a few years ago. I've been pushing us on a cloud native function war path for the last ~period of time.

Overall, I would say your presentation is fantastic. I was able to try it out in a few minutes and see the actual product for myself. I also really like the fact that you went for C# support. I was going to suggest synergies with the Unity crowd but I see you've already included a guide in your docs about this.

Seems like you might be on to something. I will be keeping an eye on this project for sure.

[+] cloutiertyler|2 years ago|reply
Thank you! Join our Discord if you like. We'll be there to answer questions almost all the time.
[+] rapnie|2 years ago|reply
> BSL 1.1 license. It converts to a free software license after a few years.

Oof. That's a pity. Otherwise interesting innovative concept.

Btw, in the README:

> This is not an open source or free software license, however, it converts to the AGPL v3.0 license with a linking exception after a few years. Note that the AGPL v3.0 does not typically include a linking exception. We have added a custom linking exception to the AGPL license for SpacetimeDB. Our motivation for choosing a free software license is to ensure that contributions made to SpacetimeDB are propogated back to the community. We are expressly not interested in forcing users of SpacetimeDB to open source their own code if they link with SpacetimeDB, so we needed to include a linking exception.

Is that open source then? I never heard of a linking exception before.

[+] cloutiertyler|2 years ago|reply
It is, yes. It's more permissive than the AGPL because it allows you to use SpacetimeDB as a library without licensing your own code under the AGPL. We were trying to solve the problem that there is no Lesser AGPL, and linking is the reason by Google doesn't allow AGPL in their codebase at all:

https://opensource.google/documentation/reference/using/agpl...

[+] ithkuil|2 years ago|reply
> no more ops, no more servers

Eventually somebody will need to run this on prem and then there will be ops and servers.

[+] cloutiertyler|2 years ago|reply
This is true, but the option is there if you want to offload the ops and servers to a cloud provider.
[+] lord-squirrel|2 years ago|reply
Really cool project, thanks for making it available for others to look at. It really reminds me of https://pocketbase.io/ which has sorta the same idea and can be extended with go/js. How does the database work under the hood? Is it also based on sqlite? Are rust modules built with a special runtime in mind like tokio or?
[+] cloutiertyler|2 years ago|reply
It's not based on sqlite. We have a custom database engine which we needed for performance reasons for BitCraft. We need to be able to control very carefully what is done in memory vs on disk so that we can manage latency for games and other real-time/soft real-time applications.

Rust modules are agnostic to all of that. Right now they're not async at all since they take place in a transactional context and you don't want to await while a transaction is held open.

[+] jasfi|2 years ago|reply
The advantage I see is that there's no more context switching between the app and DB, which is the IO between the two. Especially if the two are on different servers, as is often the case. So that should boost performance quite a bit.
[+] cloutiertyler|2 years ago|reply
Absolutely. This was the original reason that we built this system. We found that we could get much much better performance when dealing with persistent data by putting the logic in the same process as the system which persists the data.
[+] rco8786|2 years ago|reply
As a general thought - I've never understood why this pattern isn't used more commonly with existing software.

Like, why is it so important that your database run on a separate server from your api code?

[+] potamic|2 years ago|reply
How does this compare to embedded databases like sqlite?
[+] cloutiertyler|2 years ago|reply
You can use SpacetimeDB as an embedded library as well. It depends on how you want to use it. sqlite doesn't really provide you a way to have replicas of your data or manage the data across multiple machines. It's complicated, but the idea is similar in a sense.