5 ms·

Is there some website or technical article that compares Oracle DB to Postgres and explains the advantages of Postgres? I know the data required for the compar

by sdfin 10y ago

Is there some website or technical article that compares Oracle DB to Postgres and explains the advantages of Postgres? I know the data required for the comparison is out there, but if it's already nicely written somewhere I'd find it handy.

jimnotgym 10y ago
I think this is unlikely to be possible, and acknowledging that I don't have any postgres projects in production, but this may help. 1) except in extreme edge cases it is likely that either would be a technically capable DB for a large project. 2) Cost is a huge factor. Take your Oracle licensing costs for the life of the project. The cost of specialised hardware, and the uncertainty of its future. The cost of hosting is also a part of that. Look at the cost and availability of DBA's in your area. Now apply a discounted cash flow analysis to that, and it is not likely to beat 'free' 3) The Oracle ecosystem is looking uncertain. I can imagine the SPARC hardware you buy now not getting great support, maybe you will have to move platforms? Conversely it seems probably that you could run Postgres/Linux on any x86 VM's you want for the next decade or so!
- sdfin 10y ago
  Thanks. It's very easy to find hundreds of sales pitchs about commercial products, and Oracle even creates notes about the disadvantages of Postgres [1]. Finding equivalent publications about the advantages of open source software requires more work. [1] https://www.postgresql.org/message-id/CANNMO++6tPiwBv2OKcy-HhiYmByhL+XSSUH3NDvOs3G1VVg++g@mail.gmail.com https://www.postgresql.org/message-id/CANNMO++6tPiwBv2OKcy-H...
  - chris_wot 10y ago
    There are also issues that you normally wouldn't have to worry about. The biggest is the risk of being audited by Oracle, and the threat that they will make you either purchase other products, or sue you for a lot more money. https://news.ycombinator.com/item?id=10207495 https://news.ycombinator.com/item?id=10207495 They recently did this with a Java as well: http://www.theregister.co.uk/2016/12/16/oracle_targets_java_users_non_compliance/ http://www.theregister.co.uk/2016/12/16/oracle_targets_java_...
    - davidgerard 10y ago
      We just got this at work too. My boss restrained himself from asking if they were calling from the Postgres Marketing Department. (We almost entirely got off Oracle a year ago; we have one remaining instance for the Business Intelligence guys who are using something Oracle-dependent. We're working out how to charge literally everything related to this to them, or they find some software that talks to PG.)
      - chris_wot 10y ago
        Yup, that's a pretty decent way around things. The trick is to support Oracle with open arms when they bypass IT, but make sure that IT charges back the costs for Oracle to the business units who use it. The business wants an Oracle DBA? He gets employed by that business unit, and they pay him/her out of their budget. The business needs their database tuned? Charge the support costs to their cost centre. They want advanced database tuning? Again, consultants fees go to their cost centre. After a while, there's a good chance that the CEO will be asking why their profits are down. No amount of golf is worth risking the CEO's bonus :-)
        throwingoracle 10y ago
        that is the de minimus approach, IMO: my group billed the last Oracle deployment proposition for a full LOB disaster recovery contingency programme evaluation and priced it in units of median CxO option valuations. Okay, that was the flippant part we kept to ourselves, but we did evaluate another BU's purported need for Oracle RAC in terms of economic impact, with a twist: we cited a board memo regarding the IT dept responsibilities that was phrased in terms of value to the corp in business continuity. We accounted for the impact of lost ROI on NREs and long term investment programmes such as select use of very high end storage kit to enable point in time recovery for virtually anything, for which we have a capacity provisioning budget, and itemised everwhere the Oracle RAC proposition was replicating existig IT budget with as yet evaluated risks. So we billed a advance iter departmental charge for a new evaluation of their proposal, plus potential HR drain on IT, plus a last killer factor: the question whether the Board should approve a diversion from a programme of IT investment secured a mere 4 years ago, which they are happy enough with to refer (indirectly) to in annual reports. We went one further, we sent a formal request to Legal, for impact on our cient SLAs, where our systems could not be guaranteed (without new policies we furnished a budget for initial assessment and a timetable gantt chart) where we involved 3rd party liability: Would Oracle indemnify us if their systems in any way interacted with our SLAs, alternately what is the risk to that BU sales (separate document RFP sent to CFO) in event of a client crisis? Needless to say, we were able to attach real enterprise wide costs _within the Oracle sales process itself _ far beyond their anticipated sale price, and the proposal died on the vine. Detailed line items included inter departmental billing at contract rates for IT sitting in on planing meetings with Oracle, replete with citations from C Suite memos regarding unit costing and "matrix management", and examples of recent inter-dept. invoicing, and, the _coup de grace, a quote from Oracle themselves to provide the IT dept. the consultancy required to advise on the economic impact of a LOB data warehouse analysis installation on a non - Oracle ("greenfield"! ouch!) IT shop, so that we had from Oracle themselves a estimate at the least of their idea what time and manpower we needed to get the "best return" form that investment. All the while, we spoke warmly about the (very real) robustness of Oracle in serious deployments, let out our misgivings of open source culture and development (we sell a commercial software service in a financial niche) and were entirely hospitable to the sales people Oracle sent. Sneakily, we led the introductions they needed, or would have needed, had we not, to use what i think is a very British expression "seen them coming from a distance". The business where I work probably would never have existed without RDB, latterly Oracle, on VMS. I would not lightly denigrate Oracles ability, but i feel it is more like a teacher handing in a report card, bemoaning a brilliant child's talents that are being wasted, to praise Oracle in recent years. Larry Ellison had - to my view - a superb chance when he slagged off cloud biz, quipping they did cloud since Kingdom Come.... .... Yes, now if Oracle had followed that up with letting people have full on geo clustered Oracle RAC plus bells & whistles in bundles at reasonable per user monthly simple contract rates, and explained, "Hey, we can do this, cloud is remote access, but cloud is not Five Nines and real time point in time backup when you run 100K queries a second, here are some usage budgeting plans that nobody else can dream of matching, OH AND it is Solaris/SPARC that enables this offering at this price point...." Well, I am sure you get my drift, I sadly think Larry was correct to dismiss, wrong to try to follow, and Terminally Wrong to not cannibalize their licensing model by making offerings that gave you true HA Oracle at low per user entry prices and linear scaled cost for size, latency, query ad query complexity rate. What I would have done, were I Larry Ellison, would be to split off half of every product dev team to writing integrations with the competition's cloud offering. Then I would open Per User accounted integration rates, to scoop the back end database off of any conceivable service you don't want to go down. Every single product line, say PeopleSoft HR, I would pivot as high as half their developers to making say LinkedIN useful. LinkedIn takes 60 dollars or so per user per month, make Oracle the backend and charge 15 bucks per user per month, to let CxO folk feel happy a seriously robust back end is collating their sales interactions for one example, is how I would start my attrition of that revenue capture. If SalesForce gets 30 bucks a user on LinkedIN integration, I do not care if I get 20, I take that business away. I would target by customers who are deep int Oracle Financials, and build forecasting modules for them, to see LinkedIn data feed their analysis and forecasts. I absolutely believe Oracle could be cannibalistic to many product revenues, whilst pivoting twice in this way: - Pivot One: make Oracle RAC HA at least as cheap as per user SQL Server on Azure. (but with central linear scaled risers that ignore small enterprise and after say 50 users give a rational runtime fee for bigger databases) Pivot Two: take half each product line developers, and task them to build integrations to every competitor in the same field. (this also is a twofold strategy, on one hand, make Oracle NOTCloud licensing support non Oracle uses at a low rate to get the data onto Oracle back end; then both undercut and offer price breaks for scaling DB size by adding further SLAs and support automatically as that scales up. Give No Reason for any cloud app to not have Oracle at the back end, Give a clear product cost ramp that competes with self hosting even without staffing costs DBAs etc) Pivot Three: Take the remaining half of product line developers, and task them with Product,Next. The objective need to be make a small business accessible version of Oracle Financials, on a affordable cloud platform, and for high end, hire aggressively new data scientists to meet needs of big companies, either to develop products that make use of the cloud heterogenously or the data stores and silos and marts and all that stuff in intelligent ways, HA SLAs are throughout this a given, but now you charge per query or bulk deal.
- dastbe 10y ago
  In addition, look to current cloud providers for managed mysql and postgres offerings. aws has managed mysql and postgres, as well as aurora-compatibility for both. gce has managed mysql, and i've noticed over the past few months people reaching out on hn over postgres support. even if you think gce or aws are going to disappear in the next decade (which unlike the oracle on-prem ecosystem, is still in a big growth phase), mysql and postgres aren't. and if you ever get to the point that you need to migrate your data out of their ecosystems, they offer services to help you.
- abraae 10y ago
  The number one reason we stay with Oracle was that once, years ago, we had a come to Jesus moment when the database shat itself and the backups wre not working as they should have been. After a terrifying ride, some combination of Oracle support, a ton of googling and some smart in-house work repaired the damaged data and got things up and running again, literally saving the company. Would postgres have been recoverable in that situation, that one, critical time? (its fruitless to conjecture whether postgres would have been in that situation in the first place). I genuinely don't know. But based on experience I do feel a high level of confidence that Oracle can get me out of the shit when the chips are really down. I'd genuinely love to know if postgres is as reliable as Oracle. Not just in day to day use, but on that once in a blue moon occasion when you really need it to be.
  - trome 10y ago
    Its reliable enough that tons of businesses use it for their core operations, I know mine does. When the chips are down, there is a big, talkative community using it and I know at the very least I'll find an answer, whereas if this were MSSQL I know I would just be hosed (having been in a situation like that before).
  - kogepathic 10y ago
    > we had a come to Jesus moment when the database shat itself and the backups wre not working as they should have been So who was responsible for testing that the backups worked? Sounds like it was equally a process failure (not verifying backups worked) as a technical one. > I'd genuinely love to know if postgres is as reliable as Oracle. Not just in day to day use, but on that once in a blue moon occasion when you really need it to be. If you follow best practices for postgres, have a streaming replica and streaming wal archiving (e.g. to barman) then I firmly believe it's basically bullet proof. If the master shits itself you have the very latest transaction logs available on replica and point in time recovery servers. Postgres also introduced support recently for native multi-master servers. This has been supported for a while by third party extensions like bucardo, but thanks to the work of 2nd quadrent there's now a multi-master implementation provided by postgres itself. If you want a case study of a large business using postgres, look at Zalando (EU online clothing retailer) and their work with it.
rodgerd 10y ago
The two biggest disadvantages of Postgres is that the options for clustering/HA/failover are no-where near as straightforward, and that there's much less tooling and information to acclimatise DBAs to working with it. I offer both those from working in shops which have adopted both at one time or another For advantages I would cite: 1. As with Linux vendors, you have a number of options for support. You can go with a Red Hat style model from EnterpriseDB (annual fee, helpdesks and consultancy, and so on), consultancies such as LisaSoft, through to downloads and following mailing lists. While Oracle have a wide partner network, ultimately you're stuck with what Oracle decide to provide. 2. Postgres doesn't care about your platform. This is huge, huge, huge. Any conversation around Oracle DB will turn into a sales opportunity for Exa* products, OracleVM, and OEL. The Oracle DB pricing and support are hugely worse off (more expensive, less supported) on any non-Oracle product OS or hypervisor. You will either have to drag a bunch of hardware and software that wouldn't already be price/feature competitive into your life, or spend a lot of time fighting and micromanaging your DB footprint, both of which are terrible choices. 3. IME for most things Postgresql is a lot easier to use than Oracle. Per my first comment there are some cases where it isn't, much much of the set up/deploy/upgrade is much more straightforward and amenable to automation tooling (ansible/puppet/chef/etc) than Oracle. 4. Postgresql features are there or not. Folks will make a lot of the partitioning not being quite as easy as Oracle's to set up and run, but those same people are unlikely to mention how much extra $$$ Oracle partitioning costs. Or the management packs. Or the encryption packs. Or... you get the picture. I can't really go into more detail than that, I'm afraid, since Oracle, like IBM with DB2, have fishhooks in their licenses which limit the amount of real-world information users of the product can share. Personally, if I were starting a thing from scratch, I'd be inclined to use Postgres as a baseline and DB2 or SQLServer for anything it can't handle.
- trome 10y ago
  What can SQLServer handle that Postgres can't? I've only ever used the former in retail settings, where its hosed my customers over multiple times (thanks 1 core, 1GB ram & 10GB DB Size cap!) either via licensing, or edge cases where theres no community support, and the upstream software vendor told us to go fly a kite, so I'm very much not interested in SQLServer or any licensed DB, cause its a relationship ending move to say "Your database is gone, start scanning everything in the building again, sorry".
davidgerard 10y ago
The actual advantage: You never have to even think about licensing ever again. So instead of a giant SPOF database server, you can give every app its own clustered pair or triple of PG servers. (PG clustering is sorta painful to get really robust, needs some work here.) And if someone says "but it's unsupported" ... every third-party Oracle support shop is desperate to grab some PG support business. They can tell which way the wind is blowing. There are probably hypothetical use cases where Oracle is a better fit (it really is a very effective and powerful database), but these are fewer and fewer.

by sdfin 10y ago

jimnotgym 10y ago

I think this is unlikely to be possible, and acknowledging that I don't have any postgres projects in production, but this may help. 1) except in extreme edge cases it is likely that either would be a technically capable DB for a large project. 2) Cost is a huge factor. Take your Oracle licensing costs for the life of the project. The cost of specialised hardware, and the uncertainty of its future. The cost of hosting is also a part of that. Look at the cost and availability of DBA's in your area. Now apply a discounted cash flow analysis to that, and it is not likely to beat 'free' 3) The Oracle ecosystem is looking uncertain. I can imagine the SPARC hardware you buy now not getting great support, maybe you will have to move platforms? Conversely it seems probably that you could run Postgres/Linux on any x86 VM's you want for the next decade or so!

sdfin 10y ago
Thanks. It's very easy to find hundreds of sales pitchs about commercial products, and Oracle even creates notes about the disadvantages of Postgres [1]. Finding equivalent publications about the advantages of open source software requires more work. [1] https://www.postgresql.org/message-id/CANNMO++6tPiwBv2OKcy-HhiYmByhL+XSSUH3NDvOs3G1VVg++g@mail.gmail.com https://www.postgresql.org/message-id/CANNMO++6tPiwBv2OKcy-H...
- chris_wot 10y ago
  There are also issues that you normally wouldn't have to worry about. The biggest is the risk of being audited by Oracle, and the threat that they will make you either purchase other products, or sue you for a lot more money. https://news.ycombinator.com/item?id=10207495 https://news.ycombinator.com/item?id=10207495 They recently did this with a Java as well: http://www.theregister.co.uk/2016/12/16/oracle_targets_java_users_non_compliance/ http://www.theregister.co.uk/2016/12/16/oracle_targets_java_...
  - davidgerard 10y ago
    We just got this at work too. My boss restrained himself from asking if they were calling from the Postgres Marketing Department. (We almost entirely got off Oracle a year ago; we have one remaining instance for the Business Intelligence guys who are using something Oracle-dependent. We're working out how to charge literally everything related to this to them, or they find some software that talks to PG.)
    - chris_wot 10y ago
      Yup, that's a pretty decent way around things. The trick is to support Oracle with open arms when they bypass IT, but make sure that IT charges back the costs for Oracle to the business units who use it. The business wants an Oracle DBA? He gets employed by that business unit, and they pay him/her out of their budget. The business needs their database tuned? Charge the support costs to their cost centre. They want advanced database tuning? Again, consultants fees go to their cost centre. After a while, there's a good chance that the CEO will be asking why their profits are down. No amount of golf is worth risking the CEO's bonus :-)
      - throwingoracle 10y ago
        that is the de minimus approach, IMO: my group billed the last Oracle deployment proposition for a full LOB disaster recovery contingency programme evaluation and priced it in units of median CxO option valuations. Okay, that was the flippant part we kept to ourselves, but we did evaluate another BU's purported need for Oracle RAC in terms of economic impact, with a twist: we cited a board memo regarding the IT dept responsibilities that was phrased in terms of value to the corp in business continuity. We accounted for the impact of lost ROI on NREs and long term investment programmes such as select use of very high end storage kit to enable point in time recovery for virtually anything, for which we have a capacity provisioning budget, and itemised everwhere the Oracle RAC proposition was replicating existig IT budget with as yet evaluated risks. So we billed a advance iter departmental charge for a new evaluation of their proposal, plus potential HR drain on IT, plus a last killer factor: the question whether the Board should approve a diversion from a programme of IT investment secured a mere 4 years ago, which they are happy enough with to refer (indirectly) to in annual reports. We went one further, we sent a formal request to Legal, for impact on our cient SLAs, where our systems could not be guaranteed (without new policies we furnished a budget for initial assessment and a timetable gantt chart) where we involved 3rd party liability: Would Oracle indemnify us if their systems in any way interacted with our SLAs, alternately what is the risk to that BU sales (separate document RFP sent to CFO) in event of a client crisis? Needless to say, we were able to attach real enterprise wide costs _within the Oracle sales process itself _ far beyond their anticipated sale price, and the proposal died on the vine. Detailed line items included inter departmental billing at contract rates for IT sitting in on planing meetings with Oracle, replete with citations from C Suite memos regarding unit costing and "matrix management", and examples of recent inter-dept. invoicing, and, the _coup de grace, a quote from Oracle themselves to provide the IT dept. the consultancy required to advise on the economic impact of a LOB data warehouse analysis installation on a non - Oracle ("greenfield"! ouch!) IT shop, so that we had from Oracle themselves a estimate at the least of their idea what time and manpower we needed to get the "best return" form that investment. All the while, we spoke warmly about the (very real) robustness of Oracle in serious deployments, let out our misgivings of open source culture and development (we sell a commercial software service in a financial niche) and were entirely hospitable to the sales people Oracle sent. Sneakily, we led the introductions they needed, or would have needed, had we not, to use what i think is a very British expression "seen them coming from a distance". The business where I work probably would never have existed without RDB, latterly Oracle, on VMS. I would not lightly denigrate Oracles ability, but i feel it is more like a teacher handing in a report card, bemoaning a brilliant child's talents that are being wasted, to praise Oracle in recent years. Larry Ellison had - to my view - a superb chance when he slagged off cloud biz, quipping they did cloud since Kingdom Come.... .... Yes, now if Oracle had followed that up with letting people have full on geo clustered Oracle RAC plus bells & whistles in bundles at reasonable per user monthly simple contract rates, and explained, "Hey, we can do this, cloud is remote access, but cloud is not Five Nines and real time point in time backup when you run 100K queries a second, here are some usage budgeting plans that nobody else can dream of matching, OH AND it is Solaris/SPARC that enables this offering at this price point...." Well, I am sure you get my drift, I sadly think Larry was correct to dismiss, wrong to try to follow, and Terminally Wrong to not cannibalize their licensing model by making offerings that gave you true HA Oracle at low per user entry prices and linear scaled cost for size, latency, query ad query complexity rate. What I would have done, were I Larry Ellison, would be to split off half of every product dev team to writing integrations with the competition's cloud offering. Then I would open Per User accounted integration rates, to scoop the back end database off of any conceivable service you don't want to go down. Every single product line, say PeopleSoft HR, I would pivot as high as half their developers to making say LinkedIN useful. LinkedIn takes 60 dollars or so per user per month, make Oracle the backend and charge 15 bucks per user per month, to let CxO folk feel happy a seriously robust back end is collating their sales interactions for one example, is how I would start my attrition of that revenue capture. If SalesForce gets 30 bucks a user on LinkedIN integration, I do not care if I get 20, I take that business away. I would target by customers who are deep int Oracle Financials, and build forecasting modules for them, to see LinkedIn data feed their analysis and forecasts. I absolutely believe Oracle could be cannibalistic to many product revenues, whilst pivoting twice in this way: - Pivot One: make Oracle RAC HA at least as cheap as per user SQL Server on Azure. (but with central linear scaled risers that ignore small enterprise and after say 50 users give a rational runtime fee for bigger databases) Pivot Two: take half each product line developers, and task them to build integrations to every competitor in the same field. (this also is a twofold strategy, on one hand, make Oracle NOTCloud licensing support non Oracle uses at a low rate to get the data onto Oracle back end; then both undercut and offer price breaks for scaling DB size by adding further SLAs and support automatically as that scales up. Give No Reason for any cloud app to not have Oracle at the back end, Give a clear product cost ramp that competes with self hosting even without staffing costs DBAs etc) Pivot Three: Take the remaining half of product line developers, and task them with Product,Next. The objective need to be make a small business accessible version of Oracle Financials, on a affordable cloud platform, and for high end, hire aggressively new data scientists to meet needs of big companies, either to develop products that make use of the cloud heterogenously or the data stores and silos and marts and all that stuff in intelligent ways, HA SLAs are throughout this a given, but now you charge per query or bulk deal.
dastbe 10y ago
In addition, look to current cloud providers for managed mysql and postgres offerings. aws has managed mysql and postgres, as well as aurora-compatibility for both. gce has managed mysql, and i've noticed over the past few months people reaching out on hn over postgres support. even if you think gce or aws are going to disappear in the next decade (which unlike the oracle on-prem ecosystem, is still in a big growth phase), mysql and postgres aren't. and if you ever get to the point that you need to migrate your data out of their ecosystems, they offer services to help you.
abraae 10y ago
The number one reason we stay with Oracle was that once, years ago, we had a come to Jesus moment when the database shat itself and the backups wre not working as they should have been. After a terrifying ride, some combination of Oracle support, a ton of googling and some smart in-house work repaired the damaged data and got things up and running again, literally saving the company. Would postgres have been recoverable in that situation, that one, critical time? (its fruitless to conjecture whether postgres would have been in that situation in the first place). I genuinely don't know. But based on experience I do feel a high level of confidence that Oracle can get me out of the shit when the chips are really down. I'd genuinely love to know if postgres is as reliable as Oracle. Not just in day to day use, but on that once in a blue moon occasion when you really need it to be.
- trome 10y ago
  Its reliable enough that tons of businesses use it for their core operations, I know mine does. When the chips are down, there is a big, talkative community using it and I know at the very least I'll find an answer, whereas if this were MSSQL I know I would just be hosed (having been in a situation like that before).
- kogepathic 10y ago
  > we had a come to Jesus moment when the database shat itself and the backups wre not working as they should have been So who was responsible for testing that the backups worked? Sounds like it was equally a process failure (not verifying backups worked) as a technical one. > I'd genuinely love to know if postgres is as reliable as Oracle. Not just in day to day use, but on that once in a blue moon occasion when you really need it to be. If you follow best practices for postgres, have a streaming replica and streaming wal archiving (e.g. to barman) then I firmly believe it's basically bullet proof. If the master shits itself you have the very latest transaction logs available on replica and point in time recovery servers. Postgres also introduced support recently for native multi-master servers. This has been supported for a while by third party extensions like bucardo, but thanks to the work of 2nd quadrent there's now a multi-master implementation provided by postgres itself. If you want a case study of a large business using postgres, look at Zalando (EU online clothing retailer) and their work with it.

rodgerd 10y ago

The two biggest disadvantages of Postgres is that the options for clustering/HA/failover are no-where near as straightforward, and that there's much less tooling and information to acclimatise DBAs to working with it. I offer both those from working in shops which have adopted both at one time or another For advantages I would cite: 1. As with Linux vendors, you have a number of options for support. You can go with a Red Hat style model from EnterpriseDB (annual fee, helpdesks and consultancy, and so on), consultancies such as LisaSoft, through to downloads and following mailing lists. While Oracle have a wide partner network, ultimately you're stuck with what Oracle decide to provide. 2. Postgres doesn't care about your platform. This is huge, huge, huge. Any conversation around Oracle DB will turn into a sales opportunity for Exa* products, OracleVM, and OEL. The Oracle DB pricing and support are hugely worse off (more expensive, less supported) on any non-Oracle product OS or hypervisor. You will either have to drag a bunch of hardware and software that wouldn't already be price/feature competitive into your life, or spend a lot of time fighting and micromanaging your DB footprint, both of which are terrible choices. 3. IME for most things Postgresql is a lot easier to use than Oracle. Per my first comment there are some cases where it isn't, much much of the set up/deploy/upgrade is much more straightforward and amenable to automation tooling (ansible/puppet/chef/etc) than Oracle. 4. Postgresql features are there or not. Folks will make a lot of the partitioning not being quite as easy as Oracle's to set up and run, but those same people are unlikely to mention how much extra $$$ Oracle partitioning costs. Or the management packs. Or the encryption packs. Or... you get the picture. I can't really go into more detail than that, I'm afraid, since Oracle, like IBM with DB2, have fishhooks in their licenses which limit the amount of real-world information users of the product can share. Personally, if I were starting a thing from scratch, I'd be inclined to use Postgres as a baseline and DB2 or SQLServer for anything it can't handle.

trome 10y ago
What can SQLServer handle that Postgres can't? I've only ever used the former in retail settings, where its hosed my customers over multiple times (thanks 1 core, 1GB ram & 10GB DB Size cap!) either via licensing, or edge cases where theres no community support, and the upstream software vendor told us to go fly a kite, so I'm very much not interested in SQLServer or any licensed DB, cause its a relationship ending move to say "Your database is gone, start scanning everything in the building again, sorry".

davidgerard 10y ago

The actual advantage: You never have to even think about licensing ever again. So instead of a giant SPOF database server, you can give every app its own clustered pair or triple of PG servers. (PG clustering is sorta painful to get really robust, needs some work here.) And if someone says "but it's unsupported" ... every third-party Oracle support shop is desperate to grab some PG support business. They can tell which way the wind is blowing. There are probably hypothetical use cases where Oracle is a better fit (it really is a very effective and powerful database), but these are fewer and fewer.