Live data from Hacker News

D1: Our SQL database

blog.cloudflare.com

31–40 of 241 posts

Re: D1: Our SQL database

#31

Have 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?

What problems? Both are for different use cases albeit overlapping.

Re: D1: Our SQL database

#32

Any current or planned support for existing ORMs, such as Prisma or TypeOrm? Also, I wonder how hard it will be to migrate existing PostgreSQL databases and SQL statements. Of course, I understand if Cloudflare is focused on greenfield applications.

Before you consider using an ORM, try using regular SQL and some tooling first; your future self will thank you. Just write the code, it's only volume and it's not so bad.

Re: D1: Our SQL database

#33

Any current or planned support for existing ORMs, such as Prisma or TypeOrm? Also, I wonder how hard it will be to migrate existing PostgreSQL databases and SQL statements. Of course, I understand if Cloudflare is focused on greenfield applications.

Before you consider using an ORM, try using regular SQL and some tooling first; your future self will thank you. Just write the code, it's only volume and it's not so bad. What is bad is learning a 3rd language on top of SQL and JS/TS that you somehow have to manually map to SQL.

Re: D1: Our SQL database

#34
post #31

Have 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?

What problems? Both are for different use cases albeit overlapping.

Concurrent writes, for one.

Re: D1: Our SQL database

#35
All 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 overall functionality in general

* the big one for me: limited migration support, requiring quite a lot of ceremony for common tasks (eg rewriting a whole table and swapping it out)

These approaches (like fly.io s) with read replication also (apparently?) seem to throw away read after write consistency. Which might be fine for certain use cases and even desirable for resilience, but can impact application design quite a lot.

With sqlite you have do to a lot more in your own code because the database gives you fewer tools. Which is usually fine because most usage is "single writer, single or a few local readers". Moving that to a distributed setting with multiple deployed versions of code is not without difficulty.

This seems to be mitigated/solved here though by the ability to run worker code "next to the database".

I'm somewhat surprised they went this route. It probably makes sense given the constraints of Cloudflares architecture and the complexity of running a more advanced globally distributed database.

On the upside: hopefully this usage in domains that are somewhat unusual can lead to funding for more upstream sqlite features.

Re: D1: Our SQL database

#36

Have 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.

Re: D1: Our SQL database

#37
I'm buying Cloudflare stocks right now.

In 2-3 years from now, these services will be so mature and strong they will be crushing the cloud market.

They're turning dreams into reality, one after another.

Re: D1: Our SQL database

#38
Wow, this looks potentially very interesting. Since this is sort of fresh in my mind from the recent Fly post about it:

* How exactly is the read replication implemented? Is it using litestream behind the scenes to stream the WAL somewhere? How do the readers keep up? Last I saw you just had to poll it, but that could be computationally expensive depending on the size of the data (since I thought you had to download the whole DB), and could potentially introduce a bit of latency in propagation. Any idea what the metrics are for latency in propagation?

* How are writes handled? Does it do the Fly thing about sending all requests to one worker?

I don't quite know what a "worker" is but I'm assuming it's kind of like a Lambda? If you have it replicated around the world, is that one worker all running the same code, and Cloudflare somehow manages the SQL replicating and write forwarding? Or would those all be separate workers?

Re: D1: Our SQL database

#39
post #17

This looks amazing! I see cloudflare people are on this post, any chance to compar D1 vs postgres in terms of DB features? Insert ... Returning Stored procedures and triggers Etc etc Would be really helpful to get a comparison like cockroachDB did here https://www.cockroachlabs.com/docs/stable/postgresql-compati... Or even better, a general sql compatibility matrix like this https://www.cockroachlabs.com/docs/stable/…

Well, it's sqlite... so presumably you will get most of the capabilities sqlite has. RETURNING is covered. Stored procedures are indirectly there by running your own code "next to the database", as mentioned in the post. Which is arguably much nicer than having to use some database specific language, given that you can run WASM on workers.

There is a layer on top of Sqlite here, so I imagine it's something less than all the capabilities sqlite has, at least initially. Plus the upsides and downsides from their approach to have a master and read replicas.

Re: D1: Our SQL database

#40
post #36

Have 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.

I guess I’m not understanding what the benefit is vs hosted Postgres. Also low latency and setup can be equally trivial - see supabase for example.
Post reply on HN