 <p>There are a few issues with your approach:</p> <ul> <li>It may under-count since you don't use a transaction to atomically update the counter.</li> <li>It is inefficient: <ul> <li>Contention may become a problem if you need to update this counter frequently. Since you only have one counter, it won't scale well. Datastore entities can only be written at a rate of at most 5 times per second.</li> <li>You're writing to the datastore twice every time you insert a record. If you end up using transactions to fix the above problem, then you'll be making two round-trips to the datastore every time you insert the record (once to insert, and once to update the counter). You might be able to use an approach which avoids this extra round-trip to the datastore.</li> </ul></li> </ul> <p>Here are some alternate approaches (from least accurate [and fastest] to most accurate [and slowest]):</p> <ul> <li>If you only need a rough count of the number of entities of particular kind in the datastore, then you can use the <a href="http://code.google.com/appengine/docs/python/datastore/stats.html">Stats API</a>. The counts you retrieve are not constantly updated, however.</li> <li>If you need more granularity but are okay with a small possibility of occasionally under-counting, then you could use a memcache-enhanced counter. There are several good implementations discussed in <a href="http://stackoverflow.com/questions/2769934/high-concurrency-counters-without-sharding">this question</a>. In particular, see the code in the comments in <a href="http://appengine-cookbook.appspot.com/recipe/high-concurrency-counters-without-sharding/">this recipe</a>.</li> <li>If you really want to avoid undercounting, then you should consider a <a href="http://code.google.com/appengine/articles/sharding_counters.html">sharded datastore counter</a>. This will eliminate the contention issue from above.</li> </ul>