So can we assume that D2 will be postgres/mysql ?
It sounds like you're making a simile but I don't understand it. The article did literally state D1 is based on sqlite.
D1: Our SQL database
41–50 of 241 posts
Re: D1: Our SQL database
#42All this recent hype around sqlite... sqlite is a great embedded database and thanks to use by browsers and on mobile the most used database in the world by orders of magnitude. But it also comes with lots of limitations. * there is no type safety, unless you run with the new strict mode, which comes with some significant drawbacks (eg limited to the handful of primitive types) * very narrow set of column types and o…
D1 does not throw away consistency. It’s built on top of Durable Objects which is globally strongly consistent.
Re: D1: Our SQL database
#43Is this going to be open sourced? Seems to be building on the shoulder of a particular giant that could use a bit wider ecosystem.
Re: D1: Our SQL database
#44This looks awesome. I was thinking about creating a custom version of this to live behind a CF Worker. Much better to have an official version!
Re: D1: Our SQL database
#45This is so cool! From the blog post it says read-only replicas are created close to users and kept up to date with the latest data. - How should I think about this in terms of CAP? If there's a write and I query a replica what happens? - How are writes handled? Do they go to a single location or are they handled by various locations? I'm excited to try this. It's so cool to see databases being distributed "on CDNs" f…
I think they're replicated asynchronously, so reading directly from the replica may return old data. That's why they've added the ability to deploy special workers that "live" closer to the primary:
> Embedded compute
> But we're going further. With D1, it will be possible to define a chunk of your Worker code that runs directly next to the database, giving you total control and maximum performance — each request first hits your Worker near your users, but depending on the operation, can hand off to another Worker deployed alongside a replica or your primary D1 instance to complete its work.
Re: D1: Our SQL database
#46Have any of the problems that led people to use Postgres instead of SQLite actually been solved? Are we doomed to repeat the same mistakes? Also, any plans to support PATCH x-update-range so SQLite can be used entirely in the browser via SQLite.js? Can someone enlighten me with the types of use cases this would be better for vs say Postgres?
No and no. I think this is great for Edge computing, where there is currently no solution. So, it's better than nothing.
It all depends on the use-case, of course. A traditional hosted Postgres or MySQL database or cluster is certainly the go-to solution for all who need advanced features or full consistency, which only synchronous replication could provide.
Re: D1: Our SQL database
#47Have any of the problems that led people to use Postgres instead of SQLite actually been solved? Are we doomed to repeat the same mistakes? Also, any plans to support PATCH x-update-range so SQLite can be used entirely in the browser via SQLite.js? Can someone enlighten me with the types of use cases this would be better for vs say Postgres?
Which problems were you thinking of? Cloudflare and fly.io both promise hassle free read replicas and backup. They will both offer only a single node capable of writes, because that’s how SQLite rolls. This is a pretty good fit for a read heavy load that requires SQL and very low latency.
The important drawback is async replication and therefore the lack of full consistency. On the other hand, this is the big advantage of hosted Postgres and the like.
Those offerings are great for use-cases that don't need that kind of consistency, which are many.
Re: D1: Our SQL database
#48All this recent hype around sqlite... sqlite is a great embedded database and thanks to use by browsers and on mobile the most used database in the world by orders of magnitude. But it also comes with lots of limitations. * there is no type safety, unless you run with the new strict mode, which comes with some significant drawbacks (eg limited to the handful of primitive types) * very narrow set of column types and o…
Has anyone tried to write a new modern SQLite?
Re: D1: Our SQL database
#49All this recent hype around sqlite... sqlite is a great embedded database and thanks to use by browsers and on mobile the most used database in the world by orders of magnitude. But it also comes with lots of limitations. * there is no type safety, unless you run with the new strict mode, which comes with some significant drawbacks (eg limited to the handful of primitive types) * very narrow set of column types and o…
D1 does not throw away consistency. It’s built on top of Durable Objects which is globally strongly consistent.
Interesting that D1 is built on top of Durable Objects. Does this mean that it would be practical for a single worker to access multiple D1 databases, so it could use, for example, a separate database for each tenant in a B2B SaaS application? Edit: And could each database be in a different primary region?
Re: D1: Our SQL database
#50"With D1, it will be possible to define a chunk of your Worker code that runs directly next to the database...each request first hits your Worker near your users, but depending on the operation, can hand off to another Worker deployed alongside a replica or your primary D1 instance to complete its work."
That's interesting to me. It opens the door for Cloudflare to offer something more like a "normal" serverless offering. One that can run containers, or least natively run Python/Golang/Java/etc, like AWS Lambda does. And with this ecosystem described above that can conditionally route between the lighter edge Workers and the heavier central serverless functions. To me, that's the tipping point where they start to threaten larger portions of AWS.