D1 runs on Durable Object (DOs), which are only in specific colos/pops and regions: https://where.du

C

ChaikaOP•1/31/24, 6:55 PM

employees have mentioned a few times that south america support is planned d1-database

CChaika D1 runs on Durable Object (DOs), which are only in specific colos/pops and regio...

K

K•1/31/24, 7:05 PM

Haven't seen this site before. Thank s for pointing it out.

PPatrick Did you end up converting your boolean types to integers? Running into Error: D...

G

Gagan Suie•1/31/24, 7:54 PM

Yes. Convert to int and store in DB as 1/0

DDavid Renshaw I have a fresh database and an initial migration: ``` -- I don't expect there to...

M

Max (@rozenmd)•1/31/24, 8:11 PM

it's a bug in the API, yeah

M

Max (@rozenmd)•2/1/24, 1:40 PM

we should really stop calling them experimental

V

Vignesh•2/1/24, 6:14 PM

Can I store 40gb db on D1?

VVignesh Can I store 40gb db on D1?

Z

zegevlier•2/1/24, 6:41 PM

Not right now, no: https://developers.cloudflare.com/d1/platform/limits/

Z

zegevlier•2/1/24, 6:42 PM

That limit is marked as beta and subject to increase, but if it'll increase >40gb I do not know

Z

zegevlier•2/1/24, 6:42 PM

If you really want to use D1 you might be able to store it as several smaller databases though

B

bun•2/2/24, 12:03 AM

i inserted like 2000 records. tried quering a random record by id. it takes ~130-150 ms. is this expected even after multiple requests?

B

bun•2/2/24, 12:05 AM

import { Hono } from "hono";

const app = new Hono<{
  Bindings: {
    DB: D1Database;
  };
}>();

app.get("/", async (c) => {
  const result = c.env.DB.prepare(`
    select * from users where id = 420;
  `);

  const t = performance.now();

  await result.first();

  return c.text(`Query took ${performance.now() - t}ms`);
});

export default app;

import { Hono } from "hono";

const app = new Hono<{
  Bindings: {
    DB: D1Database;
  };
}>();

app.get("/", async (c) => {
  const result = c.env.DB.prepare(`
    select * from users where id = 420;
  `);

  const t = performance.now();

  await result.first();

  return c.text(`Query took ${performance.now() - t}ms`);
});

export default app;

import { Hono } from "hono";

const app = new Hono<{
  Bindings: {
    DB: D1Database;
  };
}>();

app.get("/", async (c) => {
  const result = c.env.DB.prepare(`
    select * from users where id = 420;
  `);

  const t = performance.now();

  await result.first();

  return c.text(`Query took ${performance.now() - t}ms`);
});

export default app;

import { Hono } from "hono";

const app = new Hono<{
  Bindings: {
    DB: D1Database;
  };
}>();

app.get("/", async (c) => {
  const result = c.env.DB.prepare(`
    select * from users where id = 420;
  `);

  const t = performance.now();

  await result.first();

  return c.text(`Query took ${performance.now() - t}ms`);
});

export default app;

B

bun•2/2/24, 12:39 AM

i get 0.150-0.300 on duration

B

bun•2/2/24, 12:39 AM

is it 150-300 ms ?

B

bun•2/2/24, 12:42 AM

ah so it takes actual 0.1-0.3 miliseconds

B

bun•2/2/24, 12:42 AM

then why is networking such an issue? is it because the worker it not located close to the database?

C

ChaikaOP•2/2/24, 12:43 AM

yea duration is in milliseconds. You can see where your worker is in via `npx wrangler d1 info <db-name>, and look for running_in_region

B

bun•2/2/24, 12:44 AM

you mean worker or db ?

B

bun•2/2/24, 12:45 AM

ok latency is reduced to 10ms after i enabled smart placement

C

ChaikaOP•2/2/24, 12:45 AM

That would show the location of the db. Worker is likely way closer to you. You could look at

https://<worker-host-name>/cdn-cgi/trace

https://<worker-host-name>/cdn-cgi/trace

https://<worker-host-name>/cdn-cgi/trace

https://<worker-host-name>/cdn-cgi/trace i.e

https://cloudflare.com/cdn-cgi/trace

https://cloudflare.com/cdn-cgi/trace

https://cloudflare.com/cdn-cgi/trace

https://cloudflare.com/cdn-cgi/trace and look at colo= for the airport code of where the worker is running

C

ChaikaOP•2/2/24, 12:45 AM

if you have smart placement on then you'd look at the cf-placement response header

C

ChaikaOP•2/2/24, 12:46 AM

also make sure your db version shown in d1 info is beta, not alpha

B

bun•2/2/24, 12:48 AM

yeah with smart placement latency is low. however, it increases the request latency from 10 ms to 100-200 ms now. honestly i think there should be easier way to solve the problem im trying to deal with right now.

i have like less than 1 mb JSON data that i want to somehow have ready at all point of worker requests.

i tried getting it from r2 and caching but it didnt work for some reason.

do you think it would be better to just include the data in the bundle instead of using database for this?

C

ChaikaOP•2/2/24, 12:49 AM

where are you/where are your users geographically? Are you in a region like South America/South Africa?

B

bun•2/2/24, 12:49 AM

no im in eastern europe

C

ChaikaOP•2/2/24, 12:50 AM

oh so D1 should be close unless it was created with a location hint far away or for some reason created itself in a region far away

B

bun•2/2/24, 12:50 AM

i created it manually with eastern europe setting

Bbun yeah with smart placement latency is low. however, it increases the request late...

C

ChaikaOP•2/2/24, 12:50 AM

The question about bundling it would come down to if it changed and if so how frequently

B

bun•2/2/24, 12:51 AM

the data wouldnt change

B

bun•2/2/24, 12:51 AM

at all

C

ChaikaOP•2/2/24, 12:52 AM

then I think bundling would be a good idea. If you are on Workers Paid you get up to 10 mb, but if you go over 1 mb you get put in slower storage/slightly slower then first request, still super fast. If your worker is below 1 mb then your worker is ready to go on every machine

B

bun•2/2/24, 12:53 AM

1mb compressed ?

C

ChaikaOP•2/2/24, 12:53 AM

yea gzip

B

bun•2/2/24, 12:54 AM

im on workers paid yes

B

bun•2/2/24, 12:54 AM

so everything below 1 mb does not affect performance ?

B

bun•2/2/24, 12:54 AM

then it affects only on initial request?

C

ChaikaOP•2/2/24, 12:54 AM

D1 at the moment is a single location with read replicas eventually
R2 single location + cache (although you could cache any of these)
DOs are single locations
KV is made for read heavy stuff but two locations until cached
Worker Scripts less then 1 mb are everywhere
https://developers.cloudflare.com/workers/platform/storage-options/

Bbun so everything below 1 mb does not affect performance ?

C

ChaikaOP•2/2/24, 12:55 AM

well if you were doing a lot in the global scope you could still have a cold starts

C

ChaikaOP•2/2/24, 12:55 AM

should prob move to #workers-discussions if you wanted to ask more about that idea

B

bun•2/2/24, 12:55 AM

yeah sure

Bbun the data wouldnt change

M

Max (@rozenmd)•2/2/24, 7:09 AM

make it a const in your worker if it never changes

T

tt•2/2/24, 1:56 PM

Is there any mention anywhere about the SQLite version of D1?

Ttt Is there any mention anywhere about the SQLite version of D1?

M

Max (@rozenmd)•2/2/24, 2:08 PM

https://github.com/cloudflare/workerd/blob/main/WORKSPACE#L67

MMax (@rozenmd)https://github.com/cloudflare/workerd/blob/main/WORKSPACE#L67

T

tt•2/2/24, 2:09 PM

Thanks!!

K

kgni•2/2/24, 2:28 PM

Hi there. Sorry in advance for the noob question.

Does binding values have to be unique when using the Wrangler CLI /

wrangler.toml

wrangler.toml

config?
E.G: if I have multiple environments, that I want to connect to different D1 databases.

I'm a bit confused since in the dashboard it seems like you create 1 binding per 1 database, but when using the

wrangler.toml

wrangler.toml

config file and the CLI, the binding name seems to be used more like an environment variable that you can then use in your worker.

Would the following 2 environments point to 2 different databases even though the binding names are the same?

[env.staging]
d1_databases = [
    { binding = "DB", database_name = "staging", database_id = "unique_db_id_1", migrations_dir = "migrations", preview_database_id = "DB_STAGING" },
]
workers_dev = true

[env.production]
d1_databases = [
    { binding = "DB", database_name = "production", database_id = "unique_db_id_2", migrations_dir = "migrations"},
]

[env.staging]
d1_databases = [
    { binding = "DB", database_name = "staging", database_id = "unique_db_id_1", migrations_dir = "migrations", preview_database_id = "DB_STAGING" },
]
workers_dev = true

[env.production]
d1_databases = [
    { binding = "DB", database_name = "production", database_id = "unique_db_id_2", migrations_dir = "migrations"},
]

[env.staging]
d1_databases = [
    { binding = "DB", database_name = "staging", database_id = "unique_db_id_1", migrations_dir = "migrations", preview_database_id = "DB_STAGING" },
]
workers_dev = true

[env.production]
d1_databases = [
    { binding = "DB", database_name = "production", database_id = "unique_db_id_2", migrations_dir = "migrations"},
]

[env.staging]
d1_databases = [
    { binding = "DB", database_name = "staging", database_id = "unique_db_id_1", migrations_dir = "migrations", preview_database_id = "DB_STAGING" },
]
workers_dev = true

[env.production]
d1_databases = [
    { binding = "DB", database_name = "production", database_id = "unique_db_id_2", migrations_dir = "migrations"},
]

N

neal•2/2/24, 3:56 PM

Hi! I'm using the D1 database for a game I'm working on https://twitter.com/nealagarwal/status/1752716375255101440

The database appears to be down after a large traffic spike. Is there anyone that could help debug?

Neal Agarwal (@nealagarwal) on X

The first version of Infinite Craft, an endless crafting game, is out now!

https://t.co/tb51ejeqsK

Twitter

•

1/31/24, 3:32 PM

D1 runs on Durable Object (DOs), which are only in specific colos/pops and regions: https://where.du

Similar Threads

Similar Threads

Similar Threads