Getting Started

Reality check for Laravel developers: thecodingmachine/tdbm-bundle is a Symfony bundle, not a Laravel package. It registers TDBM services and console commands in a Symfony kernel. You cannot install it into a Laravel app and use it via Eloquent or Artisan. If you want TDBM's schema-first ORM in Laravel, use the standalone thecodingmachine/tdbm library and wire DAOFactory yourself in a service provider.
If you are in Symfony: composer require thecodingmachine/tdbm-bundle, enable TDBMBundle in config/bundles.php, set DATABASE_URL, and add config/packages/tdbm.yaml with bean/DAO namespaces and connection settings. Run the bundle's generation command (typically bin/console tdbm:generate) to produce beans and DAOs from your schema.
First use case: point it at an existing MySQL/PostgreSQL schema, generate one DAO per table, then inject DAOFactory and call $daoFactory->getUserDao()->findAll() or $userDao->save($user). This is the closest to "database-first scaffolding" you get in PHP.
Look first at: the bundle README for config keys and commands; TDBM's own docs for DAO/bean generation semantics, annotations, and inheritance; your generated src/Bean and src/DAO directories to see what it produced.

Implementation Patterns

Schema-first generation loop: design/migrate the database, run generation, commit generated beans/DAOs, and regenerate after every schema change. Treat generated code as build output that happens to be committed.
DAO-centric data access: unlike Eloquent's active record, TDBM separates beans (data) from DAOs (queries/persistence). Inject DAOFactory or specific DAOs and use find, findAll, save, delete. Keep query logic in DAOs or repositories, not in beans.
Laravel standalone wiring (if you insist): add thecodingmachine/tdbm via Composer, create a TdbmServiceProvider binding a singleton DAOFactory using Laravel's DBAL connection, and add an Artisan command that shells out to TDBM's generator. Keep generated code under app/Generated and exclude it from PHPStan/coverage.
Symfony integration: rely on the bundle's service autowiring for DAOFactory and generated DAOs; use Symfony's DBAL connection for transactions; use TDBM's event/annotation hooks for lifecycle logic instead of editing generated files.
Testing: use DBAL transactions to roll back per test; generated DAOs work against a real schema, so prefer a migrated test database over mocks. Seed minimal rows and assert through DAO queries.

Not interchangeable with Eloquent: no Model::where(), no relationships via Eloquent, no Artisan make:model. TDBM handles foreign keys and generated methods, but it is a different mental model.
v6.1.0 is a compatibility release: the only change is Symfony 7 support (new contributor PR). It does not add Laravel support. Check PHP/Symfony constraints before upgrading; if you're on Symfony 6, v6.0.0 is equivalent for your needs.
Generated code overwrites: never hand-edit generated beans/DAOs. Put custom behavior in subclasses, TDBM annotations/events, or separate services. Configure generation namespaces so custom and generated code don't collide.
Config quirks: the bundle expects Symfony bundle registration and tdbm config; a missing config/bundles.php entry or wrong namespace silently produces no services. For standalone TDBM, you own the DAOFactory construction and must pass the correct DBAL connection and naming strategy.
Debugging SQL: TDBM sits on Doctrine DBAL; enable DBAL logging/middleware in Symfony or Laravel to see generated queries. If a DAO method is missing, regenerate after schema changes.
Extension points: custom DAO factories, TDBM's bean/DAO annotations, and DBAL event middleware are safer than forking generated code. For Laravel, the extension point is your service provider binding and generator command.