I use my intuitive "rules of thumb"... It is usefull for a rapid decision,
About your DATABASE: if features and/or spatial analysis are of continental-scale, and need precision (serious applications) use geography. Else use geometry: when all database is about same (city-scale) region, or you not need precision, etc. you need only geometry.
See similar rule at the suggest lecture of @underdark.
About your needs in terms of PERFORMANCE/PRECISION BALANCE: geometry is faster; if you need performance and think to use geography, do your benchmarks first.
On this page, we see some key-words and the focus on some concepts: precision, performance, and something like flexibility/commodity of use.
As remembered by others, the difference, for store and calculations, is the use of sphere in geography and plane in geometry:
- the sphere (geography) is better, more precise. See the Los Angeles/Paris example.
- evolution of geography: as @DavidF say, "geography type was more recently added, so fewer functions are supported/implemented".
Perhaps on the year 2020 all GIS databases will be set to the same standard SRID/EPSG (equivalent to the nowadays 4326 code, for WGS84).
Today geography is not a default choice because of performance and functional limitations.
In my opinion it is a question of "best practices", not a deep technical/theoretical problem.
After estimate the error on your data, do your tests and compare results: the precision gains with geography are higher than error of data? The ST_Distance function (with MAX and AVG aggregators) is the main reference in this kind of experiment.
Examples of benchmarks in an urban area of ~100km2 (diameter ~11km), all stored as geometry, in a planar UTM coordinate system. NOTE: starting with the frequently used geometry/geography conversion — frequently because some functions not exist and some others, like ST_Buffer and ST_Intersection, do conversion internally.
Bench#1: a table with ~87000 polygons representing urban lots, each with poly with (avg) ~13 points,
BEGIN; EXPLAIN ANALYSE CREATE TABLE temp_geom AS
SELECT gid, the_geom FROM urbanlots; ROLLBACK;
-- time 2080 ms ~ 2.0 s
BEGIN; EXPLAIN ANALYSE CREATE TABLE temp_geog AS
SELECT gid, Geography(ST_Transform(the_geom,4326)) AS geog
FROM urbanlots; ROLLBACK;
-- time 12374 ms ~ 12.4 s ~ 6 * geometry.
Bench#2: a table with ~3500 polygons representing urban blocks, each with poly with (avg) ~50 points: 0.6s vs 2.7s, geography_time=4.5*geometry_time.
Bench#3: ~10000 lines representing urban streets, each with ~5 points. ~0.87s vs ~0.36s, geography_time=2.4*geometry_time.
Back to Bench#2, creating the tables and doing queries,
EXPLAIN ANALYSE SELECT ST_Area(g.the_geom)+ST_Distance(g.the_geom,t.the_geom)
FROM temp_geom g, (SELECT the_geom FROM temp_geom WHERE gid=1) as t;
-- time 182 ms ~ 0.2 s
EXPLAIN ANALYSE SELECT ST_Area(g.geog)+ST_Distance(g.geog,t.geog)
FROM temp_geog g, (SELECT geog FROM temp_geog WHERE gid=1) as t;
-- time 58657 ms ~ 59 s ~ 300*geometry
-- curioselly for only distances, geography=4*geometry
Conclusion: for little tasks and good hardaware, the times converge to the "acceptable-same time", but for big tasks, there are performance ratings to consider.
On the benchmarks I do a day-by-day task, checking the number of points (by
ST_NPoints)... It is an example of operation that not exists for geography, needs cast. The "geography/geometry cast" is an annoying task for programmers, masters, etc.
When reusing libraries of SQL and PL/pgSQL functions, geography need adaptations. And, if you want to optimize code, or avoid precision problems with a lot of intermediary conversions, the absence of a complete set of build-in functions, with geography, is another problem. Program for geography, is not a easy task.
Process-only, data interchange, etc.
For non-usual demand, with no intensive user like Mapserver, when your only (PostGIS) work is to process input data and return at any time (like hours or days) the processed data, the rule of thumb is "use geography if you are comfortable!" (see "Flexibility/Commodity" above). If not, check usual rules.
NOTE: of course, if your (non-usual) task is only show data from PostGIS to Mapserver, with no process need, to preserve the same (geometry or geography) of your input data, is better decision.
I believe the data centralization is another task where geography is better: in context where the diversity of input formats and reference systems are usual, the use of a standard, such as that enforced by the geography, is beneficial... Convention over configuration is a good principle when centralization and data interchange are the business focus (see Google Maps!).