Re:It's the Postgres Age
by FuzzyDunlop on Wednesday May 23, 2012 @03:31PM
(#4014874)
And where will it stop? Will it have a built in email client next?
While it may seem nice and convenient to have all these different features in one nice package, I'm struggling to see what that's such a good idea in the long run.
The thing with the separation of concerns means you use software that does one thing and does it well. Maybe this comes with a greater maintenance cost, I don't know, but I think I'd feel safer with that, because of the maintenance reasons you list.
Many Postgres features and packages can be enabled / disabled via configure, and the engine built, if you want a "leaner" deploy.
All RDBMS engines have a variety of features that are not necessary in all deployments.
I should've noted in the article, almost all of those are optional extensions to Postgres
Yes, I'm aware of that. I'm not sure how much it matters though. You still have to maintain backwards compatibility of both behaviour and api. (in case of external projects it may be less effort, but at the same time more danger that they get broken by accident)
> Schema-less data, array columns, queueing, full-text searching, geo-spatial indexing, it's insane what Postgres can do.
Ok for arrays and geo. Maybe for integrated search. But where is the line between bloat and useful features? Do they really need queueing in the database itself, or schema-less parts? Each part is something that needs maintenance, possible bugfixes and caring about when you update any internal part. Just checking for regressions and keeping them up to date with internal interface changes is going to take some time.
See a similar issue which came up in the mysql -> drizzle move. How can we judge what is slowing the project down and what is going to make it into production somewhere?