Geography features are always stored in WGS84 prior to PostGIS 2.2; since then any lon/lat-based spatial reference system can be used. Measurements based on geography features will be in meters instead of CRS units and PostGIS will use geodetic calculations instead of planar geometry.
No all functions support geometry but you can cast between geometry and geography. For the current function list see: https://postgis.net/docs/PostGIS_Special_Functions_Index.html#PostGIS_GeographyFunctions
I don't think it's possible to recommend either geography or geometry for large databases. It depends on what you are doing with your data. As calculations on the sphere are more complicated, I'd expect analyses to be slower on geography features. You also have to transform all your data to WGS84 to use geography.
If you do a lot of measurements and e.g. have to compare sizes of large polygons, it would make sense to use geography rather than geometry.
I found the following useful: http://postgis.net/workshops/postgis-intro/geography.html
The topic is also covered in "PostGIS in Action" (ISBN: 9781935182269).
You cannot do that.
Geometry and Geography are two completely different types of data. You probably did read up on it..., but here is an explanation...
Geometry are points on a flat surface. If you would like to calculate the area of your bedroom, i.e. 3.5m by 6.8m, it would result in 23.8m2 - if you would have drawn it in a CAD program, you would start from 0,0 and draw a rectangle to 3.5 in width, and 6.8 length, which gives you the area of the flat surface, on a Z elevation of 0
When you get to Geography, we are talking about the way the earth or sphere are measured. Yes, the earth is round, but not completely round as a ball. It actually looks like a potato mixed with a watermelon. So, when you draw lines on the earth's surface, they are not flat. For the first couple of meters, its "ok" to measure a flat line, but after that you have to consider using calculations and Coordinate systems (i.e. WGS84, a.k.a. 4326 SRID)
Explanation: http://en.wikipedia.org/wiki/Earth_radius | http://en.wikipedia.org/wiki/Horizon
When you store something in Geometry, they are normally X,Y,Z, and when you store something in Geography they are normally Latitude, Longitude, Elevation. Also to note is, when you store in Geometry it is usually in units of measure, i.e. Meter. When storing in Geography is is usually in which datum the data reside, for example a province or state in America would not the be the same area if measured in Australia. The earth's curve is not the same, and you would sit with errors in your calculations. So, the idea was to use WGS84 as the major measuring unit across the world, but that has led to many errors locally on the ground for some surveyors. Measuring with a theodolite instrument, you would calculate the correct area of a surveyed place to the accuracy of less than 0.002m - which is acceptable. Imagine measuring an area of a place by only having 3 decimal digits after a lat/lon.
shape2SQL has a selection where you can choose between the two. BUT, you cannot compare the two against each other...
Best Answer
There's a good answer over at Stack Overflow, which goes a little something like this:
The rest can be found in Geography data type vs. Geometry data type in SQL Server.
A Geometry vs Geography article at the SQL from the Trenches blog goes into more detail:
Another crucial difference is the ability store your data in standard coordinate systems, such as NAD_1983_StatePlane_California Zone 5, and use all the capabilities of the spatial database, spatial functions, etc. and most importantly the spatial accuracy of a localized coordinate system - whereas sticking with geography as your data type, you can only store your data in WGS84.
So I'd say if you have the option, go with geometry, use EPSG: 102645/102245 (you'll have to check what is the standard 'state plane zone 5' for SoCal) and you'd be all set for any analysis you want to undertake. If you want to share, export your datasets to WGS84 if that is preferred for sharing.