Consider that "integer primary key" gives a name to something that's _already there_ for the table to begin with. So including the integer primary key definition at the start isn't going to slow it down in the same way as adding the other indexes at the start vs at the end. (Though, if I recall correctly, with an "integer primary key", if you insert your IDs in random order it'll be a little slower than without the "integer primary key", as without it the rowids can just be assigned in insertion order, meaning less Btree manipulation as you go. But if you insert your "integer primary key" data in primary key order then it'll be the same, and save you the cost of building the extra index later)