What so special about PostgreSQL and other RDBMS?

[Sarah Tanembaum]

Beside its an opensource and supported by community, what's the fundamental
differences between PostgreSQL and those high-price commercial database (and
some are bloated such as Oracle) from software giant such as Microsoft SQL
Server, Oracle, and Sybase?

Is PostgreSQL reliable enough to be used for high-end commercial
application? Thanks

[Erland Sommarskog]

Quirk (qu***@syntac.n et) writes:

[comp.databases. ms-sqlserver group removed]
You really need training! You failed again! (And while you are at it,
drop comp.lang.ruby which we both were requested by mail to do.)
But you *would* risk your Job on developing "high-end commercial"
applications for which you have no source code for dependencies, or
even perpetual access (at any cost) to the dependencies, and a sole
source for your support?
It happens to the be the case that in my position as an SQL Server MVP
I could get access to the source code for SQL Server, or at least I
think so. But I have not taken up on this offer. Why? Because I would
absolutely no use for it. I know about SQL programming, the SQL Server
source code is a lot of C++ code which is far beyond my field of
expertise.

And this applies to the very vast majority of SQL Server users.
Most of the poor closed-source zealots do not even realize what a
small segment of the computer industry licence vending closed-source
software developers actualy are.

I don't know if there are any closed-source zealots out there. I am
certainly not one of them. If I knew that MySQL or PostgresSQL was
the best solution for someone, I would not hesitate from making the
recomendation. Admittedly, it is a bit unlikely, but that is only
because my expert knowledge lies with SQL Server, so I would really
know what I am recommending. (And, no, I would not recommend SQL
Server, just because I know that one well.)
--
Erland Sommarskog, SQL Server MVP, so****@algonet. se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp

[Jeff Rodriguez]

Part of the beauty of SQL is that there are standards which if you try and stick
with, you can relatively easily migrate to another solution such as PostgreSQL
once they reach maturity. PostreSQL really does support a lot, however they're
missing the speed, tools, and high-availability addons of MS SQL Server.

For a company that does thousands of dollars worth of transactions per minute,
such as the one I work for, that $14,000 per processor is a small price to pay
for the reliability we can get from a commercial app. such as MS SQL Server.

Do I like the fact that MS SQL Server is closed source? Of course not, however,
if I had a choice of commercial support providers I would definetly choose
Microsoft; open source or not. I don't know if you've ever had to use their
support, but you can get on the phone with them and within a couple hours have
just about anything worked out. Why? Because they're big, they've seen damn near
everything.

I do not believe that closed source software it infallible, however nither is
open source. Now I'm not going to say that we've never been hacked, because
saying so will make me out to sound like an ignorant ass. Instead I'll say that
we are not aware of ever having any problems with our SQL Server being hacked.

Anyway, down to what matters:

What I am trying to do, is to give some sensibile advice on what a
choice between closed and open source really means, namely that closed
source means an *exclusive* external dependency, when entering such a
dependency you are extreamly vulnerable and should only do so with
both eyes open, after you have determined that this is justified for
you needs. And even then, you should have an exit strategy so that
your investment is not lost when the relationship ends or the external
provider's product loses whatever advantage they had when you made the
deal.

In the case of SQL Servers, sticking as close to standard sql as possible gives
you an exit strategy. Extremely vulnerable? I disagree, if Microsoft were to die
tomorrow by some will of the software gods, someone would just pick up the
pieces and carry on where they left off. MS SQL Server would be sold to someone,
along with the licensees, yadda yadda yadda.
In conclusion I do not agree that using a closed SQL solution makes you
vulnerable, because there will always be support for you as long as the product
is still popular. MS SQL Server is very popular, and by the time one might
consider switching to a new solution, the open source solutions will be large
enough to be considered viable. Hell, if we're lucky maybe Novell will pick up
PostgreSQL...

[Galen Boyer]

On Fri, 14 May 2004, ne********@guru geek.EXAMPLENOS PAM.com wrote:

Part of the beauty of SQL is that there are standards which if
you try and stick with, you can relatively easily migrate to
another solution such as PostgreSQL once they reach
maturity.

I like the seats and dashboards of my BMW, so just yesterday, I
pulled them out and put them in my wifes Ford Escort, but damn,
the car just doesn't seem to perform as well. I really thought
the car industry standard was supposed to take care of these
performance degradations.

--
Galen Boyer

[Daniel Morgan]

Jeff Rodriguez wrote:

_Short Summary_

*PostgreSQL*
Free, loaded with features, not particularly fast, some extras

*MySQL*
Free, not so loaded with features, very fast, some extras

*SQL Server*
/Definetly/ not free, jam packed with features, very fast, lots of extras

*Sybase and Oracle*
Can't say, I have no experience with them.
_Answer to your question_
Suitable for a high-end commercial application? I'm not sure I would
risk my job on it...

Interesting list ... Speed and extras. Not one would be on my list
of most important considerations. How about rating them on:

1. Security
2. Stability
3. Scalability

If it isn't secure who cares how fast it is?
If it isn't stable who cares how many features it has?
If it won't scale to the number of users who gives a rip about extras?

And, to be quite blunt, if the only operating system it will run on
is Windows that becomes a limitation affecting all of the above. Any
time you database server is at risk from every 16 year old on the
planet. It can't really be called secure or stable.

--
Daniel Morgan
http://www.outreach.washington.edu/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@x.wash ington.edu
(replace 'x' with a 'u' to reply)

[Howard J. Rogers]

Daniel Morgan wrote:

Jeff Rodriguez wrote:

_Short Summary_

*PostgreSQL*
Free, loaded with features, not particularly fast, some extras

*MySQL*
Free, not so loaded with features, very fast, some extras

*SQL Server*
/Definetly/ not free, jam packed with features, very fast, lots of extras

*Sybase and Oracle*
Can't say, I have no experience with them.
_Answer to your question_
Suitable for a high-end commercial application? I'm not sure I would
risk my job on it...

Interesting list ... Speed and extras. Not one would be on my list
of most important considerations. How about rating them on:

1. Security
2. Stability
3. Scalability

If it isn't secure who cares how fast it is?
If it isn't stable who cares how many features it has?
If it won't scale to the number of users who gives a rip about extras?

And, to be quite blunt, if the only operating system it will run on
is Windows that becomes a limitation affecting all of the above. Any
time you database server is at risk from every 16 year old on the
planet. It can't really be called secure or stable.

Oh, I dunno. Stick it behind a firewall with some AV software and at
least keep it (OS and AV) minimally up to date, and it will do quite
reasonable service, and the script kiddies can be largely forgotten about.

Would I want to do a database on Windows that was servicing 2000 users?
No, not really, though I think it might just conceivably stretch that
far. But 200? Yes. With rather vital data? Yup. Been there, done that.
Can't mention specific names, but the Australian securities market
springs to mind.

Windows *is* an operating system. It might not be perfect (which one is?
And you're not allowed to mention VMS in your reply to that rhetorical
question!). And it might have its issues (they all do). It might even
have more issues than most others. But it does the job, for many people,
in many circumstances.

As a happy user, at one time or another, of DOS, Windows Kiddie (er, 2.0
to 98), Windows Proper (NT to XP), Linux, Solaris, Tru64, Novell, BeOS
and OS X, all have their quirks and all have their perks. I know which
one I'd implement Oracle on (Linux by choice). And I know which one will
be easiest to manage (Windows by a long shot).

But life would be far more productive if people would stop dissing the
tools that others use perfectly happily, and instead were to concentrate
how to make the best use of *whatever* tools that fall readily to hand.

Regards
HJR

[Daniel Morgan]

Howard J. Rogers wrote:

And, to be quite blunt, if the only operating system it will run on
is Windows that becomes a limitation affecting all of the above. Any
time you database server is at risk from every 16 year old on the
planet. It can't really be called secure or stable.

Oh, I dunno. Stick it behind a firewall with some AV software and at
least keep it (OS and AV) minimally up to date, and it will do quite
reasonable service, and the script kiddies can be largely forgotten about.

Regards
HJR

And would you then ignore all of the security patches?

If you don't ... you still need to at least once a month, likely more
often, down your production database to apply them and reboot the
server.

For what possible benefit? I'm still looking for one thing Windows
can do that, for example, Linux can't do ... except perhaps steal
cycles from the CPU.

--
Daniel Morgan
http://www.outreach.washington.edu/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@x.wash ington.edu
(replace 'x' with a 'u' to reply)

[rkusenet]

"Daniel Morgan" <da******@x.was hington.edu> wrote:-

And would you then ignore all of the security patches?
If you don't ... you still need to at least once a month, likely more
often, down your production database to apply them and reboot the
server.
First you exaggerate that any 16 yrd old can bring down SQLServer
and now you exaggerate the need to apply security patch. Did it occur
to you that if your database server is safely behind the firewall,
the need to apply security patches reduces drastically. Almost all
of the security patches is only when your windows is exposed to
the outside world.

Our customers who run our application on SQL Server *always* use
it behind the firewall and one of them has SQL Server up and running
for more than 6 months. No problem for them.
For what possible benefit? I'm still looking for one thing Windows
can do that, for example, Linux can't do ... except perhaps steal
cycles from the CPU.

This is a different issue. If you want to argue on this, I will
not dispute with you. I also prefer unix over Win, but some of
your criticism against SQLServer (just because it runs on Win only)
is puerile and just shows your insecurity.

Just curious: Have you ever worked with SQLServer.

[Jim Kennedy]

"rkusenet" <rk******@sympa tico.ca> wrote in message
news:2g******** ****@uni-berlin.de...

"Daniel Morgan" <da******@x.was hington.edu> wrote:-

And would you then ignore all of the security patches?
If you don't ... you still need to at least once a month, likely more
often, down your production database to apply them and reboot the
server.

First you exaggerate that any 16 yrd old can bring down SQLServer
and now you exaggerate the need to apply security patch. Did it occur
to you that if your database server is safely behind the firewall,
the need to apply security patches reduces drastically. Almost all
of the security patches is only when your windows is exposed to
the outside world.

Our customers who run our application on SQL Server *always* use
it behind the firewall and one of them has SQL Server up and running
for more than 6 months. No problem for them.

For what possible benefit? I'm still looking for one thing Windows
can do that, for example, Linux can't do ... except perhaps steal
cycles from the CPU.

This is a different issue. If you want to argue on this, I will
not dispute with you. I also prefer unix over Win, but some of
your criticism against SQLServer (just because it runs on Win only)
is puerile and just shows your insecurity.

Just curious: Have you ever worked with SQLServer.

We have a slew of SQL Servers behind a firewall (none are outside it) and we
have to apply the patches monthly. If we do not then we have what happened
a little over a week ago when the latest worm came out. We had to apply an
emergency patch in the middle of the day on our production systems that used
Windows. If we waited the machines would have kept rebooting due to the
worm. (as they already had 5 times that day). So don't give me this hooey
that you don't have to patch the servers monthly; we are at the whims of
some teenager in some foreign land. (and sometimes not so foreign)
Jim

[Daniel Morgan]

rkusenet wrote:

"Daniel Morgan" <da******@x.was hington.edu> wrote:-

And would you then ignore all of the security patches?
If you don't ... you still need to at least once a month, likely more
often, down your production database to apply them and reboot the
server.

First you exaggerate that any 16 yrd old can bring down SQLServer
and now you exaggerate the need to apply security patch. Did it occur
to you that if your database server is safely behind the firewall,
the need to apply security patches reduces drastically. Almost all
of the security patches is only when your windows is exposed to
the outside world.

I didn't exagerate anything ... I asked a question. Please note the
question mark at the end of the sentence.

So you would, in fact, intentionally not apply Microsoft security
patches to your database servers. That is certainly one choice.
Our customers who run our application on SQL Server *always* use
it behind the firewall and one of them has SQL Server up and running
for more than 6 months. No problem for them.

Which is only possible if you never applied a security patch. Once
again ... a choice.

For what possible benefit? I'm still looking for one thing Windows
can do that, for example, Linux can't do ... except perhaps steal
cycles from the CPU.

This is a different issue. If you want to argue on this, I will
not dispute with you. I also prefer unix over Win, but some of
your criticism against SQLServer (just because it runs on Win only)
is puerile and just shows your insecurity.

Just curious: Have you ever worked with SQLServer.

I don't criticize it "just" because it only runs on Windows. That is
just one argument among many. We could, for example, look at the
inability to cluster servers without federating data and many other
things. But that wasn't the point of the post to which I responded
and I'm not interested in starting another meaningless flame war.

--
Daniel Morgan
http://www.outreach.washington.edu/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@x.wash ington.edu
(replace 'x' with a 'u' to reply)

[Steve]

Daniel Morgan wrote:

rkusenet wrote:

"Daniel Morgan" <da******@x.was hington.edu> wrote:-

And would you then ignore all of the security patches?
If you don't ... you still need to at least once a month, likely more
often, down your production database to apply them and reboot the
server.

[snip]

Following on in this current 'just curious' vein, why are any of your
database servers accessible from the internet?

Steve