Re: Rebranding PostgreSQL - Mailing list pgsql-general

From Steve Atkins
Subject Re: Rebranding PostgreSQL
Date
Msg-id 20051117173311.GC9663@gp.word-to-the-wise.com
Whole thread Raw
In response to Re: Rebranding PostgreSQL  (Vivek Khera <vivek@khera.org>)
Responses Re: Rebranding PostgreSQL
List pgsql-general
On Wed, Nov 16, 2005 at 02:19:28PM -0500, Vivek Khera wrote:
> On Nov 16, 2005, at 1:09 PM, <john.bender@hushmail.com>
> <john.bender@hushmail.com> wrote:
>
> >There are a few obstinate anti-open source customers though, that
> >prevent my plan from moving forward. They've bought into whatever
> >hype they've read and just simply say no. Now, that said, they're
> >fairly non-technical and probably had never heard of PostgreSQL
> >before we presented our plan.
>
> how would postgres be exposed to them anyhow?  wouldn't it just sit
> behind the scenes of your front-end?

Backups. You really need to explain pg_dump to the end user.

> the real trick would have been to sell it in a better way.  don't
> mention open source or antyhing -- just say we have our own in-house
> DB we can provide at reduced cost to supporting your pre-installed
> Oracle.  given them too much information was a mistake, IMHO.

We "embed" postgresql in our product[1]. We don't hide the fact - we
mention it in our pre-sales material and include docs about how to
access the backend DB via psql, JDBC and ODBC and stress that it's a
very standard, widely supported database that's compatible with many
third party tools and reporting utilities. What worries potential
customers most is the need to do maintenance on a database they're not
familiar with so we have app level code to do all the maintenance
needed.

We're selling mostly into large enterprise, and while we've had one or
two requests to support Oracle as well as Postgresql (uhm, no. life is
too short...) we've found that making it very clear that the end users
do not need to become Postgresql DBAs, and that Postgresql is a solid
enterprise grade database has been enough to make potential customers
happy.

Cheers,
  Steve

[1] Almost vanilla build, but we bundle it in the same tarball as the
    application and do all the initdb work needed behind the scenes
    as part of our installation script, include the PG startup and
    shutdown in our rc scripts and have an autovacuum kinda-equivalent
    embedded in the app.

pgsql-general by date:

Previous
From: "Peter Atkins"
Date:
Subject: unsubscribe pgsql-general
Next
From: Eric E
Date:
Subject: Partial foreign keys, check constraints and inheritance