Thread: "Too far out of the mainstream"

Hello all,

I would like the community's input on a topic.  The words "too far out of the mainstream" are from an e-mail we
receivedfrom one of our clients, describing the concern our client's IT group has about our use of PostgreSQL in our
shop. The group in question supports multiple different databases, including Oracle, MySQL, SQLServer, DB2, and even
somenon-relational databases (think Cobol and file-based storage), each type with a variety of applications and support
needs. We are in the running for getting a large contract from them and need to address their question:  "What makes
PostgreSQLno more risky than any other database?" 

Thanks in advance for your input.

Andy Yoder

So do they ever go to a site that ends in .org or .info?  Tell them to
stop it right now, as they are relying on PostgreSQL for those sites
to resolve, and PostgreSQL is too far out of the mainstream.  Once
they've stopped using or visiting .org and .info sites tell them to
get back to you.

On Fri, Aug 31, 2012 at 1:25 PM, Andy Yoder <ayoder@airfacts.com> wrote:
> Hello all,
>
> I would like the community's input on a topic.  The words "too far out of the mainstream" are from an e-mail we
receivedfrom one of our clients, describing the concern our client's IT group has about our use of PostgreSQL in our
shop. The group in question supports multiple different databases, including Oracle, MySQL, SQLServer, DB2, and even
somenon-relational databases (think Cobol and file-based storage), each type with a variety of applications and support
needs. We are in the running for getting a large contract from them and need to address their question:  "What makes
PostgreSQLno more risky than any other database?" 
>
> Thanks in advance for your input.
>
> Andy Yoder
>
>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general



--
To understand recursion, one must first understand recursion.

> -----Original Message-----
> From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-
> owner@postgresql.org] On Behalf Of Andy Yoder
> Sent: Friday, August 31, 2012 3:25 PM
> To: pgsql-general@postgresql.org
> Cc: Andy Yoder
> Subject: [GENERAL] "Too far out of the mainstream"
>
> Hello all,
>
> I would like the community's input on a topic.  The words "too far out of
the
> mainstream" are from an e-mail we received from one of our clients,
> describing the concern our client's IT group has about our use of
PostgreSQL
> in our shop.  The group in question supports multiple different databases,
> including Oracle, MySQL, SQLServer, DB2, and even some non-relational
> databases (think Cobol and file-based storage), each type with a variety
of
> applications and support needs.  We are in the running for getting a large
> contract from them and need to address their question:  "What makes
> PostgreSQL no more risky than any other database?"
>
> Thanks in advance for your input.
>
> Andy Yoder

Postgres, like the other database products out there, attempts to adhere to
an independent standard (SQL) as well as provide additional functionality
deemed useful but that falls outside the standard.  Its long existence and
usage in many different businesses and situations, as well as it regular
major-release schedule, shows that it is indeed "mainstream".  Even in a
worse-case scenario, were all new development to stop, prior stable releases
are available and proven in the market and already released under and
open-source license that cannot be revoked - unlike other licenses in the
market.

Aside from all that I would politely ask the client's IT group for specific
and detailed concerns that can be addressed with facts and not via simple
assertions that it works for other people.

If the client's IT group is going to be supporting the database then
"mainstream" has a different meaning than if all database management is
going to done by you and they are worried that PostgreSQL is insecure (which
is not just a function of the database but your entire infrastructure) or is
going to be too slow for the amount of data they are going to be accessing.
Specifics...

David J.

On Fri, Aug 31, 2012 at 02:25:13PM -0500, Andy Yoder wrote:

> I would like the community's input on a topic.  The words "too far
> out of the mainstream" are from an e-mail we received from one of
> our clients, describing the concern our client's IT group has about
> our use of PostgreSQL in our shop.  The group in question supports
> multiple different databases, including Oracle, MySQL, SQLServer,
> DB2, and even some non-relational databases (think Cobol and
> file-based storage), each type with a variety of applications and
> support needs.  We are in the running for getting a large contract
> from them and need to address their question: "What makes PostgreSQL
> no more risky than any other database?"

This canard has been going around for years.  Anyone who thinks that
MySQL, with its sketchy guarantees of data integrity and persistence,
is mainstream-acceptable but Postgres isn't because they haven't read
about it in InfoWorld (or wherever they get their news) is just
believing too much of whatever marketing material their vendors are
shoveling at them.

A response to this sort of question from the .org TLD redelegation is
still available online:
http://archive.icann.org/en/tlds/org/questions-to-applicants-13.htm#Response13TheInternetSocietyISOC.
The details in that answer are all obsolete, of course, since it's
from several years (and Postgres versions) ago, but you can use it as
a cheat sheet in formulating your answer.  For what it's worth, .org
was redelegated from Verisign to Public Interest Registry, and the
resulting system used PostgreSQL (instead of Oracle).

There are more recent community marketing materials around, but I
thought I'd point you to this one because the kind of pressure we were
under at the time was pretty much exactly as you're describing.

Good luck.

--
Andrew Sullivan
ajs@crankycanuck.ca

On Fri, Aug 31, 2012 at 2:05 PM, Andrew Sullivan <ajs@crankycanuck.ca> wrote:
> On Fri, Aug 31, 2012 at 02:25:13PM -0500, Andy Yoder wrote:
>
>> I would like the community's input on a topic.  The words "too far
>> out of the mainstream" are from an e-mail we received from one of
>> our clients, describing the concern our client's IT group has about
>> our use of PostgreSQL in our shop.  The group in question supports
>> multiple different databases, including Oracle, MySQL, SQLServer,
>> DB2, and even some non-relational databases (think Cobol and
>> file-based storage), each type with a variety of applications and
>> support needs.  We are in the running for getting a large contract
>> from them and need to address their question: "What makes PostgreSQL
>> no more risky than any other database?"
>
> This canard has been going around for years.  Anyone who thinks that
> MySQL, with its sketchy guarantees of data integrity and persistence,
> is mainstream-acceptable but Postgres isn't because they haven't read
> about it in InfoWorld (or wherever they get their news) is just
> believing too much of whatever marketing material their vendors are
> shoveling at them.
>
> A response to this sort of question from the .org TLD redelegation is
> still available online:
> http://archive.icann.org/en/tlds/org/questions-to-applicants-13.htm#Response13TheInternetSocietyISOC.
> The details in that answer are all obsolete, of course, since it's
> from several years (and Postgres versions) ago, but you can use it as
> a cheat sheet in formulating your answer.  For what it's worth, .org
> was redelegated from Verisign to Public Interest Registry, and the
> resulting system used PostgreSQL (instead of Oracle).

One of the most fascinating things to come out of the whole Afilias
winning the right to host the .org and .info domains was Oracle's PR
response to the suggestion of using postgresql.  Wish I could find it.
 Andrew might have it archived somewhere.  But the Oracle PR flak
basically outright lied about PostgreSQL, saying it didn't support
transactions.  This bald faced lie might be understandable if
transactions were bolted onto PostgreSQL at some late date after its
inception, but transactions were pretty much built in from the
beginning.  I.e. Oracle will say what they have to to win, and if that
means looking you in the face and lying about the competition, they
won't hesitate to do it.

On Aug 31, 2012, at 12:45 PM, Scott Marlowe <scott.marlowe@gmail.com> wrote:

> So do they ever go to a site that ends in .org or .info?  Tell them to
> stop it right now, as they are relying on PostgreSQL for those sites
> to resolve, and PostgreSQL is too far out of the mainstream.  Once
> they've stopped using or visiting .org and .info sites tell them to
> get back to you.

Mmm. Don't push this line of argument too hard. As I understand it,
Postgresql is used by the registry to keep track of their customers -
whois data, effectively.

The actual resolution is handled by a different database, or was back
when I knew the details of that end of .org.

I'm sure there's an Access database somewhere in Facebook, but that
doesn't mean Facebook runs on Access. :)

Cheers,
  Steve

> A response to this sort of question from the .org TLD redelegation is
> still available online:
> http://archive.icann.org/en/tlds/org/questions-to-applicants-13.htm#Response13TheInternetSocietyISOC.
> The details in that answer are all obsolete, of course, since it's
> from several years (and Postgres versions) ago, but you can use it as
> a cheat sheet in formulating your answer.  For what it's worth, .org
> was redelegated from Verisign to Public Interest Registry, and the
> resulting system used PostgreSQL (instead of Oracle).
>
> There are more recent community marketing materials around, but I
> thought I'd point you to this one because the kind of pressure we were
> under at the time was pretty much exactly as you're describing.

There is this case studies section as well -

http://www.postgresql.org/about/casestudies/

Which appear to me a little old and a little too little, one could try to add more, perhaps.

Also the limitations page is interesting -

http://www.postgresql.org/about/

Also you have what people say about it -

http://www.postgresql.org/about/quotesarchive/

And awards -

http://www.postgresql.org/about/awards/

We have been using PostgreSQL for about 10 years and are currently developing quite big data crunching application
whichshould handle between 25 and 100 million objects which go over object-relational mapping and may easily have 20-30
propertieseach, so we might go into 2-3 billion rows. We have a master database which is replicated via asynchronous
streamingreplication into read-only slaves, where the data crunching takes place. The whole setup runs on cloud
servers,so it is easy to add more slaves when more capacity is needed. 

I should say, indeed, the fame of PostgreSQL is quite smaller than its qualities. But I guess that's the fate of most
professionalthings which simply work, like vim. 

Our approach is that we are a solutions provider, and we use each successful project as a reference and we sign with
ourheads, that it will work. But I guess your situation is slightly different. 

--

On Fri, Aug 31, 2012 at 04:00:06PM -0600, Scott Marlowe wrote:

> One of the most fascinating things to come out of the whole Afilias
> winning the right to host the .org and .info domains was Oracle's PR
> response to the suggestion of using postgresql.  Wish I could find it.

It was only the .org case.

The .org redelegation, more than the start up of .info, was quite
controversial.  Nobody knew how much a new TLD was likely to make, but
at redelegation .org contained about 5 million domains.  At $6.00 per
name per year wholesale (of which Afilias, as a vendor to PIR, took
only a part, I wish to emphasise), there was a non-trivial amount of
money involved in the operation of .org, so the bidding was pretty
heavy.  Also, at the time it wasn't clear to anyone whether ICANN
would ever permit more labels in the root zone (now, of course, we
know that the plan is thousands of new domains.  It's feast or famine
in the domain name industry ;-).

The Oracle stuff is all part of the archived public comments on the
ICANN site.  You can find the whole sorry controversy here:
<http://forum.icann.org/org-eval/gartner-report/>.  Oracle's
mouthpiece, Jenny Gelhausen, did seem to have conflated PostgreSQL and
MySQL in the remarks.  I found particularly amusing the claim in those
remarks that Postgres was used primarily in the embedded market,
because of course Postgres has very frequently been attacked for its
resistance to proposed features that render it more suitable for the
embedded market.

The Gartner report itself was controversial: ISC, who also promised to
use PostgreSQL for its back end, got a lower grade on the back end
than did Afilias.

Anyway, this is all an amusing walk down memory lane.  Thanks for the
reminder!

Best,

A

--
Andrew Sullivan
ajs@crankycanuck.ca

On Fri, Aug 31, 2012 at 4:14 PM, Steve Atkins <steve@blighty.com> wrote:
>
> On Aug 31, 2012, at 12:45 PM, Scott Marlowe <scott.marlowe@gmail.com> wrote:
>
>> So do they ever go to a site that ends in .org or .info?  Tell them to
>> stop it right now, as they are relying on PostgreSQL for those sites
>> to resolve, and PostgreSQL is too far out of the mainstream.  Once
>> they've stopped using or visiting .org and .info sites tell them to
>> get back to you.
>
> Mmm. Don't push this line of argument too hard. As I understand it,
> Postgresql is used by the registry to keep track of their customers -
> whois data, effectively.
>
> The actual resolution is handled by a different database, or was back
> when I knew the details of that end of .org.
>
> I'm sure there's an Access database somewhere in Facebook, but that
> doesn't mean Facebook runs on Access. :)

Unless things have changed, Andrew Sullivan in this message
http://archives.postgresql.org/pgsql-advocacy/2002-09/msg00012.php
says:

"All interactions with the shared registry system, and any whois
queries against whois.afilias.net, are served by a PostgreSQL
database."

So yeah of course direct service of dns lookup is done via bind
servers operating off harvested data, but whois comes right out of a
pg database, and live updates go right into a pg database.

On Fri, Aug 31, 2012 at 4:47 PM, Andrew Sullivan <ajs@crankycanuck.ca> wrote:
> Anyway, this is all an amusing walk down memory lane.  Thanks for the
> reminder!

Hard to believe it was so long ago!

On Aug 31, 2012, at 4:15 PM, Scott Marlowe <scott.marlowe@gmail.com> wrote:
>
> Unless things have changed, Andrew Sullivan in this message
> http://archives.postgresql.org/pgsql-advocacy/2002-09/msg00012.php
> says:
>
> "All interactions with the shared registry system, and any whois
> queries against whois.afilias.net, are served by a PostgreSQL
> database."

That's likely still the case, a decade later.

> So yeah of course direct service of dns lookup is done via bind
> servers operating off harvested data,

dot-org is actually powered by UltraDNS tech (since bought out by
Afilias) rather than bind. And that is directly SQL database backed,
though likely not the database we know and love.

So unless someone from Afilias pops up and tells us they're using
PG there too I'm a little cautious about mentioning PostgreSQL, .org
and DNS together.

> but whois comes right out of a
> pg database, and live updates go right into a pg database.

Yup.

Cheers,
  Steve

On Fri, Aug 31, 2012 at 03:14:30PM -0700, Steve Atkins wrote:
>
> Mmm. Don't push this line of argument too hard. As I understand it,
> Postgresql is used by the registry to keep track of their customers -
> whois data, effectively.

No, the Postgres back end in the Afilias implementation I worked on
(it is as far as I know still there, but I don't work for Afilias any
more and I don't have any special knowledge about their actual
implementation as in production today) is for the domain name
registry.  That means that all the registration data -- which includes
the data necessary to produce DNS responses -- is in that database.
In addition, I worked on and deployed a system that generated directly
all the DNS zone data directly from the PostgreSQL databases.

It _is_ true, of course, that every DNS lookup is not a direct query
of that database system.  But unless Afilias has changed their
implementation very dramatically (and I've no reason to believe they
have), you could not get to any web site ending in .org (or, for that
matter, .info, .in, .aero, .mobi, and a number of others) without the
services of PostgreSQL.

Best,

A

--
Andrew Sullivan
ajs@anvilwalrusden.com

On Fri, Aug 31, 2012 at 04:31:09PM -0700, Steve Atkins wrote:
>
> dot-org is actually powered by UltraDNS tech (since bought out by
> Afilias) rather than bind. And that is directly SQL database backed,
> though likely not the database we know and love.

No, it is not.

Afilias did not buy UltraDNS.  Neustar, who run .biz and .us, bought
Ultra.  Afilias does not use any Ultra servers in its systems, and
hasn't since before I quit working for Afilias.

Best,

A

--
Andrew Sullivan
ajs@crankycanuck.ca

On Sat, Sep 01, 2012 at 12:43:15AM +0200, Geert Mak wrote:
> There is this case studies section as well -
>
> http://www.postgresql.org/about/casestudies/
>
> Which appear to me a little old and a little too little, one could try to add more, perhaps.

I noticed that the "Share Your Story" link is broken.
I don't know how long it's been broken, but this might be a reason
there are no new ones.

What kind of "success story" would be accepted for this page?
We're also running Postgres for most our projects at work, some of them
being rather large databases.  Of course "large" is subjective... some
people might call it kids' stuff.  Also, how "well known" does a company
need to be in order for it to be on the list?

Cheers,
Peter
--
http://sjamaan.ath.cx
--
"The process of preparing programs for a digital computer
 is especially attractive, not only because it can be economically
 and scientifically rewarding, but also because it can be an aesthetic
 experience much like composing poetry or music."
                            -- Donald Knuth

Em 31/08/2012 16:52, David Johnston escreveu:
>> -----Original Message-----
>> From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-
>> owner@postgresql.org] On Behalf Of Andy Yoder
>> Sent: Friday, August 31, 2012 3:25 PM
>> To: pgsql-general@postgresql.org
>> Cc: Andy Yoder
>> Subject: [GENERAL] "Too far out of the mainstream"
>>
>> Hello all,
>>
>> I would like the community's input on a topic.  The words "too far out of
> the
>> mainstream" are from an e-mail we received from one of our clients,
>> describing the concern our client's IT group has about our use of
> PostgreSQL
>> in our shop.  The group in question supports multiple different databases,
>> including Oracle, MySQL, SQLServer, DB2, and even some non-relational
>> databases (think Cobol and file-based storage), each type with a variety
> of
>> applications and support needs.  We are in the running for getting a large
>> contract from them and need to address their question:  "What makes
>> PostgreSQL no more risky than any other database?"
>>
>> Thanks in advance for your input.
>>
>> Andy Yoder
> Postgres, like the other database products out there, attempts to adhere to
> an independent standard (SQL) as well as provide additional functionality
> deemed useful but that falls outside the standard.  Its long existence and
> usage in many different businesses and situations, as well as it regular
> major-release schedule, shows that it is indeed "mainstream".  Even in a
> worse-case scenario, were all new development to stop, prior stable releases
> are available and proven in the market and already released under and
> open-source license that cannot be revoked - unlike other licenses in the
> market.
>
> Aside from all that I would politely ask the client's IT group for specific
> and detailed concerns that can be addressed with facts and not via simple
> assertions that it works for other people.
>
> If the client's IT group is going to be supporting the database then
> "mainstream" has a different meaning than if all database management is
> going to done by you and they are worried that PostgreSQL is insecure (which
> is not just a function of the database but your entire infrastructure) or is
> going to be too slow for the amount of data they are going to be accessing.
> Specifics...
>
> David J.
It's an interesting thing.
We have a product that runs over PostgreSQL without any problems (well,
we have few, but most of them can be worked around).
Nevertheless, when we present our product to customers, they won't get
satisfied until we guarantee we can run same product with major paid
versions (Oracle, MS SQL, and so on).
We assert to them that PostgreSQL works as good as any other (paid)
databases, and even better. After that (knowing that they have a
choice), they won't question any more, and they use PostgreSQL without
any concerns.
Seems that people (managers) that don't understand the technical stuff
need to know that they have a fall back to a paid version (the one that
they can blame if something goes wrong).
Thankfully, our product running over PostgreSQL never stoped in 5 years
of development in any of our customers. Now, I cannot tell the same
about MS SQL Server and MySQL, that had several problems regarding
database structure, and DB2 that suffers of constant DBA maintenance for
performance as the application grows too fast.

Regards,

Edson

On 9/1/2012 6:42 AM, Edson Richter wrote:
> Nevertheless, when we present our product to customers, they won't get
> satisfied until we guarantee we can run same product with major paid
> versions (Oracle, MS SQL, and so on).
I think this is a business problem not a technology problem. Forget
trying to persuade these folks that your solution is a good one.
It is better instead to just say "ok, you can have X (Oracle, whatever)
and the price will be y (quite large number)".
In my experience a customer in this situation will suddenly become much
less entrenched in their belief that your solution is not suitable.
Shift the frame to be about money (easily quantifiable, and something
the customer wants to keep) rather than technical arguments (hard to
quantify, win, pin down, cheap and easy for the customer to argue about).

Wandering away from the original topic a little but helpful enough to continue this line of reasoning here.

On Sat, Sep 1, 2012 at 7:25 AM, Chris Travers <chris.travers@gmail.com> wrote:

> 1)  While MySQL is perhaps better marketed, PostgreSQL is an older project
> with a proud heritage (Informix started as a Postgres fork), and top-rate

Pretty sure that's not true.  Ingres is a cousin of Postgres started
by the same guy, Stonebraker, but it's not a fork either.

Scott Marlowe <scott.marlowe@gmail.com> writes:
> On Sat, Sep 1, 2012 at 7:25 AM, Chris Travers <chris.travers@gmail.com> wrote:
>> 1)  While MySQL is perhaps better marketed, PostgreSQL is an older project
>> with a proud heritage (Informix started as a Postgres fork), and top-rate

> Pretty sure that's not true.  Ingres is a cousin of Postgres started
> by the same guy, Stonebraker, but it's not a fork either.

He didn't say Ingres.

Illustra was a commercial fork of Postgres (the pre-SQL versions, I
think).  It was later bought out by Informix.  I don't have any info
on how much of that code base survives in the modern (IBM-owned)
version of Informix - but one could assume there's at least some.

            regards, tom lane

On Sat, Sep 1, 2012 at 9:01 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Scott Marlowe <scott.marlowe@gmail.com> writes:
>> On Sat, Sep 1, 2012 at 7:25 AM, Chris Travers <chris.travers@gmail.com> wrote:
>>> 1)  While MySQL is perhaps better marketed, PostgreSQL is an older project
>>> with a proud heritage (Informix started as a Postgres fork), and top-rate
>
>> Pretty sure that's not true.  Ingres is a cousin of Postgres started
>> by the same guy, Stonebraker, but it's not a fork either.
>
> He didn't say Ingres.

Yeah I thought he might have been conflating the two.

> Illustra was a commercial fork of Postgres (the pre-SQL versions, I
> think).  It was later bought out by Informix.  I don't have any info
> on how much of that code base survives in the modern (IBM-owned)
> version of Informix - but one could assume there's at least some.

Possibly, but it hardly makes informix a fork of postgres.

2012/9/1 Tom Lane <tgl@sss.pgh.pa.us>:
> Scott Marlowe <scott.marlowe@gmail.com> writes:
>> On Sat, Sep 1, 2012 at 7:25 AM, Chris Travers <chris.travers@gmail.com> wrote:
>>> 1)  While MySQL is perhaps better marketed, PostgreSQL is an older project
>>> with a proud heritage (Informix started as a Postgres fork), and top-rate
>
>> Pretty sure that's not true.  Ingres is a cousin of Postgres started
>> by the same guy, Stonebraker, but it's not a fork either.
>
> He didn't say Ingres.
>
> Illustra was a commercial fork of Postgres (the pre-SQL versions, I
> think).  It was later bought out by Informix.  I don't have any info
> on how much of that code base survives in the modern (IBM-owned)
> version of Informix - but one could assume there's at least some.

true, Illustra was comercial fork of PostgreSQL with SQL and blades
from 1991. Later Informix bought Illustra and Stonebraker was CEO of
Informix.

Pavel



>
>                         regards, tom lane
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general

2012/9/1 Chris Travers <chris.travers@gmail.com>:
>
>
> On Fri, Aug 31, 2012 at 12:25 PM, Andy Yoder <ayoder@airfacts.com> wrote:
>>
>> Hello all,
>>
>> I would like the community's input on a topic.  The words "too far out of
>> the mainstream" are from an e-mail we received from one of our clients,
>> describing the concern our client's IT group has about our use of PostgreSQL
>> in our shop.  The group in question supports multiple different databases,
>> including Oracle, MySQL, SQLServer, DB2, and even some non-relational
>> databases (think Cobol and file-based storage), each type with a variety of
>> applications and support needs.  We are in the running for getting a large
>> contract from them and need to address their question:  "What makes
>> PostgreSQL no more risky than any other database?"
>>
> It is hard to know what sort of risk they are worried about.  Is it
> technical risk of data loss?  Risk of a lack of support if the vendor goes
> out of business?  I think the first thing you need to do is get a good sense
> of what exactly they are worried about.  If you answer the wrong question
> you aren't doing yourself any favors.
>
> The way I see it, this sort of comment is a useful way to open a
> conversation, but probably not the best one to just walk in with an answer
> to.  You probably want to be prepared however by preparing a few different
> approaches:
>
> 1)  While MySQL is perhaps better marketed, PostgreSQL is an older project
> with a proud heritage (Informix started as a Postgres fork), and top-rate
> development.  It has been the standard go-to database for complex business
> applications for a long time.   Also MySQL targets a very different approach
> than PostgreSQL and starts to break down fast when multiple apps share the
> same db because each app can set its own sql_mode settings and the dba has
> to live with the fact that each app gets to decide, for example, whether
> 0000-00-00 is a valid date for error checking purposes.

Tens years PostgreSQL has no sellers, who push PostgreSQL to end
customers. Almost all clients just wait to sellers - I was surprised
how much developers are really passive - and how much developers has
minimal informations about PostgreSQL. We are relative well in pushing
information in open source channels, but it is speaking to relative
smaller group of developers.



>
> 2)  PostgreSQL is an exceptionally robust database, used in a significant
> number of heavy-duty applications (Afilias's use for the .org domain
> registry comes to mind).  It offers a top-notch feature set and the pace of
> development is high.  Additionally the team is exceptionally professional
> about change management.
>
> 3)  PostgreSQL has always been built on the idea of multiple vendors
> offering top-notch support offerings.  Unlike MySQL there has never been an
> ability to just take over the project by buying the vendor.  This also means
> support will continue as long as there is demand for the support, which is a
> very different thing from single vendor software, where support will
> continue as long as the vendor finds it worthwhile to provide it.
>
> Best Wishes,
> Chris travers

On 09/01/2012 01:24 PM, Peter Bex wrote:
> On Sat, Sep 01, 2012 at 12:43:15AM +0200, Geert Mak wrote:
>> There is this case studies section as well -
>>
>> http://www.postgresql.org/about/casestudies/
>>
>> Which appear to me a little old and a little too little, one could try to add more, perhaps.
>
> I noticed that the "Share Your Story" link is broken.
> I don't know how long it's been broken, but this might be a reason
> there are no new ones.

hmm thanks for mentioning that - we will look into fixing that soon.


>
> What kind of "success story" would be accepted for this page?
> We're also running Postgres for most our projects at work, some of them
> being rather large databases.  Of course "large" is subjective... some
> people might call it kids' stuff.  Also, how "well known" does a company
> need to be in order for it to be on the list?

I don't think there are any formal requirements, in fact i think people
would welcome an interesting casestudy any day - so please make one :)


Stefan

"Chris Travers" <chris.travers@gmail.com> wrote in message news:CAKt_ZfvZfYq_VPYXG3p=fy=S1WhCC0P9trXkCZFrrsjsQMSh8w@mail.gmail.com...

On Fri, Aug 31, 2012 at 12:25 PM, Andy Yoder <ayoder@airfacts.com> wrote:

Hello all,

I would like the community's input on a topic.  The words "too far out of the mainstream" are from an e-mail we received from one of our clients, describing the concern our client's IT group has about our use of PostgreSQL in our shop.  The group in question supports multiple different databases, including Oracle, MySQL, SQLServer, DB2, and even some non-relational databases (think Cobol and file-based storage), each type with a variety of applications and support needs.  We are in the running for getting a large contract from them and need to address their question:  "What makes PostgreSQL no more risky than any other database?"

It is hard to know what sort of risk they are worried about.  Is it technical risk of data loss?  Risk of a lack of support if the vendor goes out of business?  I think the first thing you need to do is get a good sense of what exactly they are worried about.  If you answer the wrong question you aren't doing yourself any favors. 

The way I see it, this sort of comment is a useful way to open a conversation, but probably not the best one to just walk in with an answer to.  You probably want to be prepared however by preparing a few different approaches:

1)  While MySQL is perhaps better marketed, PostgreSQL is an older project with a proud heritage (Informix started as a Postgres fork), and top-rate development.  It has been the standard go-to database for complex business applications for a long time.   Also MySQL targets a very different approach than PostgreSQL and starts to break down fast when multiple apps share the same db because each app can set its own sql_mode settings and the dba has to live with the fact that each app gets to decide, for example, whether 0000-00-00 is a valid date for error checking purposes.

2)  PostgreSQL is an exceptionally robust database, used in a significant number of heavy-duty applications (Afilias's use for the .org domain registry comes to mind).  It offers a top-notch feature set and the pace of development is high.  Additionally the team is exceptionally professional about change management.

3)  PostgreSQL has always been built on the idea of multiple vendors offering top-notch support offerings.  Unlike MySQL there has never been an ability to just take over the project by buying the vendor.  This also means support will continue as long as there is demand for the support, which is a very different thing from single vendor software, where support will continue as long as the vendor finds it worthwhile to provide it.

Best Wishes,

Chris travers

I have been looking into heroku lately, they run on PostgreSQL -

https://postgres.heroku.com/postgres

On 04/09/12 10:38, Geert Mak wrote:
> I have been looking into heroku lately, they run on PostgreSQL -
>
> https://postgres.heroku.com/postgres
>
>
"PostgreSQL is the database of choice for reliable web-applications."

Is what they say on that page, not mincing words are they?



Cheers,
Gavin

On 08/31/2012 01:05 PM, Andrew Sullivan wrote:
> ..Anyone who thinks that
> MySQL, with its sketchy guarantees of data integrity and persistence,
> is mainstream-acceptable but Postgres isn't because they haven't read
> about it in InfoWorld....
And if they want to read about it in InfoWorld, they can:

http://www.infoworld.com/d/open-source-software/the-stealth-success-of-postgresql-197584

Cheers,
Steve

On Mon, Sep 3, 2012 at 3:38 PM, Geert Mak <pobox@verysmall.org> wrote:
> I have been looking into heroku lately, they run on PostgreSQL -
>
> https://postgres.heroku.com/postgres

Went out to lunch with a guy who worked for Redfin as well.  I guess
they're all Postgres over there too..

On Tue, Sep 4, 2012 at 11:28 AM, Mike Christensen <mike@kitchenpc.com> wrote:
> On Mon, Sep 3, 2012 at 3:38 PM, Geert Mak <pobox@verysmall.org> wrote:
>> I have been looking into heroku lately, they run on PostgreSQL -
>>
>> https://postgres.heroku.com/postgres
>
> Went out to lunch with a guy who worked for Redfin as well.  I guess
> they're all Postgres over there too..

Since there's no reporting requirements for using postgresql
commercially etc, it's kind of a stealth database.  It's all over the
place and nobody knows it.  Meanwhile, finding qualified PostgreSQL
DBAs is pretty tough because of it's silent yet explosive growth in
usage.

Andy Yoder <ayoder@airfacts.com> wrote:

> I would like the community's input on a topic.  The words "too far
> out of the mainstream" are from an e-mail we received from one of
> our clients, describing the concern our client's IT group has
> about our use of PostgreSQL in our shop.  The group in question
> supports multiple different databases, including Oracle, MySQL,
> SQLServer, DB2, and even some non-relational databases (think
> Cobol and file-based storage), each type with a variety of
> applications and support needs.  We are in the running for getting
> a large contract from them and need to address their question:
> "What makes PostgreSQL no more risky than any other database?"

Hi Andy,

You might be interested in an old post where I compared my
experiences using a commercial database with using PostgreSQL in the
Wisconsin Courts environment:

http://archives.postgresql.org/pgsql-advocacy/2011-11/msg00021.php

With only 3000 directly connected users and a few million web hits a
day backed by PostgreSQL, the Wisconsin court system is far from the
largest user, but I figure that if the larger organizations want to
broadcast their usage, that's up to them.  I also have talked to
others with much larger databases than we have -- our largest one is
3TB.  Again, it's not my place to broadcast details if they don't
choose to do so.  But I think "out of the mainstream" is a very odd
description of PostgreSQL.  It sounds like the sort of thing which a
representative of a commercial product, afraid of losing big money
to PostgreSQL but unable to come up with any *real* reason not to
use it, might throw out there to try to scare people away from it.

I will join the chorus advising you to ask for more particular
concerns.  What is it that they think makes those other database
products no more risky than PostgreSQL?

-Kevin

On Tue, Sep 4, 2012 at 11:28 AM, Mike Christensen <mike@kitchenpc.com> wrote:

On Mon, Sep 3, 2012 at 3:38 PM, Geert Mak <pobox@verysmall.org> wrote:

I have been looking into heroku lately, they run on PostgreSQL -

https://postgres.heroku.com/postgres

Went out to lunch with a guy who worked for Redfin as well.  I guess
they're all Postgres over there too..

Since there's no reporting requirements for using postgresql
commercially etc, it's kind of a stealth database.  It's all over the
place and nobody knows it.  Meanwhile, finding qualified PostgreSQL
DBAs is pretty tough because of it's silent yet explosive growth in
usage.

Possibly there should be mandatory reporting of postgresql, 
just like there is for other contagious diseases?  :-)

How about putting a notice in the release notes to encourage 
people to report their usage? 

Additionally, have bragging tables were people can register 
their biggest postgresql database or table, peak 
transactions per day, … ?  Probably best to solicit 
entries first, them companies can send in results to get 
themselves in the top ten, or something.

I have read to emails to one of the postgresql lists,
where people in companies with 1000's of databases had
power failures and only the postgresql databases
restarted without special recovery actions required.
The other databases mentioned were Oracle, MySql, and 
SQL Server.


Cheers,
Gavin

On Tue, Sep 4, 2012 at 2:03 PM, Gavin Flower
<GavinFlower@archidevsys.co.nz> wrote:
> On 05/09/12 05:35, Scott Marlowe wrote:
> I have read to emails to one of the postgresql lists,
> where people in companies with 1000's of databases had
> power failures and only the postgresql databases
> restarted without special recovery actions required.
> The other databases mentioned were Oracle, MySql, and
> SQL Server.

That was likely me, tho it wasn't thousands, it was somewhere near 100
or so.  It was more a case of the other DBAs not doing their due
diligence and testing their hardware back 10 or so years ago, when
hard drives and RAID controllers often lied about fsync.

On Tue, Sep 4, 2012 at 3:13 PM, Gavin Flower
<GavinFlower@archidevsys.co.nz> wrote:
> On 05/09/12 08:38, Scott Marlowe wrote:
>
> On Tue, Sep 4, 2012 at 2:03 PM, Gavin Flower
> <GavinFlower@archidevsys.co.nz> wrote:
>
> On 05/09/12 05:35, Scott Marlowe wrote:
> I have read to emails to one of the postgresql lists,
> where people in companies with 1000's of databases had
> power failures and only the postgresql databases
> restarted without special recovery actions required.
> The other databases mentioned were Oracle, MySql, and
> SQL Server.
>
> That was likely me, tho it wasn't thousands, it was somewhere near 100
> or so.  It was more a case of the other DBAs not doing their due
> diligence and testing their hardware back 10 or so years ago, when
> hard drives and RAID controllers often lied about fsync.
>
> I fairly certain the 2 emails were from different people, and I read them
> within the last 12 (6?) months.

I may well have written about it in the last 6 to 12 months, that
doesn't mean it happened in the last 6 to 12 months.

Since this PGCon 2011 page has no slides -

http://www.pgcon.org/2011/schedule/events/361.en.html

I Googled for "sharding" and "PostgreSQL" and I found this -

http://www.databasesoup.com/2012/04/sharding-postgres-with-instagram.html

"On Tuesday last week we had a terrific SFPUG meeting at which Mike Kreiger of Instagram explained how they grew and
eventuallysharded their 2TB of Postgres data to support 27 million users." 

Here are the slides -

http://media.postgresql.org/sfpug/instagram_sfpug.pdf

--

Is somebody collecting and organizing such things? I could not find anything about Instagram on www.postgresql.org.

On Tue, Sep 4, 2012 at 2:03 PM, Gavin Flower
<GavinFlower@archidevsys.co.nz> wrote:

On 05/09/12 05:35, Scott Marlowe wrote:
I have read to emails to one of the postgresql lists,
where people in companies with 1000's of databases had
power failures and only the postgresql databases
restarted without special recovery actions required.
The other databases mentioned were Oracle, MySql, and
SQL Server.

That was likely me, tho it wasn't thousands, it was somewhere near 100
or so.  It was more a case of the other DBAs not doing their due
diligence and testing their hardware back 10 or so years ago, when
hard drives and RAID controllers often lied about fsync.

I fairly certain the 2 emails were from different people, and I read them within the last 12 (6?) months.

Hi,

On 5 September 2012 12:14, Chris Travers <chris.travers@gmail.com> wrote:

> So people are using PostgreSQL in roles that aren't very visible anyway,
> DBA's are usually coming to PostgreSQL from other RDBMS's, and few
> applications are really distributed for PostgreSQL.
> <snip>
>  Not only
> this but there was significant interest in moving more db's to PostgreSQL,
> but the big limitation is that everyone who knows PostgreSQL already has a
> job.

Some shops are going opposite way -- from PostgreSQL to MySQL like
databases because of missing replication features. The 9.1 caught up
but there is no multi-master replication like in Percona's XtraDB
cluster: http://www.percona.com/software/percona-xtradb-cluster/

Postgres-XC can solve this missing multi-master replication issue but
"nobody" knows that this project exists. Another project is "Galera
Cluster for PostgreSQL" (Galera is used in XtraDB) but this looks like
vaporware...

--
Ondrej Ivanic
(ondrej.ivanic@gmail.com)

Here's a bit of positive news spin - in a backhanded way perhaps, but still a compliment:

http://www.theregister.co.uk/2012/08/31/postgresql_too_cool_for_school/

Oliver
www.agilebase.co.uk

On Tue, 4 Sep 2012 19:14:28 -0700
Chris Travers <chris.travers@gmail.com> wrote:

> So people are using PostgreSQL in roles that aren't very visible
> anyway, DBA's are usually coming to PostgreSQL from other RDBMS's,
> and few applications are really distributed for PostgreSQL.

I know a bunch of people working for huge sites that love Postgres but
use MySQL. The main reason is they build what Postgres is famous for at
a higher level and in a more specialized way with their own glue.

It's easy to get visibility if you're on the internet and you're huge.

But not everyone can "rebuild" eg. transactions at a higher level and
need as much specialized solutions.

On the other hand for historical reasons MySQL and PHP have nearly
monopolized the hosting space and for many web sites it's hard to
appreciate the difference between Postgres and MySQL (unless your DB
crash and burn).

That's what most people perceive as "the mainstream" if you don't have
a big marketing dept lying.

--
Ivan Sergio Borgonovo
http://www.webthatworks.it

On ������ 05 �������� 2012 10:51:49 Ivan Sergio Borgonovo wrote:
> On Tue, 4 Sep 2012 19:14:28 -0700
> Chris Travers <chris.travers@gmail.com> wrote:
>
> > So people are using PostgreSQL in roles that aren't very visible
> > anyway, DBA's are usually coming to PostgreSQL from other RDBMS's,
> > and few applications are really distributed for PostgreSQL.
>
> I know a bunch of people working for huge sites that love Postgres but
> use MySQL. The main reason is they build what Postgres is famous for at
> a higher level and in a more specialized way with their own glue.
>

Postgresql has more meaning in the enterprise than in a web site.
Web Content is never critical. The world will keep turning even if some
CSS file or some article gets lost. They are meant to be transient any way.
They are not part of anything bigger.

Postgresql shines whenever data matters. I cannot imagine running our app
(single master, 80+ slaves in 80+ vessels in the 7 seas (80+ = 80 and growning)) in mysql.
We have not lost a single transaction. We have not had a single integrity issue.
All problems were due to our own fault and never postgresql's.
Runing a variaty of 7.4 / 8.3 mixture (unfortunately upgrading to 9+ is a very hard task to manage)
(now all are on 8.3) we never had any issues. And the servers run unattended,
in almost military (marine) conditions, with frequent blackouts, hardware failures due to vibration,
disk failures, mother board failures, CPU failures, memory failures.
Postgresql just delivered.

And the thing is that postgresql really has no rivals either. No competitor when it comes
to full-featured OSS RDBMS. There are OSS rdbms (mysql) and full featured rdbms (DB2/Oracle)
but none besides pgsql which combines both worlds.

Also, as far as extensibility is concerned, postgresql is clearly the king.

> It's easy to get visibility if you're on the internet and you're huge.
>
> But not everyone can "rebuild" eg. transactions at a higher level and
> need as much specialized solutions.
>
> On the other hand for historical reasons MySQL and PHP have nearly
> monopolized the hosting space and for many web sites it's hard to
> appreciate the difference between Postgres and MySQL (unless your DB
> crash and burn).
>
> That's what most people perceive as "the mainstream" if you don't have
> a big marketing dept lying.
>
>
-
Achilleas Mantzios
IT DEPT

On Wed, Sep 5, 2012 at 7:40 PM, Achilleas Mantzios
<achill@smadev.internal.net> wrote:
> (single master, 80+ slaves in 80+ vessels in the 7 seas (80+ = 80 and growning))

Cool!! How do your nodes communicate with each other? Is it an
off-line resynchronization, or do you maintain long-range (satellite?)
comms?

The system I'm setting up at work kinda pales in comparison to that.
It's designed to scale "to infinity and beyond" (and that quote is
kinda appropriate, since we run this all on Debian Linux), but at the
moment, all the testing I've done has been on a half-dozen
off-the-shelf Dell laptops. But the same applies; we want absolute
guaranteed reliability, so we NEED a good database. Postgres all the
way! (Plus we need bindings for C++, Pike, and PHP, and I'm a lot
happier with Postgres than several other options in that area.)

ChrisA

On Τετ 05 Σεπτ 2012 23:44:08 Chris Angelico wrote:
> On Wed, Sep 5, 2012 at 7:40 PM, Achilleas Mantzios
> <achill@smadev.internal.net> wrote:
> > (single master, 80+ slaves in 80+ vessels in the 7 seas (80+ = 80 and growning))
>
> Cool!! How do your nodes communicate with each other? Is it an
> off-line resynchronization, or do you maintain long-range (satellite?)
> comms?

Hello,
our topology is star-like. The system is based on good ol' UUCP
running on top of either ISDN lines or (as of late) over TCP/IP.
It is asynchronous and off-line by design. Vessels connect to the central master server
and get all their data, receive replication updates, and also send their data
to the office (central master cerver).
UUCP does the management of the queues (for the unitiated, think of UUCP as
something like JMS or AMQP or even better like JMS (API)+AMQP (wire protocol))
The comms (ISDN and TCPIP) are all done of course over a satellite service
(very expensive, so compression and minimal data replication were/are and will be
major concern)
In the case of ISDN, the billing is by time, so clearly this had to fit in the off-line category.
In the case of TCPIP, the billing is by data size, but we use that under UUCP
just like the ISDN off-line asynchronous mode.

Vessels can operate without connection to the office, and vice versa.

>
> The system I'm setting up at work kinda pales in comparison to that.
> It's designed to scale "to infinity and beyond" (and that quote is
> kinda appropriate, since we run this all on Debian Linux), but at the
> moment, all the testing I've done has been on a half-dozen
> off-the-shelf Dell laptops. But the same applies; we want absolute
> guaranteed reliability, so we NEED a good database. Postgres all the
> way! (Plus we need bindings for C++, Pike, and PHP, and I'm a lot
> happier with Postgres than several other options in that area.)
>
> ChrisA
>
>
>
-
Achilleas Mantzios
IT DEPT

MySQL doesn't even support self referential updates like

update t1 set c1 ='value' where t1.id not in (select id from t1 where id >
100);

Nor is it fully ACID compliant.
And its online documentation is a nightmare.
PgAdmin is infintely better than mysql workbench, heck anything is better
than MySQLWorkbench

Postgres as of 9 will do pretty much anything Oracle or mssql will do minus
robust tools (where mssql is a clear winner with ssrs and ssis and ssms).
Oracles tools are coming around with developer, modeler, and analytics but
really oracle is for when you need serious distributed transaction balancing
via RAC. Honestly if your not using RAC there is no reason to use Oracle.

So There is not one reason to go with MySQL over Postgres and tons of reason
to use Postgres over MySQL, arrays, ORM, Tools, Documentation,
Cross-Language Support, Faster, ACID compliant, etc

And if you want a really rich toolset and you have bought into the .NET
library model, which once you start digging is quite cool, go read petzolds
DotNETZero, then go with mssql.

And if your running a transaction volume to rival Amazon and want a db that
can come as close to a true parrallel load balancing as RAC then fork aout
the shiny and go with Oracle.



--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Too-far-out-of-the-mainstream-tp5722177p5722878.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.

On Sat, Sep 1, 2012 at 1:24 PM, Peter Bex <Peter.Bex@xs4all.nl> wrote:
> On Sat, Sep 01, 2012 at 12:43:15AM +0200, Geert Mak wrote:
>> There is this case studies section as well -
>>
>> http://www.postgresql.org/about/casestudies/
>>
>> Which appear to me a little old and a little too little, one could try to add more, perhaps.
>
> I noticed that the "Share Your Story" link is broken.
> I don't know how long it's been broken, but this might be a reason
> there are no new ones.

Thanks for reporting that - link fixed.


--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

I dunno, perhaps I don't get out the office enough, but I just don't
hear about MySQL any more.
I think this thread is tilting at windmills.

A few years ago about 1 in 2 contracts we had was with a start-up using
MySQL.
The other half were using either PG or Oracle or SQLServer. The years before
that, pre-dot-com-crash, every start-up used Oracle, presumably because
Larry had
some Vulcan mind grip over the VCs.

Then Oracle acquired MySQL any anyone with a brain and some imagination
figured out where that would lead eventually.

So today everyone I meet is either using PostgreSQL or some "web scale"
store
like Raik, MondoDB, Cassandra. MySQL is nowhere to be seen. I'm not
sure if that's because folks migrated from MySQL to something else, or
because the MySQL-using companies were the ones that went out of business.

Regarding MySQL vs PostgreSQL:

Em 05/09/2012 23:49, Chris Travers escreveu:
> Regarding MySQL vs PostgreSQL:
>
> MySQL is what you get when app developers build a database server.
> PostgreSQL is what you get when db developers build a development
> platform.
>
> There really isn't anything more to say about it.

This kind of claim is just to feed flame wars. Don't think I need to
state that a "db developer" becomes a "app developer" as soon as he
start to develop any database server code, right?

Edson.

>
> Best Wishes,
> Chris Travers

On Wed, Sep 5, 2012 at 8:56 PM, Edson Richter <edsonrichter@hotmail.com> wrote:
> Em 05/09/2012 23:49, Chris Travers escreveu:
>
>> Regarding MySQL vs PostgreSQL:
>>
>> MySQL is what you get when app developers build a database server.
>> PostgreSQL is what you get when db developers build a development
>> platform.
>>
>> There really isn't anything more to say about it.
>
>
> This kind of claim is just to feed flame wars. Don't think I need to state
> that a "db developer" becomes a "app developer" as soon as he start to
> develop any database server code, right?

I kind of agree with both of you somewhat.

A lot of developers think of their data in a hierarchical manner. If
so a simple key->value data store is often your best answer.

MySQL's basic design is that of a simple key->value data store
parading as a relational database.  While it's had a lot done to it to
make it better in the role of relational data manager, it's still got
a lot of baggage from back in the day that means that as you go from
simple data store to complex relational data management, you start to
notice warts, like a planner that's dumb as a stump, and very simple
join methods that make complex queries painfully slow.  For people who
are just storing and retrieving lots of simple data, it's still great.

PostgreSQL's heritage was correctness in SQL and set theory.   The
obvious example is queries that MySQL, or at least older versions of
it, would run that Postgresql would, correctly, throw an error on.
Simple example is:

select a,b,c from sometable group by a;

assuming there's no PK on a, this query SHOULD throw an error because
in that case which values you get for b and c are both undefined, and
the SQL standard says that it should therefore throw an error.
Performance and easy use were not a priority for most of its early
life, so the MySQL philosophy of "just run the query and give me the
wrong answer like I asked" wasn't good enough.

They started from very different places, and while they've moved
towards each other over the last decade, their heritages mean they
still have very different strengths and weaknesses.

If you write code by grabbing small globs of data from the db, doing
the mangling in the CPU, then stuffing them back out to the db, MySQL
might be your best choice. If you write code by transforming data sets
in the database, then PostgreSQL is likely your best bet.

The problem you run into is that if you're only familiar with one db
and you're trying to use it like the other one.  MySQL will dominate
at apps that mostly read a lot of tiny bits of data and occasionally
write chunks of code out.  PostgreSQL will dominate at lots of atomic
updates or large data transformations all taking place in the db
layer, not in app code.

Em 06/09/2012 00:39, Scott Marlowe escreveu:
> On Wed, Sep 5, 2012 at 8:56 PM, Edson Richter <edsonrichter@hotmail.com> wrote:
>> Em 05/09/2012 23:49, Chris Travers escreveu:
>>
>>> Regarding MySQL vs PostgreSQL:
>>>
>>> MySQL is what you get when app developers build a database server.
>>> PostgreSQL is what you get when db developers build a development
>>> platform.
>>>
>>> There really isn't anything more to say about it.
>>
>> This kind of claim is just to feed flame wars. Don't think I need to state
>> that a "db developer" becomes a "app developer" as soon as he start to
>> develop any database server code, right?
> I kind of agree with both of you somewhat.
>
> A lot of developers think of their data in a hierarchical manner. If
> so a simple key->value data store is often your best answer.
>
> MySQL's basic design is that of a simple key->value data store
> parading as a relational database.  While it's had a lot done to it to
> make it better in the role of relational data manager, it's still got
> a lot of baggage from back in the day that means that as you go from
> simple data store to complex relational data management, you start to
> notice warts, like a planner that's dumb as a stump, and very simple
> join methods that make complex queries painfully slow.  For people who
> are just storing and retrieving lots of simple data, it's still great.
>
> PostgreSQL's heritage was correctness in SQL and set theory.   The
> obvious example is queries that MySQL, or at least older versions of
> it, would run that Postgresql would, correctly, throw an error on.
> Simple example is:
>
> select a,b,c from sometable group by a;
>
> assuming there's no PK on a, this query SHOULD throw an error because
> in that case which values you get for b and c are both undefined, and
> the SQL standard says that it should therefore throw an error.
> Performance and easy use were not a priority for most of its early
> life, so the MySQL philosophy of "just run the query and give me the
> wrong answer like I asked" wasn't good enough.
>
> They started from very different places, and while they've moved
> towards each other over the last decade, their heritages mean they
> still have very different strengths and weaknesses.
>
> If you write code by grabbing small globs of data from the db, doing
> the mangling in the CPU, then stuffing them back out to the db, MySQL
> might be your best choice. If you write code by transforming data sets
> in the database, then PostgreSQL is likely your best bet.
>
> The problem you run into is that if you're only familiar with one db
> and you're trying to use it like the other one.  MySQL will dominate
> at apps that mostly read a lot of tiny bits of data and occasionally
> write chunks of code out.  PostgreSQL will dominate at lots of atomic
> updates or large data transformations all taking place in the db
> layer, not in app code.

Yes, I heard from a beginner devel that he likes MySQL because it gives
less errors. PostgreSQL was always bugging his app complaining about
some "foreign keys".
I just had to get out for laugh :-)

Nevertheless, I've a large app, and I admit: I tried to run with
MySQL+InnoDB. I'll never do the same mistake twice. My data got corrupt
(foreign keys have been ignored, as well primary keys), and I got lots
of zombie records in database.

Nowadays, I just limit my self to adults databases: PostgreSQL (my
preferred on last 5 years because it just works), MS SQL (because I
worked with it for most of my professional life since 1990s: and yes, I
used it when it was just Sybase's core), Oracle (besides I think it's
like a big expensive White Elephant) and Db2, that surprised me in its
last incarnation.

What I feel missing in PgSQL? Tools that help me to improve performance.
Every time I need to analyze a query, I miss the MS SQL Server
performance analyzer tool, and the Db2 optimizer :-)

But life is like that, and I get used to it. And PostgreSQL have been
working very weel since 8.4 for me (by today, all my databases
(development and production) run 9.1 without any trouble).

Regards,

Edson

On Wed, Sep 5, 2012 at 7:56 PM, Edson Richter <edsonrichter@hotmail.com> wrote:

Em 05/09/2012 23:49, Chris Travers escreveu:

Regarding MySQL vs PostgreSQL:

MySQL is what you get when app developers build a database server.
PostgreSQL is what you get when db developers build a development platform.

There really isn't anything more to say about it.

This kind of claim is just to feed flame wars. Don't think I need to state that a "db developer" becomes a "app developer" as soon as he start to develop any database server code, right?

I don't mean it that way.

Ok, understood. My point here was just to return focus to the main question, and avoid feed the trolls :-)

The basic thing is that MySQL's view of data integrity is extremely application centric.  Even today, applications get to tell the server whether to throw an error when you try to insert 0000-00-00 into a date field (this is via the sql_mode setting and admins can't restrict what an app can do there).  MySQL makes perfect sense when you are an application developer looking at the database as a place to store information for your own private use.     In essence, MySQL makes perfect sense when you realize that "my" = "private" in OO terms.

Yes, I agree. Nothing professional can run this way, but for personal purposes, you can even call "access", "dbf" or "Isis txt format" a database.

This isn't necessarily a bad thing if that's what you are using it for, and because of ways the db market has developed there are a huge number of developers who are very happy with a lowest common denominator RDBMS where you can assume one app writing to the db (or at least any given relation), and possibly other apps reading.  In short if you want an easy db to port SQL code that was intended to be portable to, MySQL is the RDBMS for you.  For people who want to avoid putting business logic in the db, and want to put all the API's for interoperability and integration in their app logic, it's a good RDBMS.  In fact, I can't actually think of better.  This is *especially true* if you want to make it dangerous for other apps to write to the db, perhaps in order to say this is not supported and ask people to purchase more client access licenses....

Actually, for web based applications, developers are forced to add validation at several levels. But is still database responsibility to accept or reject the data that will persist for a lifetime (sometimes less).

MySQL behavior that seems "incorrect" is not necessarily "incorrect" in that context.  It's a data store for one app to write to and optionally other apps to read from.  The app can be trusted to not do crazy things with sql_mode settings or the like, and if it does, whatever the app tells the db is correct behavior, the db is supposed to do.

It is incorrect in a way to by the MySQL behavior, data will get corrupt in a very short of time, I know because I tried with application that run perfectly well in PostgreSQL and get corrupt in a very short of time when using MySQL. The same statement is true for Access and DBF in any multi user scenario.

PostgreSQL on the other hand has been engineered from the beginning (as I understand it) with the idea that you have multiple applications writing to the same relations.  So a lot of the things like sql_mode settings, which are great for porting applications to MySQL, would be dangerous in a PostgreSQL context.  The relations are a public API, while in MySQL they are at least semi-private.  Additionally from the beginning you have had a very strong emphasis on being able to do advanced data modelling in PostgreSQL perhaps to an extent even today unparalleled elsewhere.  If you are going to do db-level programming in PostgreSQL, you shouldn't IMO think like an application developer but rather like a database developer.

What I am getting at is that if you are an app developer looking at databases, MySQL looks fine, and the warts more or less match how you would tend to think a db should act anyway.  If you are a db developer, PostgreSQL tries hard where we all agree on correct db behavior to do the right thing without respect to what the app might have intended.  On the other hand, this is mostly a platform for data modelling, and if you are an app developer a lot of things will seem weird in that context until you get used to it.

Like it or not, the perspectives are very different.  If all you want is an information store for your app with reporting capabilities, then you end up with a different solution then if you want to manage data in a centralized way.

Of course. But remember that writing wrong applications is wrong by design, and its cause are the wrong decisions. The main problem is the people behind and its behavior, not the role they play. Remember that there is not software without bugs, there is software that has been poorly tested. Since we have bugs, we need to have a great community, open for discussions (like this one), and humility to accept that we can always improve. PostgreSQL has all of this, MySQL (and some other opensource and commercial databases) not.


Regards,

Edson.

Best Wishes,

Chris Travers