The project is open source (https://github.com/Brayden/starbasedb/blob/main/src/index.ts). Yes to it provides a way to update Cloudflare's SQLite with HTTP.

Some day I really need to learn when to use sqlite in a durable object vs the eventually consistent one (r2).

Still think there is a lot we can add to StarbaseDB to make the developer experience on SQLite databases better, and personally I think it starts with a better external interface. Provide a frictionless way to get started. Then figuring out how to improve developer experiences on how they interface with databases.

Is it auto-accessible REST endpoints? Easy to implement websocket support for the database? Data replication for scaling reads? Offline data syncing? A lot of potential wins for a layer like this to build on.

It appears to be a product that requires the Cloudflare edge computing service.

So it actually sits on top of it, providing an HTTP interface to interact with them.

We don't cache query responses in the Starbase application layer. When we originally set out to build this, we were under the assumption we had to handle the ACID transactional support ourselves. Thankfully someone from Cloudflare shed some light for us as you can see in our Github issues and open PR's :)

Learn more about that here: https://github.com/Brayden/starbasedb/issues/12

+1. Love the cassette falling in place with the sound effect. Still don't know what it actually does though, but that is very satisfying.

Had no idea this was put on HN today. Author of StarbaseDB here, will get a bug fix for the blog redirection pushed out soon! Thanks for bringing this up.

DO = Cloudflare Durable Objects, https://developers.cloudflare.com/durable-objects/

D1 = Cloudflare D1, https://developers.cloudflare.com/d1/

Just incase someone else was as lost as me.

It's actually sitting on top of Cloudflare's new SQLite storage in Durable Objects. You can learn more here:

https://blog.cloudflare.com/sqlite-in-durable-objects/

There's actually a section called: What about D1?

He was mentioned, but did he comment here?

Multiple workers would connect to the same durable object and write to it, basically, the Durable Object takes care of all the writes in a single thread, so there's no issues with concurrent modifications.

We probably need to build out some sort of data replication to scale reads though Durable Objects are limited to 1000 RPS.

Same here. I wonder if it’s only broken for us or if it’s broken for everybody else as well.

I found it to be hilariously uninformative.

I have this old school expectation that I should be able to understand what your website/product/project is about but reading the first few sentences in the "above the fold" section of your homepage. I don't want to play a game or click below the fold "read more" links to try and find out what this web content has to do with the domain name "starbasedb".

Perhaps they actually know their intended (seemingly game developer?) audience that I give them credit for? But I do have plans (admittedly only very vague plans right now) to use one of the available "SQLite from javascript in a webpage querying the SQLite file in an object store like S3 without a web backend" techniques or projects. Maybe they'd work for me with my non game oriented use case? I don't know, it seems like they don't want me to find out...

So right now you will have to pay and use Cloudflare for this, there's no other way around it today.

No, there's no traditional database-level locking here. The Durable Object itself is single-threaded, so you don't have to worry about multiple things trying to change the same data at the same time.

As far as scaling yeah there are still some challenges there. I mentioned in another response there's a limit of 1K RPS, and the single-threadedness could become a bottle-neck. I think there are probably clever workarounds here that we still want to explore, for instance each Durable Object could handle a seperate piece of state and you would effectively have a level of state-based sharding.