Add a database that keeps your app's data

Outcome and starting state

Move from browser-local task state to a durable data model. Prove that a task survives a new database connection and that an additive schema change preserves old records. You need a working app and its existing data layer. VibeField uses Drizzle with libSQL; keep your app's supported driver rather than adding a second database stack just for this lesson.

The database exercise download uses Python 3.10+ and its standard SQLite module to make the persistence boundary visible without an account. It is an isolated command-line example, not a Next.js database adapter. Database feature implementation guides the app integration; Data model worksheet holds the model and migration record.

1. Model one journey

A task has id, owner_id, and a nonblank title of at most 120 characters. The owner is a relationship to the application's user identity; the isolated exercise uses sample IDs A and B without pretending to authenticate them. Add a nullable description only in the second migration. List the screens that create and read these fields before changing the schema.

Inspect [PROJECT]'s existing database driver and screens. Model the task journey:
id, owner, validated title, and later an optional description. Explain constraints,
relationships, and where data survives. Use the project's migration conventions
and disposable development data; keep credentials on the server.

2. Create a disposable development database

From the extracted examples/task-database directory:

python database.py --db demo.sqlite init
python database.py --db demo.sqlite add --owner A --id task-1 --title "Review the release"
python database.py --db demo.sqlite list --owner A