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.