Too bad you probably can't use this to store data about EU citizens. Phone numbers like they show in the demo are considered PII, right?
why?
D1: Our SQL database
131–140 of 241 posts
Re: D1: Our SQL database
#132For a Cloudflare article, this one is surprisingly light on technical details. And for the product where it most matters. I'm guessing this is a single master database with multiple read replicas. That means it's not consistent anymore (the C in ACID). Obviously reads after a write will see stale data until the write propogates. I'm a bit curious how that replication works. Ship the whole db? Binary diffs of the mast…
Small nitpick, but that's still consistent as in ACID. I think what you mean is it wouldn't be consistent in the CAP sense (it wouldn't be linearizable).
TFA does say that read-replicas will be present at every edge location, which makes sense for a product like Workers. But it doesn't mention writes at all.
Re: D1: Our SQL database
#133So I assume we'll see a nice big donation to the sqlite coffers, then?
Re: D1: Our SQL database
#134Any 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.
We are definitely interested in ORMs. Want to make it easy to use. I hope someone creates the next Rails using Workers. And having other models on top of our SQL offerings will be important. Get in contact and let us know what you'd like.
I'm building an open source firebase alternative using sqlite. I'll be reaching out, I was thinking to build the distribution & durability part myself, but I would rather use D1!
I guess it would count as a client focused ORM :)
I'll be reaching out from jp@javascriptdb.com
Great addition, congrats!
Re: D1: Our SQL database
#135Earlier quoted context omitted.
We are definitely interested in ORMs. Want to make it easy to use. I hope someone creates the next Rails using Workers. And having other models on top of our SQL offerings will be important. Get in contact and let us know what you'd like.
> I hope someone creates the next Rails using Workers I too am eagerly waiting for a good serverless nodejs framework that is "batteries included". I've deployed on Lambda using the "Serverless Framework" but once your app grows to a certain size everything starts to fall apart and you lose some of the magic. Unfortunately, most of the things that advertise themselves as serverless/lambda/worker nodejs frameworks are…
Hey Josh,
I'm building a serverless firebase alternative that uses SQLite. If CF gives me access I will totally support D1 & workers.
Check it out: javascriptdb.com
Re: D1: Our SQL database
#136Earlier quoted context omitted.
> I hope someone creates the next Rails using Workers I too am eagerly waiting for a good serverless nodejs framework that is "batteries included". I've deployed on Lambda using the "Serverless Framework" but once your app grows to a certain size everything starts to fall apart and you lose some of the magic. Unfortunately, most of the things that advertise themselves as serverless/lambda/worker nodejs frameworks are…
Hey Josh, I'm building a serverless firebase alternative that uses SQLite. If CF gives me access I will totally support D1 & workers. Check it out: javascriptdb.com
Thanks! I'll check it out.
Re: D1: Our SQL database
#137The API for this is currently the only thing I wish I could grok a bit better. It seems like it would be hard to make it work with existing libraries that can access SQLite, which is kind of a shame. I'm thinking of sqlx in Rust (or any other language binding / ORM for that matter), which has compile time schema safety. This is a nice capability, and because this interface seems non-standard (possibly for good reason…
There might be a `env.DB.url` (e.g. the jdbc URL) which you could pass into an existing library.
I'm kinda willing to make a bet that this rides on top of what looks like HTTP to the Javascript engine. That's how their worker-to-worker and worker-to-durable-object protocols are.
(It's not really HTTP as in it might never cross a TCP socket, just get shuffled from one V8 isolate to another, but it looks like a `fetch` call to the Javascript.)
It's also worth remembering that SQLite itself has no wire protocol, it's a library. And there is no such thing as a "SQL wire protocol". It sure isn't gonna be Postgres wire protocol either.
From the article:
> D1’s API includes batching: anywhere you can send a single SQL statement you can also provide an array of them, meaning you only need a single HTTP round-trip to perform multiple operations. This is perfect for transactions that need to execute and commit atomically:
Re: D1: Our SQL database
#138Earlier quoted context omitted.
Biggest benefit over hosted PostgreSQL is that you get SELECT queries that are measured in microseconds, because SQLite avoids needing network overhead per query. https://www.sqlite.org/np1queryprob.html
Wouldn’t D1 introduce network overhead?
Yes for writes, but it shouldn't for reads: it looks like it works by replicating the full database down to each edge location where the code is running.
Re: D1: Our SQL database
#139Any 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.
Prisma won't work with D1 out of the box. The primary limitations are: - SQLite is traditionally embedded in an application, so Prisma interacts with it by mounting a file. Workers does not have a local filesystem, and D1 is exposed over the network through an API accessible from a Worker. Prisma will have to create a specific connector for D1. - Workers have a script size limit which is currently 1MB. My understandi…
> We are also very excited about D1 as a way to bring a subset of data closer to users in order to deliver faster experiences. We hope this will be a way to bring the benefit of edge computing to larger organisations who cannot simply rearchitect everything to run on Workers.
I am also excited about this :)
Re: D1: Our SQL database
#140Earlier quoted context omitted.
SQLite made sense as an embedded database on day a desktop or phone because there’s only a single person generally writing to it. The perfect use case. I don’t understand how it will be usable at all in a website with multiple users. Is the idea to make your site to every user gets their own database? How do you stop SQL injection? Once you solve all of these problems aren’t you better off just using Postgres?
> I don’t understand how it will be usable at all in a website with multiple users With WAL mode enabled the database is locked during writes only, and concurrent writes are queued but you can still perform reads concurrently. If you keep your write transactions small and consider that a lot of apps aren't writing a lot, it can give perfectly good performance for a lot of usecases. > Is the idea to make your site to…
Most of the problems with Postgres are a result of it not being embedded. If you’re using SQLite in an non embedded fashion I don’t see how you don’t inherit the same problems.