As many people who know us know we sit on several camps especially when it comes to databases.
The camps we sit on are growing rather than shrinking.
While we do have our favorites, we understand that peoples needs and comfort levels are different from ours and we try to take that into
consideration when making recommendations to people. The only thing that is generally true about the clientele we consult for is that they
fit one of the following features:
- Very minimal bureaucratic structure - this generally rules out most fortune 500 companies
and shall we say smaller companies who are too bureaucratic for their own good
- Dot com startups/Niche product developers who are looking to keep costs down to a minimum without too much fuss and are trying to produce a product to change the world
- Small companies who have a relatively low IT budget, but are predominantly windows-based
- Mid-sized companies predominantly windows-based or departments with decent IT staff,
who are looking for something their staff can easily maintain rather than simply keeping licensing costs down
It has come up as a topic of discussion, now that SQL Server 2008 is coming out soon and with its new fangled geodetic spatial support,
how does this change things?
The short answer is - not much except to increase awareness of spatial databases and to give us more business. As part of our due diligence work
we have put together a comparison of the 3 databases spatial functionality -
Cross Compare SQL Server 2008 Spatial, PostgreSQL/PostGIS 1.3-1.4, MySQL 5-6
to compliment our Cross Compare of SQL Server, MySQL, and PostgreSQL
We expect to be using both PostgreSQL and SQL Server 2008 databases for our
spatial and non-spatial work. In fact we may be using both in the same project in some cases since each has complimentary functionality that the other is lacking
and PostgreSQL has the advantage that its raw SQL functionality is on par with SQL Server and it can scale out/run/or for our product producing clients (install on client servers without additional cost) on more platforms via cloud/hosting without incurring software licensing costs.
We are predominantly SQL Server consultants. It must be noted we are less than we once were,
but if truth be known 80% of our database revenue still comes from SQL Server Support and application development,
and the remaining 20% is split between MySQL and PostgreSQL with MySQL still leading that chunk.
It is true that the predominant reason for us starting to use PostgreSQL was for the superior spatial functionality at zero cost and for that we put
up with a lot of annoying things about PostgreSQL (which for the most part, most of those issues no longer exist in PostgreSQL 8+).
Along the way we discovered things about PostgreSQL that we liked a lot more than we liked in SQL Server and MySQL.
The fact that lots of rich .NET work surrounding the PostgreSQL and Linux community is happening
Francisco's Npgsql group work, better overall support of PostgreSQL on windows,
Mono.NET making it possible to run .NET on Linux, and various efforts of .NET in GIS world
SharpMap.Net, ZigGIS, MapDotNet, Manifold, ArcGIS Server - each with a strong PostGIS support, the integration of SQL Server 2005+ with .NET and Windows platform
is not as strong of a selling point as it once was a year or two ago.
