Show HN: SpacetimeDB – A database that replaces your server (github.com)

80 points by cloutiertyler ↗ HN
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

[ 2.7 ms ] story [ 54.6 ms ] thread
> 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.

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...

Isn't that just gpl2?
There is no lesser GPLv2.0, you need a custom linking exception there too.
I wouldn't ordinarily chirp about this because it seems to be such a common typo/mistake but the fact you have a badge for it <https://github.com/clockworklabs/SpacetimeDB/blob/0f1fdf62d0...> as well as typoing it down in the license section <https://github.com/clockworklabs/SpacetimeDB/blob/0f1fdf62d0...> makes it worth pointing out in hopes of correction

The SPDX for BUsiness Source License is BUSL https://spdx.org/licenses/BUSL-1.1.html but the SPDX for Boost Source License is BSL https://spdx.org/licenses/BSL-1.0.html

Based on a search <https://shields.io/search?q=license> it seems you're using the custom badge syntax <https://shields.io/badges/static-badge> so you have influence over the correction

Whoops! We'll fix this right away. Good catch, thanks for the heads up!
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.

Thank you! Join our Discord if you like. We'll be there to answer questions almost all the time.
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.
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.
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?
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.

> no more ops, no more servers

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

This is true, but the option is there if you want to offload the ops and servers to a cloud provider.
How does this compare to embedded databases like sqlite?
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.
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?