The keyless password reset table survives because nothing in the running application ever asks for a primary key. The scaffold declares email and token NOT NULL, created_at nullable, and one non-unique KEY on email [6]. The lookup path the app uses is indexed, so no query gets slower and no test goes red. What the DDL as printed also permits is two rows for the same address, because a non-unique index with no PRIMARY is no uniqueness at all [7]. Twill is the evidence that this was inherited rather than chosen: it renamed its copy to twill_password_resets in its own migration and left the keys alone [8]. The rename touched the table name only; the primary key and index stayed exactly as the scaffold had set them.
Foreign keys turn out to be just as sparse as the missing primary keys. Snipe-IT is a mature asset manager with 58 tables held together by exactly one foreign key [10]. Cachet sits in the middle with 32 tables and three keys, about one per eleven tables [13][4], and its schema is full of columns that name their target with _id, in the right type, next to the table they point at [13]. The ->foreign() call is the only interface between an Eloquent relationship and a database constraint, and where no migration outside vendor/ makes that call, the models are the only place the relationship exists [11]. Alberto Arena attributes part of the split to portability: several of these projects ship migrations meant to run on MySQL, PostgreSQL and SQLite alike, and he names the foreign key as the main casualty of that choice [12].
For the roughly-half figure to transfer to your codebase, the incentive has to transfer with it. Every application in the census is a codebase you can clone and read [1], so each one installs onto a database somebody else administers, which makes multi-engine migrations a product requirement rather than a preference [12]. If your Laravel app runs on one engine you own, that constraint never applied to you, and you can still end up with the schema it produces, because the framework and the ecosystem around it chose first [2]. The relationships in the schema-free half are real; they live where an ER diagram cannot see them [14].
Two coverage lines are worth copying down alongside the numbers. Relationship counts cover all fifteen applications, less Statamic, which the census holds out of that ranking for a reason handled in its own section, leaving a ranking fourteen wide [3][9][5]. The structural checks cover twelve databases and 482 tables, of which seven are real applications and five are bare Laravel baselines kept as a control [4], so eight of the fifteen never ran the tooling that found the keyless tables [2]. Six is a floor. At 811 tables across fifteen applications the corpus averages about 54 tables each [1], which is a workable definition of past the tutorial stage [2].
The generic form of this is that whichever generator wrote your first ten migrations still owns them until somebody reopens the file, and that is the mechanism the census documents rather than any failure of care in the four projects still carrying the old shape [2].
