"Too far out of the mainstream"

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 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

--
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 which should handle between 25 and 100 million objects which go over object-relational mapping and may easily have 20-30 properties each, so we might go into 2-3 billion rows. We have a master database which is replicated via asynchronous streaming replication 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 professional things 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 our heads, 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/&gt;. 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 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 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 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 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

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 5:42 AM, Edson Richter <edsonrichter@hotmail.com>wrote:

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.

I have been thinking about this phenomenon a lot. I don't run into it as
much as others probably because what I think is out there and so people
don't ask, but the question is why this comes up so much. Here is my
theory and it is worth bringing up here because it does have a bearing on
the original question.

The database market has traditionally been dominated by big-cost
alternatives, which tend to require substantial investments in per server
and per user licensing (usually together) and in expertise. For this
reason businesses have reasonably chosen to centralize all systems on one
system, whether it is Oracle, MS SQL, DB2, Informix, etc. This saves costs
and it reduces complexity in the IT environment. It seems like a winning
strategy.

In actuality however the main thing this does it it separates commercial,
off the shelf apps from internal and specialized apps. The former want to
reach a larger market and the only way they can do this is to program in a
way that is portable across databases, meaning that everything gets done in
standard SQL and advanced features are ignored. Internal apps, and those
specializing in markets where they can limit themselves to one db, tend to
use advanced features. However the app developers for commercial apps all
try to control access to the db because that is where their gold is, so
most of these are, the developer hopes, only accessed by the licensed app.
In many cases I know of applications whose EULA's forbid third party apps
from accessing the application's database.

Where MySQL comes in is that after content management they became a
database *just good enough* to handle this one application per db scenario
and all the things that make the db horrible when 30 apps are writing to it
are features for the one app per db with portable SQL model. MySQL's big
weakness here is actually its strength when it comes to its business model.

So the difficulty is that unless IT departments are willing to accept
multiple RDBMS's in their environment, you will end up with applications
coded in a style that's best described as "we'd use NoSQL but we want some
ad hoc reporting."

The thing about PostgreSQL is it is not, and will never be, the lowest
common denominator database any more than Oracle will be. We aren't highly
specialized like Vertica or VoltDB. We are an excellent generalist
database which can be used for really advanced data modelling, and we are
rock solid behavior-wise at least if you stay away from the undefined
fringe.

Best Wishes,
Chris Travers

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.

On Sat, Sep 1, 2012 at 7:45 AM, Scott Marlowe <scott.marlowe@gmail.com>wrote:

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.

As I understand it, Allura was started by Stonebraker as an attempt to
commercialize Postgres. It switched to SQL before Postgres did, and was
bought by Informix, renamed as Informix, and then bought by IBM.

Am I missing something?

Best Wishes,
Chris Travers