See what I wrote above. I don't agree. We're gonna charge you to keep it around "forever", sorry.
See what I wrote above. I don't agree. We're gonna charge you to keep it around "forever", sorry.
IOh yeah, not expecting you to not charge for that 
IDefinitely do, everyone does.
MAnd then if you want to query that "locked" version, is that some special binding? How that does map to just being "another" DB? etc.
IOh no no, it's not an actually present and accessible db. It'd be a sort of snapshot saved you can revert to or clone out of.
IYou could use it to create another db or revert the one you are using back to that.
M(I'm intentionally being a little obtuse because I'm trying to understand why adding "more" to the data model is helpful) - so why not just make that another DB
- ?
MIf we let you have ~100+ DBs per account, or 1000?
IScaleway, for example, in their DB implementation (it's somewhat different, those are actual VMs running a managed DB instance on them) has a backup/snapshot feature. Billed per GB/month (sort of like it being saved to an object storage) which get discarded after some time you define. You can lock version to bypass this and keep them forever (with the cost, of course).
MRight, but that makes sense when you think about disk snapshots in a traditional, VM based system, without point in time recovery.
MSo you have to take snapshots.
IBecause, let's imagine you have a sort of sample dataset you use. You have multiple Workers, Pages sites, etc. connected to it. Now, you clone it out for initial data. You run things for a while and then you want to revert. Now you have to go and change where each of those things point to (by cloning the "backup" to a separate thing, because otherwise you loose it).
IWith a locked "snapshot" you can define, you just go there, click and replace the current instance.
IOr create another one.
IOh yeah, again, I'd be fine with both instances, they'd both work fine. It's mostly UX and having users handle the duplication vs. a simple "lock" which handles things in the backed automatically.
MI don't think that requires snapshots. If we let you clone over the top of another DB... then you can achieve that.
IOh if you do, then ok. Then 99% of the thing goes away.
MThe more new concepts we add, and the more "things" that can eat your bill (we have to list your snapshots, show usage by snapshot, etc) -> way more complexity.
II assumed you could only clone to new or to itself
MThis is why I push you
MNow, you clone it out for initial data. You run things for a while and then you want to revert. Now you have to go and change where each of those things point to (by cloning the "backup" to a separate thing, because otherwise you loose it).
IOh yeah, I'm happy to engage in this 
MThat was your problem in a nutshell 
IYeah, with the ability to clone over something else that exists already then yeah. it's just some UX, but it makes sense. Cloudflare is more dev focused, a Scaleway has a slightly wider user base that would go to it.
V@elithrar Do you guys have a date in mind when you will start allowing size limit increase?
MNot that we're sharing yet. It will coincide with the beta. We won't be doing one-off increases.
S@elithrar D1 Seems pretty stable now, what's holding off beta other than metrics and time-travel?
VIn https://developers.cloudflare.com/workers/wrangler/configuration/#d1-databases, it says to use
iddatabase_idWrangler optionally uses a wrangler.toml configuration file to customize the development and publishing setup for a Worker.
Cdatabase_id
CHi everyone, I face an issue or not support that the
From the screenshot, the ID is always null.
id SERIAL PRIMARY KEYFrom the screenshot, the ID is always null.
In this tutorial, you will learn how to create a Cloudflare Workers application and connect it to a PostgreSQL database using TCP Sockets. The Workers …
VD1 is running on SQLite, not PostgreSQL
Vtry
id int primary key autoincrement
CDoes D1 has multi column primary key? 
CI keep getting error from this
CThe error
T@chientrm I believe
PRIMARY KEY
CThank you so much 
CI run wrangler dev --remote when dev.
When dev, the error message is
But in production, it's just
When dev, the error message is
D1_ERROR: Error: ERROR 9007: SQL execute error: UNIQUE constraint failed: User.emailBut in production, it's just
D1_ERROR: ErrorOn web console, the error is returned correctly:
ERROR 9015: SQL engine error: query error: Error code 2067: A UNIQUE constraint failed (UNIQUE constraint failed: User.email)Oke I figured it out, on production the error message is at 
error.cause?.message
MIs anyone using d1 currently for a service they’re selling
CJust use it, it's sqlite
AIt's definitely a bit of a risk to use it right now, given it's alpha state there is a possibility for unexpected errors. That being said, from my experience D1 is mostly quite stable.
It's been said a few times before in this channel, but once backups are available for the new D1 backend, the risk for using this in production is much lower.
It's been said a few times before in this channel, but once backups are available for the new D1 backend, the risk for using this in production is much lower.
Mhi all, is there anywhere to follow along with the D1 roadmap? Looking for updates on read replication
IThat changelog not being date ordered is not nice 
let me PR that 
let me PR that 
I
MThat would be a interesting solution. Only thing I wonder for something like d1 is say I use it to store e-commerce orders for my saas. What happens when I have over 100gb of data and ex hit the db size limits? Is there spread the data across multiple d1 databases at that point?
UWe dont even know what the limits of production ready D1 will be yet so we cant really give any advice for that yet 
Mis there a limit to the size of queries you can run with
wrangler d1 execute?