Re: On "multi-master" - Mailing list pgsql-general

From Alex Stapleton
Subject Re: On "multi-master"
Date
Msg-id 67AB9195-2088-4756-9BE6-7ADDC5EA2006@advfn.com
Whole thread Raw
In response to Re: On "multi-master"  (Andrew Sullivan <ajs@crankycanuck.ca>)
Responses Re: On "multi-master"
List pgsql-general
On 18 Oct 2005, at 15:59, Andrew Sullivan wrote:

> On Sat, Oct 15, 2005 at 05:58:20PM -0700, Chris Travers wrote:
>

<snip>

>   And in the market we're talking
> about "cheaper" is not the main consideration for "better than".  I
> think other arguments are useful -- access to source (and therefore
> auditability) is an obvious one -- but one needs to establish a
> well-known set of practices around these things if one wishes to be
> taken seriously for this kind of application.

The current market thinks like that, but I suspect that a lot of
small to medium sized companies which don't want to get sucked into
the Oracle consultancy / £16,000 per CPU licensing vacuum are
currently prepared to simply choose a less good solution that just
happens to kinda get the job done. The current market for these
solutions is made up of high paying customers with very expensive
data precisely because nobody has released a cheaper alternative.
There is no serious variation in price in the market, and hence the
client base doesn't change because there isn't any real innovation.

Release a cheaper / free alternative and people will use it because
they will have almost no reason not to. This means that cheaper and
as good as does have a place in the market even if it's not a
conventional solution. It just needs evidence and evangelism. The
current market should not be the principal target.

I do agree that there being a single solution under PostgreSQL to
this problem is the best path though, it is attractive to everyone
for there to by one way to do it, not just the current users of
similar systems.


pgsql-general by date:

Previous
From: "Onyx"
Date:
Subject: Re: A good client
Next
From: "Onyx"
Date:
Subject: Re: About postgreSQL database Synchorization