Live data from Hacker News

D1: Our SQL database

blog.cloudflare.com

21–30 of 241 posts

Re: D1: Our SQL database

#21
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?

Re: D1: Our SQL database

#22
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.

Re: D1: Our SQL database

#23

wow SQLite getting a lot of love these days https://tailscale.com/blog/database-for-2022 https://fly.io/blog/all-in-on-sqlite-litestream https://blog.cloudflare.com/introducing-d1

I'm wondering if we'll see some similar energy around non-sql embedded databases like leveldb or rocksdb

Re: D1: Our SQL database

#24
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/…

The announcement - if you read it before posting - says it's sqlite, so that's something you can punch into google.

Long story short, don't expect anything fancy. Support for alter table is limited, and concurrency can be an issue.

Re: D1: Our SQL database

#25
This 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" for lack of a better term.

Re: D1: Our SQL database

#26
First, I'm very excited. Sure, SQLite has some limitations compared to Postgres, esp. regarding the type system and concurrency. But we get ACID compliance and SQL.

But it is really hard getting some useful information from this article. I can't even tell if it is not there or just buried in all this marketing hot air.

So, what is it really? Is there one Write-Master that is asynchronously replicated to all other locations? Will writes be forwarded to this master and then replicated back?

I'm very curious about how it performs in real life. Especially considering the locking behavior (SQLite has always the isolation level 'serializable' iirc). The more you put in a transaction or the longer you have to wait for another process to finish their writes, the more likely you have to deal with stale data.

But overall I'm very excited. Also by the fly.io announcement, of course. Lots of innovation and competition. Good times for customers.

Re: D1: Our SQL database

#27
post #19

wow SQLite getting a lot of love these days https://tailscale.com/blog/database-for-2022 https://fly.io/blog/all-in-on-sqlite-litestream https://blog.cloudflare.com/introducing-d1

I think it’s long overdue. While SQLite certainly has its limitations, it’s a winner in many categories. Even for sites with mild traffic using ordinary SQLite in PHP like a decade ago, it was always nice to use for its simplicity and the performance was totally acceptable. In comparison, the memory usage of typical relational database servers was high enough to make it hard to fit on a single lowend VPS with the sam…

The main thing for tuning SQLite will be how to open it, e.g. in write-ahead mode, to turn on foreign keys (this needs to be enabled manually), and whether it should wait to get a database lock on slower hardware before giving up. There's also some gotchas like if you mark an ID column as primary key, it'll use the rowid as key - which can be reused if a row is removed. So you need to explicitly set primary key AND autoincrement, else you're going to have a bad time. (https://www.sqlite.org/autoinc.html)

Re: D1: Our SQL database

#29
post #5

Not a expert on DOM or JavaScript so be kind ;) One thing I hope to see in the future is a better product filtering experience. When I worked on a jquery product filter I realized the DOM bloat was the main problem. I wonder if D1 can help devs build instant product filtering pages that don’t require the reload like microcenter or Newegg does. IE https://www.newegg.com/p/pl?d=hdmi+cable&N=-1&SortType=8

It's probably better - especially for more advanced search engines - to have an elasticsearch instance or whichever is the more recent example handle product search and filtering like that.
Post reply on HN