8 ms·

I have a lot of respect for databases in general, and DB2 is no different. But if you've ever tried to install DB2, you'll know it's a monstrosity, and even int

I have a lot of respect for databases in general, and DB2 is no different. But if you've ever tried to install DB2, you'll know it's a monstrosity, and even internally it was hard to get a license. The result of this is that most IBMers I know would rather use e.g. Postgres for other projects, not DB2. Now I'm not silly enough to think Postgres will replace DB2 at e.g. banks, but the effect is that Postgres reputation and knowledge spreads, and DB2 reputation and knowledge die. In the long run, I think this is a good thing. Also, if you read between the lines, there's a ludicrous amount of infighting in IBM, which is probably how they ended up with four code bases. Still happens to this day.

gaius 9y ago
Now I'm not silly enough to think Postgres will replace DB2 at e.g. banks You might be surprised then, because that's not silly at all. DB2 may hang on in the Back Office, the least technically sophisticated bit of banking for various reasons for a while longer, but it's long gone from the Front Office and Postgres is one of the replacements. I don't think anyone is starting new projects on DB2 even in BO.
- ghshephard 9y ago
  Are there any databases successfully in production in high-value transactional environments other than oracle or DB2? I have to believe a lot of the pain coinbase is experiencing stems from their decision to use mongodb - which I love and use daily, but would never, ever have chosen over Oracle for high transaction bitcoin exchange. I wonder if anybody has done a write up on this oracle/db2 versus “others” in the super-high-value back office scenario.
  - hunterjrj 9y ago
    I think SAP keeps Sybase Adaptive Server Enterprise on life support due to it still being used for financial applications.
    - kchoudhu 9y ago
      Both investment banks I worked at were massive Sybase ASE shops. Oracle costs too much for what you get.
      - ghshephard 9y ago
        In terms of cost - I've always thought that one reason Oracle can charge the many millions of dollars per Server for a Database License is that, over the total cost of a project (with sometimes many hundreds of engineers), and the value of the project (Driving 100s of millions or more per year) - that the Database License cost would end up being round off error. The corollary to this, of course, is that anybody who isn't involved in projects of that scale, is going to be far better served with Postgres/MySql. It will be interesting to see what the uptake on products that try and fit in the middle - like Amazon Aurora - High scale and affordable.
        kchoudhu 9y ago
        I've been part of exciting conversations with desk heads attempting to justify database licensing fees in flat/falling trading environments where traders and people are being let go. Given those experiences, I personally stopped optimizing for today's flush tech budget. I now budget for what I know is a realistically shitty future state of affairs where we have to keep the lights on [1] while spending as little as possible. [1] The one worse thing you can tell a trader during a 2008-level crisis than "I need more money for databases" is "you can't trade, we don't have enough capacity to handle the additional market vol".
        gaius 9y ago
        They can charge it because if you really need Oracle, there really is no substitute. 12c is genuinely state-of-the-art, Exadata does things that only mainframes can otherwise do and a bunch of stuff that they can't. There are far fewer people however that do really need it, than believe that they do... The vast majority of Oracle shops could probably switch to Postgres for less than their annual licenses, then start saving the money from the second year on... My rule of thumb is that Postgres gets you 50% of Oracle for 0% of the price. Most of what most people need is somewhere in that 50%. SQL Server gets you 90% for 25% of the cost. I think Oracle will lose a lot of seats to SQL Server once it's stable on Linux.
  - gaius 9y ago
    Are there any databases successfully in production in high-value transactional environments other than oracle or DB2? Yes, Postgres is often used and in-house developed DBs are fairly popular too. On the commercial side, Sybase still exists too! And of course SQL Server, tho' I am not aware of anyone using it on Linux in production yet. The inertia keeping DB2 in the BO is all the third party apps running on it - if they move they will need to persuade all their vendors to move en-masse to whatever comes next. FO software is a lot more bespoke and anything from outside tends to be chosen by people who know what they're doing. I have to believe a lot of the pain coinbase is experiencing stems from their decision to use mongodb Almost certainly. I would go in-house before Mongo any day of the week. That's if Postgres wasn't already a better JSON store than Mongo is...
  - pjmlp 9y ago
    SQL Server is also used in such scenarios.
  - thriftwy 9y ago
    These days you often have multiple systems. One for rock solid storage, one for fast moving development on the same dataset. Apache Ignite tries to become the database you can trust that kind of data, but it's "not there yet" to be used as the only storage.
  - dmd 9y ago
    Are there any databases successfully in production in high-value transactional environments other than oracle or DB2? Teradata! And IMS, but that's not relational.
    - snaky 9y ago
      And ADABAS (officially declared fully supported through the year 2050 and beyond). Most often considered non-relational too. High-value transactional environments most often neither relational nor even running on operating system (in modern sense at least), like zTPF "because a real operating system is too high level and therefore too slow for real transaction processing needs". Current users of TPF include Sabre, VISA, American Airlines, American Express, HP SHARES (formerly EDS), Holiday Inn, Alitalia, KLM, Amtrak, Marriott International, Travelport, Citibank, Citifinancial, Air Canada, Delta Air Lines, Japan Airlines and many others.
- zhte415 9y ago
  BO has all been about cost over the past few years, and that's only increasing. 'Robotics' solutions are what new projects are, which are simply layers on existing solutions. Clamp over existing things, rather than re-implementing them.
  - gaius 9y ago
    'Robotics' solutions are what new projects are It's funny: a few years ago in the FO we heard a rumour that the bank was starting work on robotics, and were curious and some of my colleagues were keen to get involved. Robots! We didn't realise at the time that "robotics" is the word BO use to mean "any sort of automation, whatsoever". Even VBA. Banks are now trying to recruit graduates with the promise of working on "robotics", ho ho ho.
    - zhte415 9y ago
      Yes. The term robotics as used in banking is a bit ridiculous. EUC is deeply frowned upon by audit however; a different name is used. The access to quality tech BO has is terrible. Lack funding for people that can DIY and lack time and budget to experiment. Fintech is not driven by tech but by regulation where banks are forced to make an investment in change, not just talk about it.
mey 9y ago
Did an exhaustive research for some payment processing system where we examined rdbms, document and other DB types. We could find no niche or feature set that wasn't better satisfied by either SQL server, Postresql, or Oracle RAC (in the rdbms area). Depending what you needed to optimize for (cost, clustering, ease of use, performance, tooling).
keeler 9y ago
I put our DB2 installation process into an Ansible playbook. Installation time is now like 12-15 minutes, tops.

gaius 9y ago

Now I'm not silly enough to think Postgres will replace DB2 at e.g. banks You might be surprised then, because that's not silly at all. DB2 may hang on in the Back Office, the least technically sophisticated bit of banking for various reasons for a while longer, but it's long gone from the Front Office and Postgres is one of the replacements. I don't think anyone is starting new projects on DB2 even in BO.

ghshephard 9y ago
Are there any databases successfully in production in high-value transactional environments other than oracle or DB2? I have to believe a lot of the pain coinbase is experiencing stems from their decision to use mongodb - which I love and use daily, but would never, ever have chosen over Oracle for high transaction bitcoin exchange. I wonder if anybody has done a write up on this oracle/db2 versus “others” in the super-high-value back office scenario.
- hunterjrj 9y ago
  I think SAP keeps Sybase Adaptive Server Enterprise on life support due to it still being used for financial applications.
  - kchoudhu 9y ago
    Both investment banks I worked at were massive Sybase ASE shops. Oracle costs too much for what you get.
    - ghshephard 9y ago
      In terms of cost - I've always thought that one reason Oracle can charge the many millions of dollars per Server for a Database License is that, over the total cost of a project (with sometimes many hundreds of engineers), and the value of the project (Driving 100s of millions or more per year) - that the Database License cost would end up being round off error. The corollary to this, of course, is that anybody who isn't involved in projects of that scale, is going to be far better served with Postgres/MySql. It will be interesting to see what the uptake on products that try and fit in the middle - like Amazon Aurora - High scale and affordable.
      - kchoudhu 9y ago
        I've been part of exciting conversations with desk heads attempting to justify database licensing fees in flat/falling trading environments where traders and people are being let go. Given those experiences, I personally stopped optimizing for today's flush tech budget. I now budget for what I know is a realistically shitty future state of affairs where we have to keep the lights on [1] while spending as little as possible. [1] The one worse thing you can tell a trader during a 2008-level crisis than "I need more money for databases" is "you can't trade, we don't have enough capacity to handle the additional market vol".
      - gaius 9y ago
        They can charge it because if you really need Oracle, there really is no substitute. 12c is genuinely state-of-the-art, Exadata does things that only mainframes can otherwise do and a bunch of stuff that they can't. There are far fewer people however that do really need it, than believe that they do... The vast majority of Oracle shops could probably switch to Postgres for less than their annual licenses, then start saving the money from the second year on... My rule of thumb is that Postgres gets you 50% of Oracle for 0% of the price. Most of what most people need is somewhere in that 50%. SQL Server gets you 90% for 25% of the cost. I think Oracle will lose a lot of seats to SQL Server once it's stable on Linux.
- gaius 9y ago
  Are there any databases successfully in production in high-value transactional environments other than oracle or DB2? Yes, Postgres is often used and in-house developed DBs are fairly popular too. On the commercial side, Sybase still exists too! And of course SQL Server, tho' I am not aware of anyone using it on Linux in production yet. The inertia keeping DB2 in the BO is all the third party apps running on it - if they move they will need to persuade all their vendors to move en-masse to whatever comes next. FO software is a lot more bespoke and anything from outside tends to be chosen by people who know what they're doing. I have to believe a lot of the pain coinbase is experiencing stems from their decision to use mongodb Almost certainly. I would go in-house before Mongo any day of the week. That's if Postgres wasn't already a better JSON store than Mongo is...
- pjmlp 9y ago
  SQL Server is also used in such scenarios.
- thriftwy 9y ago
  These days you often have multiple systems. One for rock solid storage, one for fast moving development on the same dataset. Apache Ignite tries to become the database you can trust that kind of data, but it's "not there yet" to be used as the only storage.
- dmd 9y ago
  Are there any databases successfully in production in high-value transactional environments other than oracle or DB2? Teradata! And IMS, but that's not relational.
  - snaky 9y ago
    And ADABAS (officially declared fully supported through the year 2050 and beyond). Most often considered non-relational too. High-value transactional environments most often neither relational nor even running on operating system (in modern sense at least), like zTPF "because a real operating system is too high level and therefore too slow for real transaction processing needs". Current users of TPF include Sabre, VISA, American Airlines, American Express, HP SHARES (formerly EDS), Holiday Inn, Alitalia, KLM, Amtrak, Marriott International, Travelport, Citibank, Citifinancial, Air Canada, Delta Air Lines, Japan Airlines and many others.
zhte415 9y ago
BO has all been about cost over the past few years, and that's only increasing. 'Robotics' solutions are what new projects are, which are simply layers on existing solutions. Clamp over existing things, rather than re-implementing them.
- gaius 9y ago
  'Robotics' solutions are what new projects are It's funny: a few years ago in the FO we heard a rumour that the bank was starting work on robotics, and were curious and some of my colleagues were keen to get involved. Robots! We didn't realise at the time that "robotics" is the word BO use to mean "any sort of automation, whatsoever". Even VBA. Banks are now trying to recruit graduates with the promise of working on "robotics", ho ho ho.
  - zhte415 9y ago
    Yes. The term robotics as used in banking is a bit ridiculous. EUC is deeply frowned upon by audit however; a different name is used. The access to quality tech BO has is terrible. Lack funding for people that can DIY and lack time and budget to experiment. Fintech is not driven by tech but by regulation where banks are forced to make an investment in change, not just talk about it.

mey 9y ago

Did an exhaustive research for some payment processing system where we examined rdbms, document and other DB types. We could find no niche or feature set that wasn't better satisfied by either SQL server, Postresql, or Oracle RAC (in the rdbms area). Depending what you needed to optimize for (cost, clustering, ease of use, performance, tooling).

keeler 9y ago

I put our DB2 installation process into an Ansible playbook. Installation time is now like 12-15 minutes, tops.