Rows in memory-optimized tables are stored as heaps. These heaps are not to be confused with heaps in the traditional storage engine, but are memory structures storing the row data itself. These rows have no specific physical ordering and no requirement or expectation of being located near to other rows in memory. They also have no knowledge of connected rows themselves, they are solely created to store row data. The connection of these rows is controlled via the indexes created on memory-optimized tables. Knowing that the index stores and controls the connection of the memory-optimized row data heaps, we can infer that a table must have at least one index. This index (or indexes) must be defined during table creation.

In the introduction to the chapter, we mentioned that the In-Memory OLTP system is an implementation of the optimistic concurrency model. This model uses row versioning to allow concurrent connections to change data and still provide the necessary isolation. Row versioning is an important part of how memory-optimized tables are structured. Let's look at how a row is structured for a memory-optimized table.

In the following figure, we can see a depiction of a memory-optimized table, which is split into a row header (information about the row) and payload (the actual row data). The Row Header structure is expanded in the lower part of the image: