3 ms·
>> I am not sure whether not having control over >> upgrades is a feature or a bug. > > I think different people will have different answers > t
by liotier 12y ago
>> I am not sure whether not having control over
>> upgrades is a feature or a bug.
>
> I think different people will have different answers
> to that question [..]
Yes, as long as the features remain reliable. But sometimes, though rarely, an upgrades retires an API or worse, changes a default behavior. I guess that you have thought about that, but that is what I meant with my original question... Sometimes you have to choose between feature stability and newer versions (for new features or, more importantly, bugfixes). How will you handle that balance ? What guarantees does the customer gets either way ? Doesn't making it explicit to the customer comes in conflict with hiding the gritty details of database server operations ?
- pjlegato 12y agoOur guarantee to the customer with regard to the upgrade process is that we will use our best efforts and accumulated knowledge to make the right decisions about how to manage the thorny questions around the upgrade process, to which there are no universally correct solutions, so that they don't have to do so. Of course, it's very easy to say some nice-sounding words like that. The real evidence can only be demonstrated over time, after many successive trials, through building up an ongoing relationship of trust with our customers and repeatedly demonstrating that we make the right calls most of the time. With regards to breaking Postgres changes specifically, they are rare and almost always announced well in advance, giving us ample time to message the users, prepare them, and manage the transition. I see this stage of the database market as analogous to e-mail in the early 2000s. At the time, most people read e-mail delivered by a custom Sendmail, Postfix, or Outlook installation. Many felt that the numerous gritty details of running an e-mail server meant that every site needed its own mail daemon, customized to its particular needs. There were a few email-as-a-service offerings like Hotmail, but many admins felt they were too limited for serious business use cases. It turns out that most businesses actually just needed GMail -- a really well done email-as-a-service platform. Sure, there are still some places that really do need a custom e-mail setup, and they continue to use custom software. For 80% of all businesses, though, a Google Apps GMail account is more than adequate. They trust that GMail's admins will make the right call. We aim to do the same for databases.
- liotier 12y agoI still run my own mail server... But I understand your point - the reasons I still do are mostly not technical.