5

I have a SDE 10.0 Geodatabase based on MS SQL 2008.

I'm running a continuous process where about 6400 point features are written to a feature-class every hour. I need it to be a featureclass, since I'm doing some krigging on the feature-class, after applying an attribute query based on a time field in the data.

I was wondering what is the limitation on the number of features a SDE Feature-class can hold?

Improve this question
3

2 Answers 2

Reset to default
9

Two billion features, plus or minus (2^31-2 legal rowid values). I've only loaded 80m personally, but a colleague used my tools to load 680m in Oracle, SQL-Server, and PostgreSQL servers, side by side. That said, the effective useful limit is a lot closer to 20-50 million features.

Tables loaded over time are extremely vulnerable to the effects of spatial fragmentation, which will destroy spatial-first query performance in tables over 2 million rows. If you plan to let the table grow unbounded, you'll need to implement a mitigation plan.

There are an infinite number of permutations of database product, geometry storage, versioning status, and insert behavior which could limit row count -- 2^31-7 versioned edits of an SDEBINARY layer would limit the business table to 5 rows.

For your use case of simple feature insert, the limit is "two gigafeatures". Once you start moving features, then you run into a different limit -- "the total number of features a layer has ever held since the last TRUNCATE" (which is also two gigafeatures). This is probably why "the limit" is not documented.

Improve this answer
5
  • Thanks! Can you give a source citation for the number? We are in the process of periodically moving to different tables, but we are debating whether we should do it monthly, bimonthly, or quarterly.
    – Devdatta Tengshe
    Jan 17, 2014 at 11:59
  • 1
    You need a source for the maximum value of a signed 32-bit integer?
    – Vince
    Jan 17, 2014 at 12:19
  • I need a source that 32 bit integer limit for the ObjectId is the limiting factor, and not something else.
    – Devdatta Tengshe
    Jan 17, 2014 at 12:22
  • 1
    As an clarification to my last comment, imagine this situation. Supposed it is a Versioned fc. Maybe the A & D tables have some effect on the limitation. (I don't know if it's true, just an example of what could be a limiting factor)
    – Devdatta Tengshe
    Jan 17, 2014 at 12:29
  • 3
    There are an infinite number of permutations of database product, geometry storage, versioning status, and insert behavior which could limit row count -- 2^31-7 versioned edits of an SDEBINARY layer would limit the business table to 5 rows. For your use case of simple feature insert, the limit is "two gigafeatures". Once you start moving features, then you run into a different limit -- "the total number of features a layer has ever held since the last TRUNCATE" (which is also two gigafeatures). This is probably why "the limit" is not documented.
    – Vince
    Jan 17, 2014 at 14:56
0

Starting from 10.1 the new 64 bit version will allow you to store and index up to 2^64 records theoratically. That's alot.

Of course you have to enable geodatabase archiving if you are aiming this high.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.