Well, you can always do ad-hoc materialized views ... I'm coding some now.

However, better matview management is currently under development. We had a Google Summer Of Code project to write code to manage the updating of materialized views. In a couple of releases, we might have matviews as good as Oracle's.

Of course, if you're a PostgreSQL user and you want better matview support, then we could really use your help developing it.

--Josh Berkus
      PostgreSQL Project

JD,

You're absolutely correct that such a comparison would be a real asset to users. However, it would also be a Herculean task. Several people have tried to do similar things, but the number of indexes you need to compare (features, reliability, performance, etc.) is too large. And some things are so different it's hard to compare them meaning fully. Imagine trying to do a head-to-head comparison of all OSes in every way.

Here's a few comparison links, but they just scratch the surface:
http://troels.arvin.dk/db/rdbms/
http://en.wikipedia.org/wiki/Comparison_of_SQL_database_management_systems

PostgreSQL *must* be the leading open source SQL database, now. People are bashing us on Slashdot. That's always a sign of success.

Thanks, guys!

--Josh Berkus
    PostgreSQL contributor

Why not just use .NET with PostgreSQL? You can put whatever you want on the back end.

Or you could use Once:Radix or Servoy, both of which integrate with PostgreSQL.

https://sourceforge.net/projects/onceradix/
http://www.servoy.com/

Ed,

Sorry, no.

Speaking as a database contributor (PostgreSQL), databases should absolutely secured at the network level. If not by firewall, by making them only available on localhost, or only by VPN or SSL connection.

DBMSes are designed to be feature-ful, fast, and secure ... **in that order**. Which means that no DBMS is designed to stand up to a protracted, determined, knowledgable attack on an open port (athough some of us do better than others). At the very least, an attacker could DOS you by simply attempting a connection thousands of times a second, forcing the database to fork processes or threads.

Further, the most popular DBMSes (SQL Server, Oracle and MySQL) pretty much always have outstanding security exploits on their bug lists, and far more which were patched in the most recent update most people haven't applied. Even we fix 1-2 exploits per update these days, some of which are quite dangerous with an attacker who really knows their stuff.

Developers are *terrible* about setting good DB passwords. I absolutely can't tell you the number of times I've seen "temp/temp" as an authentication string in a production database, or "trust" authentication for the right IP (which can be spoofed) because a developer wanted a back door which didn't require typing his password.

For that matter, web developers are supposed to set up different permissions for the web user vs. the database owner, but this is a rare thing to see in practice.

So it's *way* important to firewall your database. Better yet, don't have it listen to the internet at all: set up the database to only listen to localhost or the private network.

--Josh Berkus