More prosaically, the AtomTable maintains a pointer to every atom that has been inserted into the AtomSpace, together with the in-RAM indexes needed to locate a node, given only its name (and type), or link, given an outgoing set and type. The AtomSpace uses these indexes to determine if an atom exists, and to locate the one globally-unique copy, if it does.
The AtomTable is central to garbage collection and memory management: an Atom will always continue to exist in RAM, as long as the AtomTable is maintaining a pointer to it. In general, an atom will continue to exist in RAM, as long as someone is holding a pointer to it; when there is no one else, the someone defaults to the AtomTable.
The AtomTable should be thought of as the in-RAM cache of the grand-total AtomSpace. Large portions of the AtomSpace may sit in SQL storage, or in some other persistent storage mechanism/device. However, once materialized into local RAM, they become available in the AtomTable. Thus, the contents of the AtomTable can be purged to disk and restored from disk; these operations are under explicit algorithmic (user) control, and are not automated in any way. Its not automated because its essentially impossible to figure out how an algorithm might want to access atoms in RAM, and thus, at what times its efficient to save/restore them.