Checkout the previous post on How I deployed my Astro + Turso + Drizzle project to Cloudflare Pages if you want to know more about the project.
Background
I wanted to migrate my Turso DB to Cloudflare D1. As such this post will go into the details of the challenges I faced during the migration process.
You can find the project and the repository below:
Challenges
Making D1 work with drizzle and Astro
D1 as well as drizzle-kit requires the project to have a wrangler.toml file. Here is mine:
#:schema node_modules/wrangler/config-schema.json
name = "map"
compatibility_date = "2024-10-11"
pages_build_output_dir = "./dist"
[placement]
mode = "smart"
[vars]
NODE_VERSION = "20.17.0"
PNPM_VERSION = "9.9.0"
[[d1_databases]]
binding = "MAP"
database_name = "map"
database_id = "10eb6d23-6724-46e8-9bf2-c4091739f69f"
migrations_dir = "migrations"
migrations_table = "__drizzle_migrations"
Ensure the corresponding D1 binding is also set in Cloudflare dashboard. Based on their docs it seemed like drizzle expects the argument to be of type D1Database. Since env.d.ts file is being used throughout the application for environment related stuff, I updated it like so:
/// <reference path="../.astro/types.d.ts" />
type Runtime = import("@astrojs/cloudflare").Runtime<Env>;
declare namespace App {
interface Locals extends Runtime {
env: {
CLOUDFLARE_ACCOUNT_ID: string;
CLOUDFLARE_DATABASE_ID: string;
CLOUDFLARE_D1_TOKEN: string;
CLOUDFLARE_D1_BINDING: string;
MAP: D1Database;
};
}
}
interface ImportMeta {
readonly env: {
readonly CLOUDFLARE_ACCOUNT_ID: string;
readonly CLOUDFLARE_DATABASE_ID: string;
readonly CLOUDFLARE_D1_TOKEN: string;
readonly CLOUDFLARE_D1_BINDING: string;
};
}
If you observe, MAP in the env.d.ts file matches the binding in the wrangler.toml file.
Turso dump was not working
I wanted to take a dump of my data. After searching, I found out about the dump command. I ran turso db shell map-viz ".dump" > map-viz.sql. map-viz being the name of my database. However, every single time, the map-viz.sql was being created with empty content. I'm not sure what was wrong since I was correctly executing the command and the data was also present. So I finally resorted to manually exporting the data in the CSV format.
D1 does not support importing data in the CSV format
Feeling good about myself after clearing the Turso hurdle, I was disappointed to find out that D1 does not support CSV import (at least as of this writing). So how to solve this new issue then?
I updated my env to point to the hosted D1 and ran pnpm db:migrate to apply the migrations to my database. Good thing was D1 allowed running SQL queries directly. Since I had the CSV data, I wanted to create SQL statements from it. What good way than to use Claude for this. I asked it to write SQL queries and provided it a couple of CSV records. After modifying the output a bit, here is the final JS file which I used:
const fs = require("fs");
const csv = require("csv-parse/sync");
const fileName = "location.csv";
const tableName = "location";
// Function to escape single quotes in string values
function escapeQuotes(value) {
return value.replace(/'/g, "''");
}
// Function to format value for SQL
function formatValue(value) {
if (value === "") return "NULL";
if (isNaN(value)) return `'${escapeQuotes(value)}'`;
return value;
}
// Read the CSV file
const fileContent = fs.readFileSync(fileName, "utf8");
// Parse the CSV content
const records = csv.parse(fileContent, {
columns: true,
skip_empty_lines: true,
});
// Generate INSERT statements
const insertStatements = records.map((record) => {
const columns = Object.keys(record).join(", ");
const values = Object.values(record).map(formatValue).join(", ");
return `INSERT INTO ${tableName} (${columns}) VALUES (${values});`;
});
// Write INSERT statements to a file
fs.writeFileSync(`${fileName}.sql`, insertStatements.join("\n"));
console.log(`INSERT statements have been written to ${fileName}.sql`);
After running the script it generated the SQL statements like so:
INSERT INTO location (id, created_at, updated_at, latitude, longitude, city, region, region_code, country, hash, count, last_visit) VALUES (54, '2024-10-12 11:21:03', 1728732060, -34.0866, 18.8144, 'Somerset West', 'Western Cape', 'WC', 'ZA', '-34.08660-18.81440-Somerset West-Western Cape-WC-ZA-45.222.74.86', 1, 1728732060);
INSERT INTO location (id, created_at, updated_at, latitude, longitude, city, region, region_code, country, hash, count, last_visit) VALUES (64, '2024-10-12 17:19:12', 1728753549, 46.3153, 4.8344, 'Mâcon', 'Bourgogne-Franche-Comté', 'BFC', 'FR', '46.31530-4.83440-Mâcon-Bourgogne-Franche-Comté-BFC-FR-2a01:cb10:82ae:c600:259e:a34c:1e8e:a4b5', 1, 1728753549);
SQL commands now being generated, the last step was to import the data. For which I ran wrangler d1 execute map --file=./location.csv.sql --remote and voila! The data was there in my D1 database.
Conclusion
Even though I faced some challenges during integration of Cloudflare services and migrating data, moving to D1 was a good decision since the initial load times have pretty much been cut in half.
Top comments (0)