Course lesson 50 · Better Auth

Configuration & Schema Creation

One study unit · Read, recall, then practice · Original video 00:15:44

Better Auth configuration is connected to the existing Drizzle workflow so authentication tables can be generated and then created in D1. A shared factory supports both schema generation, where provider credentials are unnecessary, and runtime initialization, where they are required. The generated authentication schema is also registered with the runtime Drizzle adapter, and package exports are repaired after TypeScript’s output layout changes.

Primary source: course video 50 · Supplied English subtitles · 00:15:44.

Understand the idea

The original workflow introspects manually created D1 tables into Drizzle schema definitions.
The new authentication workflow goes from Better Auth configuration to Drizzle schemas to SQL creation statements.
Generation-time configuration can use placeholder database information because it describes the schema rather than serving real requests.
Runtime configuration receives the actual Drizzle-backed database and Google credentials.
A single configuration factory keeps schema-generation choices aligned with application behavior.

What the course does

Create shared Better Auth setup with email/password disabled and Google provider support.
Implement the runtime accessor using the project’s existing Drizzle database setup.
Configure a generation entry point with the SQLite Drizzle adapter and point the Better Auth CLI at it.
Generate the user, session, account, and verification schemas, then generate their SQL statements.
Execute the required statements against stage and production D1 and supply schema references to the runtime adapter.
Update package exports to the new dist/source layout after including the generation folder in TypeScript compilation.

Watch for

The instructor deletes generated migration metadata to produce creation SQL; the course is not using those files as an authoritative migration history.
The narration says six tables after executing six statements, but the core schema explicitly shown is user, session, account, and verification.
Adding a plugin later requires regenerating and applying its schema changes, not merely changing a runtime flag.

Recall before revealing

Why share one Better Auth configuration factory between generation and runtime?

Reveal the explanation

It keeps the enabled providers and plugins aligned, while allowing generation placeholders and real runtime dependencies to be supplied differently.

Try it

Write the ordered steps required after adding a plugin that needs a new table.

Check your result

You include configuration, schema generation, SQL generation, applying database changes, and making the runtime adapter aware of the schemas.

Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.

Rewatch only what you need

Open this lesson in your original course library and seek to the times below. Videos are not hosted on this site.

00:01:33 — Configuration-to-schema-to-SQL workflow
00:06:10 — Generation credentials versus runtime credentials
00:09:43 — Generated core authentication schemas
00:13:48 — Fix package output and exports

Companion primary documentation: Better Auth basic usage. For recorded API names, commands, limits, and prices, check the version you use.

← Previous Next →