Обсуждение: PostgreSQL vs. SQL Server, Oracle

Поиск
Список
Период
Сортировка

PostgreSQL vs. SQL Server, Oracle

От
Kaare Rasmussen
Дата:
Press coverage, an interview with Neil Matthew and Richard Stones.

http://searchopensource.techtarget.com/tip/0,289483,sid39_gci1222466,00.html

--

Med venlig hilsen
Kaare Rasmussen, Jasonic

Jasonic                 Telefon: +45 3816 2582
Nordre Fasanvej 12
2000 Frederiksberg      Email: kaare@jasonic.dk

Re: PostgreSQL vs. SQL Server, Oracle

От
David Fetter
Дата:
On Wed, Oct 11, 2006 at 12:24:15PM +0200, Kaare Rasmussen wrote:
> Press coverage, an interview with Neil Matthew and Richard Stones.
>
> http://searchopensource.techtarget.com/tip/0,289483,sid39_gci1222466,00.html

With friends like these...

"In an emergency, having companies the size of Microsoft or Oracle to
call on may significantly mitigate that risk."

My experiences calling these outfits in an emergency have been a lot
less than uniformly good, even with their top-cost levels of support.
Blaming one of these outfits may save some manager's job, but that's
not the same as actually having the emergency resolved promptly, or
better still, not having it happen at all.

"First, the ability to write functions and stored procedures is
somewhat more limited than you would get with Oracle's PL/SQL or
Sybase's T-SQL."

I don't know which languages they were looking at, but it's hard to
imagine how PL/SQL or T-SQL outdid PL/Perl, PL/PythonU, PL/Ruby,
PL/sh, etc. from a flexibility perspective.

Cheers,
D
--
David Fetter <david@fetter.org> http://fetter.org/
phone: +1 415 235 3778        AIM: dfetter666
                              Skype: davidfetter

Remember to vote!

Re: PostgreSQL vs. SQL Server, Oracle

От
Jeff Davis
Дата:
On Wed, 2006-10-11 at 09:41 -0700, David Fetter wrote:
> "First, the ability to write functions and stored procedures is
> somewhat more limited than you would get with Oracle's PL/SQL or
> Sybase's T-SQL."
>
> I don't know which languages they were looking at, but it's hard to
> imagine how PL/SQL or T-SQL outdid PL/Perl, PL/PythonU, PL/Ruby,
> PL/sh, etc. from a flexibility perspective.
>

Or C, for that matter. Doesn't get much less "limited" than allowing C
functions with a very powerful SPI. It's hard to argue with them when
they don't provide a single example, however.

Regards,
    Jeff Davis


Re: PostgreSQL vs. SQL Server, Oracle

От
"Joshua D. Drake"
Дата:
Jeff Davis wrote:
> On Wed, 2006-10-11 at 09:41 -0700, David Fetter wrote:
>> "First, the ability to write functions and stored procedures is
>> somewhat more limited than you would get with Oracle's PL/SQL or
>> Sybase's T-SQL."
>>
>> I don't know which languages they were looking at, but it's hard to
>> imagine how PL/SQL or T-SQL outdid PL/Perl, PL/PythonU, PL/Ruby,
>> PL/sh, etc. from a flexibility perspective.
>>
>
> Or C, for that matter. Doesn't get much less "limited" than allowing C
> functions with a very powerful SPI. It's hard to argue with them when
> they don't provide a single example, however.

O.k. guys, the article wasn't perfect but it was a heck of a lot more
fair an accurate then what we usually see from the press.

I have already written the editor with a note about the misconception of
our procedural languages.

Joshua D. Drake



>
> Regards,
>     Jeff Davis
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match
>


--

   === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
   Providing the most comprehensive  PostgreSQL solutions since 1997
             http://www.commandprompt.com/



Re: PostgreSQL vs. SQL Server, Oracle

От
David Fetter
Дата:
On Wed, Oct 11, 2006 at 10:43:39AM -0700, Joshua D. Drake wrote:
> Jeff Davis wrote:
> > On Wed, 2006-10-11 at 09:41 -0700, David Fetter wrote:
> >> "First, the ability to write functions and stored procedures is
> >> somewhat more limited than you would get with Oracle's PL/SQL or
> >> Sybase's T-SQL."
> >>
> >> I don't know which languages they were looking at, but it's hard
> >> to imagine how PL/SQL or T-SQL outdid PL/Perl, PL/PythonU,
> >> PL/Ruby, PL/sh, etc. from a flexibility perspective.
> >
> > Or C, for that matter. Doesn't get much less "limited" than
> > allowing C functions with a very powerful SPI. It's hard to argue
> > with them when they don't provide a single example, however.
>
> O.k. guys, the article wasn't perfect but it was a heck of a lot
> more fair an accurate then what we usually see from the press.

I'd think you of all people would be a little peeved at having your
support dismissed this way by their failure to mention that your kind
of support was available.

> I have already written the editor with a note about the
> misconception of our procedural languages.

That's a start :)  You'll notice what I started this off with, which
is "With friends like these..."  These guys wrote a book on
PostgreSQL.  They should know better, but for some reason have decided
to spread a bunch of FUD.

Cheers,
D
--
David Fetter <david@fetter.org> http://fetter.org/
phone: +1 415 235 3778        AIM: dfetter666
                              Skype: davidfetter

Remember to vote!

Re: PostgreSQL vs. SQL Server, Oracle

От
"Jonah H. Harris"
Дата:
On 10/11/06, Joshua D. Drake <jd@commandprompt.com> wrote:
> O.k. guys, the article wasn't perfect but it was a heck of a lot more
> fair an accurate then what we usually see from the press.

True.

> I have already written the editor with a note about the misconception of
> our procedural languages.

True, however, it goes to show the authors level of knowledge when
researching and churning out the book.  You'd think there at least
would've been a mention of extending the procedural language.

Of course, Oracle supports C and Java stored procedures and Microsoft
supports procedures with the Common Language Runtime... so I don't
think it's a fair comparison to say, "PostgreSQL can do it and others
can't" just because they didn't mention PL extensibility.

Just my 2 cents.

--
Jonah H. Harris, Software Architect | phone: 732.331.1300
EnterpriseDB Corporation            | fax: 732.331.1301
33 Wood Ave S, 2nd Floor            | jharris@enterprisedb.com
Iselin, New Jersey 08830            | http://www.enterprisedb.com/

Re: PostgreSQL vs. SQL Server, Oracle

От
"Jonah H. Harris"
Дата:
On 10/11/06, David Fetter <david@fetter.org> wrote:
> I'd think you of all people would be a little peeved at having your
> support dismissed this way by their failure to mention that your kind
> of support was available.

Neither was ours, but that's not the point behind open source and
PostgreSQL... PostgreSQL is free and available for community-based
support... there's nothing wrong with that and I don't consider it a
dismissal at all.

> That's a start :)  You'll notice what I started this off with, which
> is "With friends like these..."  These guys wrote a book on
> PostgreSQL.  They should know better, but for some reason have decided
> to spread a bunch of FUD.

Honestly, these guys are professional authors who churn out book after
book.  They do a little research and write the book; it's in no way
representative of the in-depth knowledge available in the community...
just a good place to start.

I don't think they were spreading FUD, just aiming statements for
small/medium businesses who are paying big bucks for Oracle, SQL
Server, et al.  They aren't PostgreSQL professionals... just authors
trying to promote PostgreSQL a little bit.  Chill out man :)

--
Jonah H. Harris, Software Architect | phone: 732.331.1300
EnterpriseDB Corporation            | fax: 732.331.1301
33 Wood Ave S, 2nd Floor            | jharris@enterprisedb.com
Iselin, New Jersey 08830            | http://www.enterprisedb.com/

Re: PostgreSQL vs. SQL Server, Oracle

От
"Joshua D. Drake"
Дата:
>
> I'd think you of all people would be a little peeved at having your
> support dismissed this way by their failure to mention that your kind
> of support was available.

Honestly, I got over that a *long* time ago. The reality is, people who
want to use postgresql, do the research themselves and then call us (if
they need us). If you recall I don't have any car salesmen, like other
companies. People that do business with us, because of our resume not
because some guy in a tie with a split tongue told them that we are the
best postgresql company out there.

Could we get more business if the press was more accurate? Sure... but
then again if the press was more accurate, they wouldn't be able to sell
any advertising.

>
>> I have already written the editor with a note about the
>> misconception of our procedural languages.
>
> That's a start :)  You'll notice what I started this off with, which
> is "With friends like these..."  These guys wrote a book on
> PostgreSQL.  They should know better, but for some reason have decided
> to spread a bunch of FUD.

I didn't get any FUD from the article is my point. I just got ignorance
but perceptions vary. I can see your frustration from the fact that they
wrote a book on it but writing a book is easy. Writing a good book is hard.

Sincerely,

Joshua D. Drake



--

   === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
   Providing the most comprehensive  PostgreSQL solutions since 1997
             http://www.commandprompt.com/



Re: PostgreSQL vs. SQL Server, Oracle

От
Jeff Davis
Дата:
On Wed, 2006-10-11 at 10:43 -0700, Joshua D. Drake wrote:
> > Or C, for that matter. Doesn't get much less "limited" than allowing C
> > functions with a very powerful SPI. It's hard to argue with them when
> > they don't provide a single example, however.
>
> O.k. guys, the article wasn't perfect but it was a heck of a lot more
> fair an accurate then what we usually see from the press.
>

I would agree with you except that it was the first problem he
mentioned. Table partitioning and vendor tools were second and third,
respectively. That doesn't seem odd to you?

I can't even recall a single complaint about PostgreSQL's functions in
recent history.

However, you're right, I shouldn't complain since the press is probably
good overall.

> I have already written the editor with a note about the misconception of
> our procedural languages.
>

Thanks, a nicely worded note to the editor is always good.

Regards,
    Jeff Davis


Re: PostgreSQL vs. SQL Server, Oracle

От
Ron Mayer
Дата:
David Fetter wrote:
>> http://searchopensource.techtarget.com/tip/0,289483,sid39_gci1222466,00.html
>
> With friends like these...
>
> "In an emergency, having companies the size of Microsoft or Oracle to
> call on may significantly mitigate that risk."

Thanks to Fujitsu you have a bigger company supporting
PostgreSQL than Oracle.

I believe if you want a > $40 Billion revenue company
supporting your database, your only choices are SQL
Server, DB2, and PostgreSQL (Fujitsu's 4.8 billion yen
revenue is about 40 billion/yr makes it the world's third
largest IT services provider).

With such alternatives, you wouldn't want to trust your
business to a database only supported by a small company
like Oracle ($15B/yr), would you?


Re: PostgreSQL vs. SQL Server, Oracle

От
Robert Treat
Дата:
On Wednesday 11 October 2006 12:41, David Fetter wrote:
> On Wed, Oct 11, 2006 at 12:24:15PM +0200, Kaare Rasmussen wrote:
> > Press coverage, an interview with Neil Matthew and Richard Stones.
> >
> > http://searchopensource.techtarget.com/tip/0,289483,sid39_gci1222466,00.h
> >tml
>
> With friends like these...
>
> "In an emergency, having companies the size of Microsoft or Oracle to
> call on may significantly mitigate that risk."
>
> My experiences calling these outfits in an emergency have been a lot
> less than uniformly good, even with their top-cost levels of support.
> Blaming one of these outfits may save some manager's job, but that's
> not the same as actually having the emergency resolved promptly, or
> better still, not having it happen at all.
>
> "First, the ability to write functions and stored procedures is
> somewhat more limited than you would get with Oracle's PL/SQL or
> Sybase's T-SQL."
>
> I don't know which languages they were looking at, but it's hard to
> imagine how PL/SQL or T-SQL outdid PL/Perl, PL/PythonU, PL/Ruby,
> PL/sh, etc. from a flexibility perspective.
>

I'm not sure why people in this community are so quick to label anyone who is
less than glowing about postgresql as "the enemy", but it's really annoying.
Maybe these guys were thinking about things like the ability to return
multiple resultsets and/or the ability to do multiple transactions within a
stored procedure; both of which are functionality that Oracle and SQL Server
devotee's have been enjoying for years... (for the curious, see relevant
threads in the -hackers archives about implementation proposals to add these
features that as of yet have not gotten off the ground)

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

Re: PostgreSQL vs. SQL Server, Oracle

От
Jeff Davis
Дата:
On Wed, 2006-10-11 at 20:18 -0400, Robert Treat wrote:
> I'm not sure why people in this community are so quick to label anyone who is
> less than glowing about postgresql as "the enemy", but it's really annoying.

I didn't take the "with friends like these..." comment literally, but I
see how many people would interpret that to mean he's an enemy, which he
isn't.

> Maybe these guys were thinking about things like the ability to return
> multiple resultsets and/or the ability to do multiple transactions within a
> stored procedure; both of which are functionality that Oracle and SQL Server
> devotee's have been enjoying for years... (for the curious, see relevant
> threads in the -hackers archives about implementation proposals to add these
> features that as of yet have not gotten off the ground)

I don't think it's fair to say "not gotten off the ground". Most of the
use cases that people were concerned about with multiple transactions in
a function/procedure were solved with the addition of savepoints. I
understand that people still want procedures that are executed outside
any other transactions, but I think significant progress was made
responding to many of the needs. I understand your point though.

Regards,
    Jeff Davis


Re: PostgreSQL vs. SQL Server, Oracle

От
David Fetter
Дата:
On Wed, Oct 11, 2006 at 08:18:18PM -0400, Robert Treat wrote:
> On Wednesday 11 October 2006 12:41, David Fetter wrote:
> > On Wed, Oct 11, 2006 at 12:24:15PM +0200, Kaare Rasmussen wrote:
> > > Press coverage, an interview with Neil Matthew and Richard Stones.
> > >
> > > http://searchopensource.techtarget.com/tip/0,289483,sid39_gci1222466,00.h
> > >tml
> >
> > With friends like these...
> >
> > "In an emergency, having companies the size of Microsoft or Oracle
> > to call on may significantly mitigate that risk."
> >
> > My experiences calling these outfits in an emergency have been a
> > lot less than uniformly good, even with their top-cost levels of
> > support.  Blaming one of these outfits may save some manager's
> > job, but that's not the same as actually having the emergency
> > resolved promptly, or better still, not having it happen at all.
> >
> > "First, the ability to write functions and stored procedures is
> > somewhat more limited than you would get with Oracle's PL/SQL or
> > Sybase's T-SQL."
> >
> > I don't know which languages they were looking at, but it's hard
> > to imagine how PL/SQL or T-SQL outdid PL/Perl, PL/PythonU,
> > PL/Ruby, PL/sh, etc. from a flexibility perspective.
>
> I'm not sure why people in this community are so quick to label
> anyone who is less than glowing about postgresql as "the enemy", but
> it's really annoying.

I didn't do that.  I called them friends, if not very clueful ones.

> Maybe these guys were thinking about things like the ability to
> return multiple resultsets and/or the ability to do multiple
> transactions within a stored procedure;

Then they should have mentioned it.  PostgreSQL has real issues, and
if they'd mentioned any one of these, it would have been reasonable.
Instead, these guys chose to spread the FUD around and call PostgreSQL
a toy.

> both of which are functionality that Oracle and SQL Server devotee's
> have been enjoying for years... (for the curious, see relevant
> threads in the -hackers archives about implementation proposals to
> add these features that as of yet have not gotten off the ground)

Part of why they haven't gotten off the ground is that it's been
possible for at least 3 years to return SETOF REFCURSOR from
functions, and there's your multiple result sets :)  As far as
multiple transactions, we have had SAVEPOINTs for quite awhile and
it's possible to do 'autonomous transactions' through untrusted PLs.

I agree that none of what I just mentioned is ideal, but it means that
the capability is there, and so a lot of people who work on internals
are faced with a choice:  Make existing functionality prettier, or do
things that can't currently be done.  If we had a bunch more people on
salary doing this, as I hope we will soon, that choice won't be as
stark.

Cheers,
D
--
David Fetter <david@fetter.org> http://fetter.org/
phone: +1 415 235 3778        AIM: dfetter666
                              Skype: davidfetter

Remember to vote!

Re: PostgreSQL vs. SQL Server, Oracle

От
Robert Treat
Дата:
On Wednesday 11 October 2006 21:36, David Fetter wrote:
> On Wed, Oct 11, 2006 at 08:18:18PM -0400, Robert Treat wrote:
> > On Wednesday 11 October 2006 12:41, David Fetter wrote:
> > > On Wed, Oct 11, 2006 at 12:24:15PM +0200, Kaare Rasmussen wrote:
> > > > Press coverage, an interview with Neil Matthew and Richard Stones.
> > > >
> > > > http://searchopensource.techtarget.com/tip/0,289483,sid39_gci1222466,
> > > >00.h tml
> > >
> > > With friends like these...
> > >
> > > "In an emergency, having companies the size of Microsoft or Oracle
> > > to call on may significantly mitigate that risk."
> > >
> > > My experiences calling these outfits in an emergency have been a
> > > lot less than uniformly good, even with their top-cost levels of
> > > support.  Blaming one of these outfits may save some manager's
> > > job, but that's not the same as actually having the emergency
> > > resolved promptly, or better still, not having it happen at all.
> > >
> > > "First, the ability to write functions and stored procedures is
> > > somewhat more limited than you would get with Oracle's PL/SQL or
> > > Sybase's T-SQL."
> > >
> > > I don't know which languages they were looking at, but it's hard
> > > to imagine how PL/SQL or T-SQL outdid PL/Perl, PL/PythonU,
> > > PL/Ruby, PL/sh, etc. from a flexibility perspective.
> >
> > I'm not sure why people in this community are so quick to label
> > anyone who is less than glowing about postgresql as "the enemy", but
> > it's really annoying.
>
> I didn't do that.  I called them friends, if not very clueful ones.
>

Is that how you treat all your "friends" ?

> > Maybe these guys were thinking about things like the ability to
> > return multiple resultsets and/or the ability to do multiple
> > transactions within a stored procedure;
>
> Then they should have mentioned it.  PostgreSQL has real issues, and
> if they'd mentioned any one of these, it would have been reasonable.
> Instead, these guys chose to spread the FUD around and call PostgreSQL
> a toy.

Now who is spreading FUD? Show me where they said PostgreSQL was a toy?

>
> > both of which are functionality that Oracle and SQL Server devotee's
> > have been enjoying for years... (for the curious, see relevant
> > threads in the -hackers archives about implementation proposals to
> > add these features that as of yet have not gotten off the ground)
>
> Part of why they haven't gotten off the ground is that it's been
> possible for at least 3 years to return SETOF REFCURSOR from
> functions, and there's your multiple result sets :)
> As far as
> multiple transactions, we have had SAVEPOINTs for quite awhile and
> it's possible to do 'autonomous transactions' through untrusted PLs.
>

You're starting to sound more like those database guys who thought FK's were
unneccessary and transactions were overrated every day... I just can't decide
if it's due to zealotry or a lack of experience with other systems.

> I agree that none of what I just mentioned is ideal, but it means that
> the capability is there, and so a lot of people who work on internals
> are faced with a choice:  Make existing functionality prettier, or do
> things that can't currently be done.  If we had a bunch more people on
> salary doing this, as I hope we will soon, that choice won't be as
> stark.
>

I'm not questioning the choices the hackers have made, I'm questioning the
tactic of trashing people who are promoting postgresql just because they
don't bath in the same flavor of kool-aid as you.

You yourself just said "I agree that none of what I just mentioned is ideal",
(which as someone who has actually worked on systems using all of your above
methods I'd say is being generous) but somehow when they say that PostgreSQL
is "somewhat more limited"  your reaction is a backhanded email to the
advocacy group.  I'd prefer people recognize the high points of the article
and then educate themselves on why two postgresql supporters might question
postgresql's use in certain areas so that we know better how to tackle those
problems both in code and from an advocacy point of view.

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

Re: PostgreSQL vs. SQL Server, Oracle

От
Josh Berkus
Дата:
David,

> Then they should have mentioned it.  PostgreSQL has real issues, and
> if they'd mentioned any one of these, it would have been reasonable.
> Instead, these guys chose to spread the FUD around and call PostgreSQL
> a toy.

That's not how I read the article.  They recommended PostgreSQL for "edge"
applications, which is the conventional opinion on Open Source databases.
From my perspective, it's a positive article for us: "Try PostgreSQL, you
might like it."

--
Josh Berkus
PostgreSQL @ Sun
San Francisco

Re: PostgreSQL vs. SQL Server, Oracle

От
"Jim C. Nasby"
Дата:
On Wed, Oct 11, 2006 at 10:55:33PM -0700, Josh Berkus wrote:
> David,
>
> > Then they should have mentioned it.  PostgreSQL has real issues, and
> > if they'd mentioned any one of these, it would have been reasonable.
> > Instead, these guys chose to spread the FUD around and call PostgreSQL
> > a toy.
>
> That's not how I read the article.  They recommended PostgreSQL for "edge"
> applications, which is the conventional opinion on Open Source databases.
> From my perspective, it's a positive article for us: "Try PostgreSQL, you
> might like it."

Not only that, but I think the very last answer really hit the nail on
the head when it comes to MySQL and PostgreSQL: there's no need to take
MySQL's trade-offs for even your light-weight applications.

The reality is, very few companies are willing to bet their a..erm,
donkey ;) on PostgreSQL... yet. Remember that most of the people at a
level that can make that decision have probably barely even heard about
PostgreSQL, so it's no surprise they're not ready to bet the farm on it.
Given time and sucessful deployments in less-critical areas, this will
change. Especially if the big 3 keep their pricing where it is...
--
Jim Nasby                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)

Re: PostgreSQL vs. SQL Server, Oracle

От
David Fetter
Дата:
On Thu, Oct 12, 2006 at 02:50:25PM -0500, Jim C. Nasby wrote:
> On Wed, Oct 11, 2006 at 10:55:33PM -0700, Josh Berkus wrote:
> > David,
> >
> > > Then they should have mentioned it.  PostgreSQL has real issues,
> > > and if they'd mentioned any one of these, it would have been
> > > reasonable.  Instead, these guys chose to spread the FUD around
> > > and call PostgreSQL a toy.
> >
> > That's not how I read the article.  They recommended PostgreSQL
> > for "edge" applications, which is the conventional opinion on Open
> > Source databases.  From my perspective, it's a positive article
> > for us: "Try PostgreSQL, you might like it."
>
> Not only that, but I think the very last answer really hit the nail
> on the head when it comes to MySQL and PostgreSQL: there's no need
> to take MySQL's trade-offs for even your light-weight applications.

True.

> The reality is, very few companies are willing to bet their a..erm,
> donkey ;) on PostgreSQL... yet.

I think this was true two years ago, but just about anybody here can
name a whole bunch of outfits (and probably is not allowed to name
others) that bet the farm on PostgreSQL. :)

> Remember that most of the people at a level that can make that
> decision have probably barely even heard about PostgreSQL, so it's
> no surprise they're not ready to bet the farm on it.  Given time and
> sucessful deployments in less-critical areas, this will change.
> Especially if the big 3 keep their pricing where it is...

They may or may not.  FOSS databases have cut into their markets in a
big way, and we can expect that none of those outfits are going to
take it lying down.  We've already seen "introductory" pricing, FUD
campaigns, etc., and we will doubtless see a lot more as time goes on.

Cheers,
D
--
David Fetter <david@fetter.org> http://fetter.org/
phone: +1 415 235 3778        AIM: dfetter666
                              Skype: davidfetter

Remember to vote!

Re: PostgreSQL vs. SQL Server, Oracle

От
"Joshua D. Drake"
Дата:
>> Not only that, but I think the very last answer really hit the nail
>> on the head when it comes to MySQL and PostgreSQL: there's no need
>> to take MySQL's trade-offs for even your light-weight applications.
>
> True.
>
>> The reality is, very few companies are willing to bet their a..erm,
>> donkey ;) on PostgreSQL... yet.
>
> I think this was true two years ago, but just about anybody here can
> name a whole bunch of outfits (and probably is not allowed to name
> others) that bet the farm on PostgreSQL. :)

Shhhhhhhhhhhhh! You will get me in trouble.

Joshua D. Drake



--

   === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
   Providing the most comprehensive  PostgreSQL solutions since 1997
             http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate


Re: PostgreSQL vs. SQL Server, Oracle

От
"Jim C. Nasby"
Дата:
On Thu, Oct 12, 2006 at 01:25:16PM -0700, David Fetter wrote:
> > The reality is, very few companies are willing to bet their a..erm,
> > donkey ;) on PostgreSQL... yet.
>
> I think this was true two years ago, but just about anybody here can
> name a whole bunch of outfits (and probably is not allowed to name
> others) that bet the farm on PostgreSQL. :)

My point was that how many fortune 500 companies have
mission-critical services that depend on PostgreSQL, especially if
they're public-facing? Sure, some have... many more have not. The few
that have are on the bleeding edge (which isn't so bloody afterall).

In any case, this is rapidly changing. The next few years will certainly
be very interesting. :)
--
Jim Nasby                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)

Re: PostgreSQL vs. SQL Server, Oracle

От
"Jim C. Nasby"
Дата:
On Fri, Oct 13, 2006 at 10:31:14AM -0700, Joshua D. Drake wrote:
> Jim C. Nasby wrote:
> > On Thu, Oct 12, 2006 at 01:25:16PM -0700, David Fetter wrote:
> >>> The reality is, very few companies are willing to bet their a..erm,
> >>> donkey ;) on PostgreSQL... yet.
> >> I think this was true two years ago, but just about anybody here can
> >> name a whole bunch of outfits (and probably is not allowed to name
> >> others) that bet the farm on PostgreSQL. :)
> >
> > My point was that how many fortune 500 companies have
> > mission-critical services that depend on PostgreSQL, especially if
> > they're public-facing? Sure, some have... many more have not. The few
> > that have are on the bleeding edge (which isn't so bloody afterall).
>
> I find that the fortune 500 companies that are technical in nature are
> already running PostgreSQL. Those that are of a different nature likely
> aren't.

"running PostgreSQL" != "running mission-critical public services on
PostgreSQL". :)

AFAIK every large customer we've talked to is "running" MySQL... for
internal apps that aren't mission-critical.
--
Jim Nasby                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)

Re: PostgreSQL vs. SQL Server, Oracle

От
"Joshua D. Drake"
Дата:
> "running PostgreSQL" != "running mission-critical public services on
> PostgreSQL". :)
>
> AFAIK every large customer we've talked to is "running" MySQL... for
> internal apps that aren't mission-critical.

Well any company will to run mysql for mission critical stuff probably
isn't thinking very hard about the implications.

Beyond that, I know of several *technical* based fortune 500 companies
that are doing exactly that... running postgresql on critical
infrastructure. No. I will not name names, don't ask.

Sincerely,

Joshua D. Drake



--

   === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
   Providing the most comprehensive  PostgreSQL solutions since 1997
             http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate


Re: PostgreSQL vs. SQL Server, Oracle

От
"Joshua D. Drake"
Дата:
Jim C. Nasby wrote:
> On Thu, Oct 12, 2006 at 01:25:16PM -0700, David Fetter wrote:
>>> The reality is, very few companies are willing to bet their a..erm,
>>> donkey ;) on PostgreSQL... yet.
>> I think this was true two years ago, but just about anybody here can
>> name a whole bunch of outfits (and probably is not allowed to name
>> others) that bet the farm on PostgreSQL. :)
>
> My point was that how many fortune 500 companies have
> mission-critical services that depend on PostgreSQL, especially if
> they're public-facing? Sure, some have... many more have not. The few
> that have are on the bleeding edge (which isn't so bloody afterall).

I find that the fortune 500 companies that are technical in nature are
already running PostgreSQL. Those that are of a different nature likely
aren't.

Sincerely,

Joshua D. Drake



--

SPI Liason, PostgreSQL Fundraising Group
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
Find out about PostgreSQL Fundraising: http://fundraising.postgresql.org/
Read the PostgreSQL docs: http://www.postgresql.org/docs/