Mcan you rerun it with
fts5 instead of FTS5? looks like a bug
IGitHub
The Experimental Backend doesn't allow using CURRENT_TIMESTAMP when running any type of query. It's supported perfectly when it's set as default value for a column.
Munixepoch is supported. Does that create table statement work outside of D1? Usually you can’t have functions like that.Mhttps://github.com/cloudflare/workerd/blob/bc3fc4cdd309dccc553e18240ef432a39f53d5eb/src/workerd/util/sqlite.c%2B%2B#L171 (the function is typo’ed on the allowlist)
GitHub
The JavaScript / Wasm runtime that powers Cloudflare Workers - workerd/sqlite.c++ at bc3fc4cdd309dccc553e18240ef432a39f53d5eb · cloudflare/workerd
MNot at my computer so asking, otherwise I’d test.
Mwhat are you using to insert btw?
a basic example seems to work:
a basic example seems to work:
Mdefault backend or experimental btw?
Mah okay I'll try again on the default, I just tested on the experimental one
Moh ok
Mnot a waste, always worth double checking these things 
L@elithrar @rozenmd I wrote a code for D1. However, this code gives the following error when there are too many requests:
Can I send the code via pm?
NOT:*It works with few users. but it does not work when there are many instant requests.
{
"message": "Error while checking rows: Error: D1_ERROR\n at D1Database._send (worker.js:149:13)\n at async D1PreparedStatement.all (worker.js:215:7)\n at async Object.fetch (worker.js:11:18)"
}Can I send the code via pm?
NOT:*It works with few users. but it does not work when there are many instant requests.
MBetter to post it here: we can't formally/directly support folks via DM, but others may be able to help 
MWhat's your database ID? And is this on the
--experimental-backend or the original alpha backend?MPerfect, thanks. Let me see if I can track down the log entry on our side.
MImportantly, when we enable global read replication, you won’t have to pay extra for it, nor will replication multiply your storage consumption
MThe Cloudflare Blog
We've been heads down iterating on D1, and we've just shipped a major new version that's substantially faster, more reliable, and introduces Time Travel: the ability to restore a D1 database to any point in time.
IOne question I have about read replication, would it improve performance when writing to the DB? I now see a reduction in performance on write when running any sort of
SELECTAnd secondary question, any ETA on backups on the experimental backend? It's very hard to export data now, even a manual backup would be great in the meantime.
MClients will read from the (geographically) nearest read replica. That may sometimes be the leader (write+read). What kind of perf reduction are you seeing here?
M(Per the blog) We're entirely moving to Point in Time Recovery for the foreseeable future vs. snapshot based backups, since PITR is a) infinitely more flexible and b) is better than snapshots in terms of actually restoring your DB. What you won't be able to do until GA is export a DB directly.
INot much, tbh, but I've doing a lot of requests and I saw some slowdowns after a couple of queries in the console (somewhat big, but not massive ones). Understood. Will check next time the queue runs and in case report back
One thing I'm not sure about iswhere would a scheduled Worker run and, more importantly (this was dumb 
) where the consumers for queues would run to locate the db closer to there (especially with the replicas on the horizon as the users would hit only the read side)
One thing I'm not sure about is
) where the consumers for queues would run to locate the db closer to there (especially with the replicas on the horizon as the users would hit only the read side)II see, so the wait is for the Time Travel feature... hopefully soon!
IA good export option would be nice regardless, tbh
MWe'd need to solve import - you may not care, but many others will. Import is also tricky to solve.
MYou shouldn't typically see a slowdown as our storage implementation is non-blocking (it's effectively a WAL-mode implementation):
WAL provides more concurrency as readers do not block writers and a writer does not block readers. Reading and writing can proceed concurrently.
IOh yeah, I had to bypass that, too... but you can use a very big
.sqlIt might have been something else, unfortunately I don't have just DB calls, but also a
1.1.1.1 fetch and it's a queue consumer, so who knows. Will report back if it becomes a pattern 
MRETURNING *MINSERT INTO some_table (name) VALUES ('something') RETURNING id for example