In case you're still curious, I think the reason it isn't included is because auto-increment is a hard problem to do right, ends up being a leaky abstraction fo

In case you're still curious, I think the reason it isn't included is because auto-increment is a hard problem to do right, ends up being a leaky abstraction for technical reasons, causes bugs, and is philosophically sub-optimal for basically any use case you can dream up. Want to order? Dates are probably always a better thing to order by, or else some natural property of the data like name or title. Want to link two records together? GUIDs are so much better it's not even a contest. In development, auto-increment appears to be previous field +1. Developers write code expecting that behavior and relying on continuous IDs without gaps. But, well, for example, Oracle doesn't rollback sequence values. They also pull them in blocks (I think blocks of 20?). So sometimes you can end up with numbering like 1,2,3,20,22 if things were weird at just the right time, and you probably never saw it during development or QA unless you happened to know to try to force it. Then you get things like SQL Server resets auto increment field values on database export/import, so numbering which used to have gaps in the original will have no gaps in the import, causing the numbers to change. (I have no idea why, just seems like a bug/disaster waiting to happen.) Changing some ID fields tends to cause obvious disasters, as you usually have several tables which store a copy of the old auto ID value to join on. I've seen several production data loss issues as I learned about the joys of this data type and prefer to avoid them as I learned more.