31–40 of 76 posts
> You get to deploy your server logic directly into the database > You may make use of the Licensed Work provided your application or service uses the Licensed Work with no more than one SpacetimeDB instance in production and provided that you do not use the Licensed Work for a Database Service. Therefore, as an OSS product, SpacetimeDB does not scale.
I’d like to recommend If you are really need to scale out soon, your domain is difficult to separated, only use distributed DB.
It is true, distributed databases superior to many people technically, But that’s not mean they are better in your service situation
I think it is better spend your time, separate domain architecture. Simply use DB. Do not put unpredictable future off DB as past Oracle DB handle all.
I had a coworker that would always ask this, like a javelin thrown in the bicycle spokes of every demo. We hoped for tens of users.
I was waiting for a comment like this. It's not like there aren't any projects that should be thinking about "scale", but it's almost a meme at this point. There is even the section there near the beginning about how small web apps without many users 'may have to think about horizontal scaling as well' - no, no they don't. To take part in the meme as well, a single server with Postgres will suffice for what? 99% of c…
> You get to deploy your server logic directly into the database > You may make use of the Licensed Work provided your application or service uses the Licensed Work with no more than one SpacetimeDB instance in production and provided that you do not use the Licensed Work for a Database Service. Therefore, as an OSS product, SpacetimeDB does not scale.
I think there's alot of interesting things happening in the database space. Vitess/Neki, vector stores, spacetime are all really good things to be happening. I think it's a shame that database developers seem to have a drama filled timeline out there. It's... all very exciting, together.
Anyway, Some things that need improvement (some of which are addressed by this blog post):
1. Backups (fast recovery) and Disaster Recovery (slow, durable recovery)
This is a big one, but sometimes speed is not the only objective you have to meet. You need to have certainty that, if everything goes down that you (eventually) can bring things back online. I don't really have a way of doing that today.
2. Read replicas sure would be nice for analytic workloads
3. Durable writes to s3 would be nice for intermittent bursting workloads (like ci systems)
I think the Spacetime folks have their work cut out for them, not necessarily because of the technology (that's hard too) but because the AI models have seemingly decided that Neon and Postgres are all that exists.
I think spacetime has a bright future ahead of it, and I am wishing the team all the best as they work hard to imprint something new on the universe.
Earlier quoted context omitted.
I'll admit to not reading your code. It's hard to keep up with all the different databases launched in the last decade. I have doubts that a global readwrite lock around a hashtable makes for a good general purpose storage system.
We originally did MVCC and it was actually worse performance (in our implementation, I grant), but that's what OPs article is about. We spent a lot of money finding out that a lock is more performant. Calling it a "hashtable" is something that only someone who hasn't built a DB engine would do. It's incredibly naive. It discounts the complexity of execution, atomicity, durability, constraint validation, migrations, q…
> We spent a lot of money finding out that a lock is more performant.
I want to hear about that journey.
> Besides, it's a btree.
I guess it's not a hash table, but I think the point of Vincent's post is still worth exploring. You and he both say that essentially a key/value store is mutexed, and the user's code runs inside that mutex. That is fascinating. Why would that be better? Clearly it is, or you wouldn't have spent the money. What controls did you put in place to ensure user code didn't blow up the performance, or did you even feel the need for such controls? Is WASM VM execution fast enough for this? Is there even a market for that? Who pays to put their code inside that mutex and why? I want to know more.
While I think the tech is cool, and I'm sure it is fast, the fact that the benchmarks make assumptions about your stack doesn't sit right with me. They even admit that it is the main contributor to its speed: > The most significant (but not sole) reason SpacetimeDB is faster than other backends is that we have decreased the round trip time between your server and your database by at least 99.95%. In SpacetimeDB your…
I am the author of OPs article (SpacetimeDB cofounder). These are all fair caveats/criticisms. > The benchmarks are completely meaningless for that use case. I wouldn't say completely meaningless, but it isn't a game benchmark that's true. We feel very comfortable that it's the most performant backend for persistent games though. We were trying to show it's also more performant for web use cases. > 90% (or more) just…
Depends how persistent you really need it to be. If rolling back a few minutes is tolerable in exceptional scenarios then I disagree. It will be more performant to keep state in engine and snapshot whatever you need to save every few minutes. That's pretty much what most games do now.
> This is not correct. It's mostly processing player movement transactions. We do about 50 million an hour.
I said gameplay, not processing time.
While I think the tech is cool, and I'm sure it is fast, the fact that the benchmarks make assumptions about your stack doesn't sit right with me. They even admit that it is the main contributor to its speed: > The most significant (but not sole) reason SpacetimeDB is faster than other backends is that we have decreased the round trip time between your server and your database by at least 99.95%. In SpacetimeDB your…
But also vertical scaling seems to be able to handle so much these days that more people probably aught to ask themselves if their application is ever likely to truly need horizontal scaling - Maybe my work is just a small pond, but I suspect we will eventually end up in a place where the vast majority of applications are happy on a single box, and only twitter scale things need to care about this stuff.
.. or maybe I lack imagination of what possible future applications might make use of such massive horizontal scaling on such capable individual boxes (seriously).
Earlier quoted context omitted.
I've pushed teams to choose Spanner over using Postgres (when already in the GCP ecosystem). It's not really more expensive when you sit down and do the math, you save untold hours of maintenance over the lifespan of the app, and it actually scales without fuss.
what kind of maintenance? I think one of the maybe less talked about benefits of distributed SQL is support for nearly transparent rolling upgrades of the database with very little impact to a running workload. Spanner is best in class at this.