> While it is true that there will be a surrogate key (the row ID), that doesn't imply there is any sort of index as there is in SQLite. In PG heaps it does, t

> While it is true that there will be a surrogate key (the row ID), that doesn't imply there is any sort of index as there is in SQLite. In PG heaps it does, though it's not stable across `VACUUM`. From what you say the same is true of SQL Server. The point being that two duplicate rows in a table w/o a `PRIMARY KEY` will have different "row IDs" or "ctids" or whatever even though that row ID or ctid will not be stable across vacuuming though it should be stable across a single query. (In PG all tables are heaps, always. You can have indices, and even covering indices, and your read queries might never hit the heap, but a heap will be there. IMO PG ought to support a b-tree instead of a heap for tables with `PRIMARY KEY`s -- it would be an improvement, and a performance optimization.)