Maximum number of features in a File Geodatabase Feature Class

[MichalisAvraam]

I have been trying to find out the maximum number of features allowed in a file geodatabase feature class, to no avail. The best I could find was hundreds of millions of vectors (I assume one vector is the equivalent of one simple geometry shape).

Is there a hard limit, or any way to calculate that hard limit? Is my only solution to break down the features into multiple feature classes, and if so, at which point? First 100,000,000 million features? 10,000,000? 1,000,000?

I am running across some programs that simply die with no error message when trying to write a large number of features to a file geodatabase (~1,000,000,000 points along with 2 text fields each of length 8). Yes I understand that this is a large number of features to write, but this is simply a record of calculations that I need to maintain and in no way production data. In all likelihood these data will never be accessed again - they are going straight to an archive.

Thank you,

Michalis

PS: The arcpy.Getmessages() command at the except: code block returns 2 \n as a result (very informative, I know).

[VinceAngelo]

In theory, each table is "limited" to four billion (2^32-1) features (which is roughly 400
times larger than can be effectively managed). 

If they aren't ever going to be accessed again, why not just write them to /dev/null?
Or a series of 20Gb ASCII files?

I know of a client that probably has two billion features in a single table by now,  but
they optimized the load performance in a way that the table could never be effectively
queried, and the real work was done by a table with 72-96 hours of data.

- V

[MichalisAvraam]

The reason they are not sent to /dev/null is that we need to maintain a record so we can recreate results if ever needed.

If the file geodatabase can (in theory) hold 400 billion records, my problem then becomes arcpy silently dying without any response when saving to the geodatabase. Interesting...

[VinceAngelo · Accepted solution]

A file geodatabase can hold closer to an infinite number of records, but any one table can
only hold *four* billion records.  I wouldn't recommend exceeding ten million, especially in
any one session.

If there are no concrete plans to use the data, and large data volumes cause ArcGIS to
crash, then my recommended solution is to not use file geodatabase for this task.  Instead
use a sequence of ASCII files (larger than binary, but more platform-independent) that
combines the date and a rolling sequence number in the filename, capped at one tenth the
expected daily throughput or 1Gb, whichever is smaller.  This would give you a lightweight,
scalable solution that won't cloud the performance (creating locks and such) of the file
geodatabase.

- V

[MichalisAvraam]

Thank you V. I will move into chunking my data then outside a geodatabase.

A file geodatabase can hold closer to an infinite number of records, but any one table can
only hold *four* billion records.  I wouldn't recommend exceeding ten million, especially in
any one session.

If there are no concrete plans to use the data, and large data volumes cause ArcGIS to
crash, then my recommended solution is to not use file geodatabase for this task.  Instead
use a sequence of ASCII files (larger than binary, but more platform-independent) that
combines the date and a rolling sequence number in the filename, capped at one tenth the
expected daily throughput or 1Gb, whichever is smaller.  This would give you a lightweight,
scalable solution that won't cloud the performance (creating locks and such) of the file
geodatabase.

- V