Live data from Hacker News

Starbase: SQLite on the Edge

starbasedb.com

41–49 of 49 posts

Re: Starbase: SQLite on the Edge

#41
post #15

I don't really understand what this is offering beyond Cloudflare's recent release of running SQLite in durable objects: https://blog.cloudflare.com/sqlite-in-durable-objects/ . Is it about providing an external interface to Cloudflare's SQLite databases?

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.

If that's the case there's libsql (https://github.com/tursodatabase/libsql) which already provides HTTP clients, embedded replicas (essentially good old SQLite but with replication support), self-hosted SQLite server and is maintained by a company using it for their own product.

Re: Starbase: SQLite on the Edge

#42
post #24
post #7

How does this compare with Cloudflare’s new offering SQLite it durable objects: https://blog.cloudflare.com/sqlite-in-durable-objects

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

Not a bad idea. There'll always be someone who says "but I can already do that with X" and then someone who replies to that with "but I can already do that with Y" and in the end when you're done trying to stick to the purist laws you've ran out of time and motivation and your project goes into the Pile of Dead Projects.

Or, we have easy to use, enjoyable interfaces and let ourselves use them, and actually finish things.

Re: Starbase: SQLite on the Edge

#43

Earlier quoted context omitted.

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

Just fyi, the person that replied wasn't just "someone" at Cloudflare. It was Kenton Varda (kentonv here). He's the creator of Cloudflare workers, he's an incredible engineer.

On the other hand, everyone is just someone, somewhere. Let's not criticise people for not giving enough of an intro to people.

Re: Starbase: SQLite on the Edge

#47

Really glad Kenton chimed in there, as it wasn't clear in the docs and I was about to implement a similar pseudo transaction pattern as this. Pretty excited about this tech, it really flips the script on the concept of a DB per user / sharding approach which used to be costly at the schema/physical db level.

He was mentioned, but did he comment here?

Re: Starbase: SQLite on the Edge

#48
post #47

Really glad Kenton chimed in there, as it wasn't clear in the docs and I was about to implement a similar pseudo transaction pattern as this. Pretty excited about this tech, it really flips the script on the concept of a DB per user / sharding approach which used to be costly at the schema/physical db level.

He was mentioned, but did he comment here?

He commented here: https://github.com/Brayden/starbasedb/issues/12

Re: Starbase: SQLite on the Edge

#49
post #18

Earlier quoted context omitted.

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

iirc they are both powered by the same engine to stream and replicate the WAL. I believe R2 is now implemented as a Durable Object backed by SQLite now.

Does this mean that R2 is not "eventually consistent" anymore?

I wonder what are the use cases (and when it's safe) to use "eventually consistent".

I'm guessing that maybe things like social media posts could be fine with "eventually consistent". It's not really critical to have the latest data.

I'm guessing that things like a shopping cart, a user account, a session shouldn't use a "eventually consistent" database.

Post reply on HN