The problem with a "pointer" like this is that you then can't move stuff around as easily. SQL databases frequently reorganize the physical representation of rows to reclaim space used by deleted data, for example. Surely the same would apply to graph/object databases.

SQL databases _could_ conceivably optimize foreign key constraints behind the scenes by replacing/augmenting the referencing column with the physical location of the foreign row, but what do you do when the target row moves around in the physical store? You'd have to hunt down all the references and replace them. If anything can point to anything, that could have a cascading effect.

You could have conceivably have an indirection here: Instead of pointing to the physical location of another row, you pointed to the physical location of a special intermediate file that itself could contain the physical location. I don't know of any database that uses any tricks like these.