D1

D1 is serverless SQLite accessed from Workers — good for edge-adjacent metadata, feature flags, small admin config, or session indexes, not a drop-in replacement for PostgreSQL at origin scale. Migrations run through Wrangler; queries use prepared statements with binding parameters.

					const { results } = await env.DB.prepare(
  'SELECT id, slug FROM posts WHERE published = ? LIMIT ?',
)
  .bind(1, 20)
  .all();
				

| Limit area | Design response | |------------|-----------------| | Size and QPS | Keep tables narrow; cache hot reads in KV | | Replication | Understand read latency vs primary region | | Transactions | Use for small atomic updates only | | Joins at edge | Prefer denormalized keys for hot paths |

Treat D1 as complementary: authoritative user data may still live in RDS/PlanetScale while D1 holds edge-readable projections.

On interviews: D1 vs KV vs Durable Objects vs origin SQL, migration workflow, consistency, and when SQLite-at-edge is the wrong choice.

Common pitfalls: storing large blobs; high-write chat or ledger workloads; assuming PostgreSQL features (extensions, complex types); no backup/restore drill.

The trade-off is low-latency SQL at the edge versus SQLite limits, replication lag, and operational maturity versus managed Postgres.

Checklist:

• Model access patterns before schema design.
• Parameterize all Worker SQL.
• Cache read-heavy config in KV when needed.
• Keep authoritative financial data on origin DB.