Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zero-latency SQLite storage in every Durable Object

simonwillison.net

Post reply on HN
Print view View original

21–30 of 108 posts

Re: Zero-latency SQLite storage in every Durable Object

#21

Post by emadda »

Some other interesting points:

- The write api is sync, but it has a hidden async await: when you do your next output with a response, if the write fails the runtime will replace the response with a http failure. This allows the runtime to auto-batch writes and optimistically assume they will succeed, without the user explicitly handling the errors or awaits.

- There are no read transactions, which would be useful to get a pointer to a snapshot at a point in time.

- Each runtime instance is limited to 128mb RAM.

- Websockets can hibernate and you do not have to pay for the time they are sleeping. This allows your clients to remain connected even when the DO is sleeping.

- They have a kind of auto RPC ability where you can talk to other DOs or workers as if they are normal JS calls, but they can actually be calling another data center. The runtime handles the serialisation and parsing.

Re: Zero-latency SQLite storage in every Durable Object

#22

Post by danpalmer »

stavros wrote: post #3

This is a really interesting design, but these kinds of smart systems always inhabit an uncanny valley for me. You need them in exactly two cases: 1. You have a really high-load system that you need to figure out some clever ways to scale. 2. You're working on a toy project for fun. If #2, fine, use whatever you want, it's great. If this is production, or for Work(TM), you need something proven. If you don't know you…

I'd view the split here along the axes of debuggability/introspection.

There are many services that just don't require performance tuning or deep introspection, things like internal tools. This is where I think serverless frameworks do well, because they avoid a lot of time spent on deployment. It's nice if these are fast, but that's rarely a key requirement. Usually the key requirement is that they are fast to build and low maintenance. It's possible that Cloudflare have got a good story for developer experience here that gets things working quickly, but that's not their pitch, and there are a lot of services competing to make this sort of development fast.

However where I don't think these services work well is when you have high debuggability and introspection requirements. What metrics do I get out of this? What happens if some Durable Objects are just slow, do we have the information to understand why? Can we rectify it if they are? What's the logging story, and how much does it cost?

I think these sorts of services may be a good idea for a startup on day 1 to build some clever distributed system in order to put off thinking about scaling, but I can't help but think that scale-up sized companies would be wanting to move off this onto something they can get into the details more with, and that transition would be a hard one.

Re: Zero-latency SQLite storage in every Durable Object

#23

Post by simonw »

yen223 wrote: post #20
stavros wrote: post #3

This is a really interesting design, but these kinds of smart systems always inhabit an uncanny valley for me. You need them in exactly two cases: 1. You have a really high-load system that you need to figure out some clever ways to scale. 2. You're working on a toy project for fun. If #2, fine, use whatever you want, it's great. If this is production, or for Work(TM), you need something proven. If you don't know you…

I almost have the opposite view: When starting out you can get away with using a simple Postgres database. Postgres is fine for low-traffic projects with minimal latency constraints, and you probably want to spend your innovation tokens elsewhere. But in very high-traffic Production cases with tight latency requirements, you will start to see all kinds of weird and wacky traffic patterns, that barebones Postgres won'…

Have you worked on any examples of projects that started on PostgreSQL and ended up needing to migrate to something specialized?

Re: Zero-latency SQLite storage in every Durable Object

#24

Post by dantiberian »

simonw wrote: post #6

One thing I don't understand about Durable Objects yet is where they are physically located. Are they located in the region that hosted the API call that caused them to be created in the first place? If so, is there a mechanism by which a DO can be automatically migrated to another location if it turns out that e.g. they were created in North America but actually all of the subsequent read/write traffic to them comes…

https://where.durableobjects.live is a good website that shows you where they live. Only about 10-11% of Cloudflare PoPs host durable objects. Requests to another PoP to create a DO will get forward to one of the nearby PoPs which do host them.

Re: Zero-latency SQLite storage in every Durable Object

#25

Post by klabb3 »

stavros wrote: post #3

This is a really interesting design, but these kinds of smart systems always inhabit an uncanny valley for me. You need them in exactly two cases: 1. You have a really high-load system that you need to figure out some clever ways to scale. 2. You're working on a toy project for fun. If #2, fine, use whatever you want, it's great. If this is production, or for Work(TM), you need something proven. If you don't know you…

Databases is an extremely slow-maturing area, similar to programming languages, but are all deviations from Postgres shiny and hipster?

The idea of colocating data and behavior is really a quantifiable reduction in complexity. It removes latency and bandwidth concerns, which means both operational concerns and development concerns (famously the impact of the N+1 problem is greatly reduced). You can absolutely argue that networked Postgres is better for other reasons (and you may be right) but SQLite is about as boring and predictable as you can get, with known strong advantages. This is the reason it’s getting popular on the server.

That said, I don’t like the idea of creating many small databases very much - as they suggest with Durable Objects. That gives noSQL nightmares - breaking all kinds of important invariants of relational dbs. I think it’s much preferable to use SQLite as a monolithic database like it’s done in their D1 product.

Re: Zero-latency SQLite storage in every Durable Object

#26

Post by dumbo-octopus »

stavros wrote: post #18
crabmusket wrote: post #15

Earlier quoted context omitted.

As far as I can tell, multiplayer is the killer app for Durable Objects. If you want to build another Figma, Google Docs, etc, the programming model of Durable Objects is super handy. This article goes into it more: https://digest.browsertech.com/archive/browsertech-digest-cl... I think this old article is quite relevant too: http://ithare.com/scaling-stateful-objects/ Anyone who read the Figma multiplayer article an…

That's a very interesting use case. Given that your "players" aren't guaranteed to be local to the DO, doesn't using DOs only make sense in high-traffic situations again? Otherwise you might as well just serve the players from a conventional server, no? CRDTs really do sound amazing, though.

In practice you’re most likely to be collaborating with other folks on your school project group, work team, close family, etc. Sure there are exceptions, but generally speaking picking a service location near your first group member ensures low latency for them (and they’re probably most engaged), and is likely to have lowish latency for everyone else.

On the flip side, picking US-East-1 gives okayish latency to folks near that, and nobody else.

Re: Zero-latency SQLite storage in every Durable Object

#27

Post by crabmusket »

stavros wrote: post #18
crabmusket wrote: post #15

Earlier quoted context omitted.

As far as I can tell, multiplayer is the killer app for Durable Objects. If you want to build another Figma, Google Docs, etc, the programming model of Durable Objects is super handy. This article goes into it more: https://digest.browsertech.com/archive/browsertech-digest-cl... I think this old article is quite relevant too: http://ithare.com/scaling-stateful-objects/ Anyone who read the Figma multiplayer article an…

That's a very interesting use case. Given that your "players" aren't guaranteed to be local to the DO, doesn't using DOs only make sense in high-traffic situations again? Otherwise you might as well just serve the players from a conventional server, no? CRDTs really do sound amazing, though.

Best case, the players are co-located in a city or country, and they'll benefit from data center locality.

Worst case, they're not co-located, and one participant has good latency, and the other doesn't. This is equivalent to the "deploy the backend in a single server/datacenter" approach.

Aside from the data locality, I still find the programming model (a globally-unique and addressable single-threaded class instance) to be quite nice, and would want to emulate it even without the Cloudflare edge magic.

Re: Zero-latency SQLite storage in every Durable Object

#28

Post by crabmusket »

klabb3 wrote: post #25
stavros wrote: post #3

This is a really interesting design, but these kinds of smart systems always inhabit an uncanny valley for me. You need them in exactly two cases: 1. You have a really high-load system that you need to figure out some clever ways to scale. 2. You're working on a toy project for fun. If #2, fine, use whatever you want, it's great. If this is production, or for Work(TM), you need something proven. If you don't know you…

Databases is an extremely slow-maturing area, similar to programming languages, but are all deviations from Postgres shiny and hipster? The idea of colocating data and behavior is really a quantifiable reduction in complexity. It removes latency and bandwidth concerns, which means both operational concerns and development concerns (famously the impact of the N+1 problem is greatly reduced). You can absolutely argue t…

> That gives noSQL nightmares - breaking all kinds of important invariants of relational dbs

IMO Durable Objects map well to use cases where there actually are documents. Think of Figma. There is a ton of data that lives inside the literal Figma document. It would be awful to have a relational table for like "shapes" with one row per rectangle across Figma's entire customer base. That's just not an appropriate use of a relational database.

So let's say I built Figma on MongoDB, where each Figma document is a Mongo document. That corresponds fairly straightforwardly to each Figma document being a Durable Object instance, using either the built-in noSQL storage that Durable Objects already have, or a small Sqlite relational database which does have a "shapes" table, but only containing the shapes in this one document.

Re: Zero-latency SQLite storage in every Durable Object

#29

Post by crabmusket »

dumbo-octopus wrote: post #26
stavros wrote: post #18

Earlier quoted context omitted.

That's a very interesting use case. Given that your "players" aren't guaranteed to be local to the DO, doesn't using DOs only make sense in high-traffic situations again? Otherwise you might as well just serve the players from a conventional server, no? CRDTs really do sound amazing, though.

In practice you’re most likely to be collaborating with other folks on your school project group, work team, close family, etc. Sure there are exceptions, but generally speaking picking a service location near your first group member ensures low latency for them (and they’re probably most engaged), and is likely to have lowish latency for everyone else. On the flip side, picking US-East-1 gives okayish latency to fol…

And the corollary to that is that often your collaborations have a naturally low scale. While your entire app/customerbase as a whole needs to handle thousands of requests per second or more, one document/shard may only need to handle a handful of people.

Re: Zero-latency SQLite storage in every Durable Object

#30

Post by [deleted] »

klabb3 wrote: post #25
stavros wrote: post #3

This is a really interesting design, but these kinds of smart systems always inhabit an uncanny valley for me. You need them in exactly two cases: 1. You have a really high-load system that you need to figure out some clever ways to scale. 2. You're working on a toy project for fun. If #2, fine, use whatever you want, it's great. If this is production, or for Work(TM), you need something proven. If you don't know you…

Databases is an extremely slow-maturing area, similar to programming languages, but are all deviations from Postgres shiny and hipster? The idea of colocating data and behavior is really a quantifiable reduction in complexity. It removes latency and bandwidth concerns, which means both operational concerns and development concerns (famously the impact of the N+1 problem is greatly reduced). You can absolutely argue t…

[deleted]
Post reply on HN