yes I understand I can do that, and I also understand why the authors chose to do that, I would have done the same.
My point of view is more from a small saas company perspective (i.e 100% pragmatic):
1. I want as less vendor as possible, especially on something as mission critical as my database
2. I already use AWS RDS and it comes with a LOT of nice things (managed, multi-az, easy backup/restore story, etc.)
In that situation:
1. hosting myself is not an option because I will loose all the niceties that I will have to reimplement
2. buying from a 3rd party is not an option either because:
1. What if they go bankrupt ?
2. We are ISO 27001 and they may be not ISO 27001 themselves or forever.
3. If I choose a vendor because it's "postgres + feature A" then if there's an other vendor selling "postgres + feature B" (timescaledb etc.) what do I do ?
That's why I was more interested in knowing if that specific could one day be implemented in postgres directly (as there's already tsvector).
Once again I'm 100% behind them to have chosen a restrictive license if they plan on selling it, but in that case their interested and mine are not aligned, and that's fine.
That's a really fair use case acknlowedging personal preference to interpret how you like it.
I find some of the built in services on clouds are just open source libraries that are packaged up to increase tie in to that platform.
I like cloud, but cloud agnostically, and hybrid/private clouds in the mix with that seem like a good skill to at least be able to consider thinking through.
Comments
yes I understand I can do that, and I also understand why the authors chose to do that, I would have done the same.
My point of view is more from a small saas company perspective (i.e 100% pragmatic):
1. I want as less vendor as possible, especially on something as mission critical as my database 2. I already use AWS RDS and it comes with a LOT of nice things (managed, multi-az, easy backup/restore story, etc.)
In that situation:
1. hosting myself is not an option because I will loose all the niceties that I will have to reimplement 2. buying from a 3rd party is not an option either because: 1. What if they go bankrupt ? 2. We are ISO 27001 and they may be not ISO 27001 themselves or forever. 3. If I choose a vendor because it's "postgres + feature A" then if there's an other vendor selling "postgres + feature B" (timescaledb etc.) what do I do ?
That's why I was more interested in knowing if that specific could one day be implemented in postgres directly (as there's already tsvector).
Once again I'm 100% behind them to have chosen a restrictive license if they plan on selling it, but in that case their interested and mine are not aligned, and that's fine.
That's a really fair use case acknlowedging personal preference to interpret how you like it.
I find some of the built in services on clouds are just open source libraries that are packaged up to increase tie in to that platform.
I like cloud, but cloud agnostically, and hybrid/private clouds in the mix with that seem like a good skill to at least be able to consider thinking through.