Question

Normally we can give more values, at the maximum, how many rows a table can have in SQL Server? After that we can’t add a new row.

Answer 1

There are a couple of edge cases (outside of the obvious disk space issue) where SQL Server will prevent you from adding more rows, not about number of rows exactly but thought worth mentioning:

• you have an IDENTITY column and you hit the end of the range for the data type, e.g. 255 for TINYINT, 2,147,483,647 for INT, some ungodly number that starts with a 9 – possibly the number of inches to the sun and back – for BIGINT, etc. When you try to insert the next row, you’ll get error message 815 about overflowing the type. This has nothing to do with the number of rows already in the table, per se, but rather the number of rows you’ve already tried to insert (without re-seeding the IDENTITY column). If you have a high percentage of rollbacks (or a large number of successful inserts), you may want to keep track of the max value in this column over time.

• if you have a heap with a non-unique index, or a clustered index that is not unique, you won’t be able to store more than 2 * 2,147,483,647 unique index key combinations. When you try to insert (2 * 2,147,483,647) + 1 rows with a value of 1 in an INT column that is the only column in a clustered index, you will get error message 666 about exhausting the uniqueifier. This is because the uniqueifier (which helps SQL Server identify a row when there is no true key) is only 4 bytes, which means it can’t exceed the capacity of an INT (it does use both positive and negative, unlike IDENTITY unless configure it as such, which is why you get double). Now why you would ever do this, <shrug>… but you could.

• in the VLDB space, a database can only be 524,272 terabytes. Again a very edge case, but if you have a humongous data warehouse then obviously at some point the number of rows – depending on row size – will put you near this limit. I think petabyte databases, while they allegedly exist in some corner of some lab somewhere, are largely theoretical at this point. I suppose technically the “Limited by available storage” statement on the Max Capacity page for SQL Server could take this max size into account, or they could just assume that nobody will ever have more than 524,272 terabytes of storage available to a single instance of SQL Server (which is probably a reasonable assumption today, but so was 640K of RAM, once :-)).

There are probably other similarly academic cases, but those are three that I thought of immediately when I saw the title of the question. They’re very obscure and mostly academic, but I still thought they should be included in the discussion.