Re: Justifying a PG over MySQL approach to a project

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>
Cc: "Gauthier, Dave" <dave(dot)gauthier(at)intel(dot)com>, Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Justifying a PG over MySQL approach to a project
Date: 2009-12-21 06:36:49
Message-ID: 4B2F1781.5010202@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Ron Mayer wrote:
> * There are enough large companies that depend entirely
> on each of the databases that make either one a save
> choice from that point of view (Skype). And the way
> Apple and Cisco use it for a number of their programs
>
Yeah, these are all good examples. Cisco uses PostgreSQL in a number of
products:

Carrier-Sensitive Routing:
http://www.cisco.com/en/US/products/sw/voicesw/ps4371/products_user_guide_chapter09186a00800c252c.html

Fabric Manager:
http://www.cisco.com/en/.../product_data_sheet09186a00800c4656.pdf

That have non-trivial uptime requirements. "Call routing" is not a
field particularly tolerant of the "my database got corrupted and went
down" kind of errors.

You'll similarly find PostgreSQL used inside Japan's Nippon Telegraph
and Telephone Corporation (NTT) too, enough so that they're doing major
development to improve it (they're sponsoring the "Streaming
Replication" feature targeted for 8.5). When the telcos and providers
of telco equipment like Skype, Cisco, and NTT are all using PostgreSQL,
it certainly makes it easy to support the idea that the database is
reliable in the real world.

--
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.com

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Greg Smith 2009-12-21 06:41:53 Re: Justifying a PG over MySQL approach to a project
Previous Message Tom Lane 2009-12-21 03:39:00 Re: PL/Perl Performance Problems