HSBC moves from 65 relational databases into one global MongoDB database

This title is misleading, and the article is missing a key piece of information.<p>This is ONE system at HSBC - out of literally HUNDREDS (maybe thousands) of applications. It&#x27;s not as if HSBC is moving ALL of its applications to MongoDB. HSBC doesn&#x27;t have a single tech stack. They have thousands of IT employees all using different tech, in different parts of the world, for different departments. This might be as inconsequential as the system that catalogues security camera feed URLs - or maybe the one that monitors remote employee company mobile data usage - who the F knows, because the article gives us zero information.<p>Account Management, Credit Cards, Mortgages, Security, Asset Management, HR, Legal, Compliance, Regulatory, Risk Management, Trading, Operations, Building management, Payroll, ATM comms, Clearance&#x2F;settlement, Website, a million different reporting engines, etc, etc, etc... and then each region usually has its own application for each function - literally hundreds of tech stacks in every tech you can imagine from DB2 Mainframe to Oracle to MongoDB. All banks are like this.<p>This article is just vague PR and is just referring to one single group consolidating their regional instances. It does not deserve HN attention.

Jepsen&#x27;s latest analysis of MongoDB -- <a href="https:&#x2F;&#x2F;jepsen.io&#x2F;analyses&#x2F;mongodb-4.2.6" rel="nofollow">https:&#x2F;&#x2F;jepsen.io&#x2F;analyses&#x2F;mongodb-4.2.6</a> -- finds that it doesn&#x27;t even preserve snapshot isolation when set at the highest consistency level. This seems like a pretty terrible decision.<p>I&#x27;ve never wanted to short a company more in my life.

This is like one step above csv files on an NFS share.<p>Could be a great way to wash some crimes off the books, &quot;oh our DB failed and our backups were stored in the database as well, oopsie&quot;.<p>In less than 5 years there will be an EU directive on how financial institutions need to have immutable db architectures with full provenance.

I have to say that on the surface, this sounds horrific.<p>- MongoDB: Yes<p>- Micro Services: Yep<p>- Some attempt at a grand unifying model: Of course<p>That&#x27;s pretty much a 10&#x2F;10 shitshow as far as I am concerned. Mix in banking regs &amp; regional differences for afterburner on that money furnace.<p>But, in reality, I doubt that one of those 65 relational databases involves the core customer&#x2F;account&#x2F;transaction processing facilities. These are probably (hopefully) still running on an IBM system with proper ACID &amp; uptime guarantees. Anything a live transaction flow (especially credit&#x2F;debit processing) is going to touch could never be trusted on something like MongoDB in this current reality.

I&#x27;ve worked contracts in UK banks for a number of years now. Nothing on the mainframes but I know some of the guys that do work on those and, despite the constant stream of flavour-of-the-month tech that we talk about constantly in places like HN, the mainframes work well and will not be replaced any time soon.<p>The dev cycle for releases and whatnot is incredibly long due to testing and, lets be honest, fear, in case something breaks but when it comes to battle-tested technology, mainframes and DB2 are right up there.<p>I do know of some code that&#x27;s over 40 years old and still runs at the core of one of the big banks...<p>MongoDB, despite its capabilities, is... an odd choice imo! Not trying to second-guess but if I was in that meeting I would have certainly raised an eyebrow.<p>Good luck to them.

I have no actual information about this migration but I wouldn’t be surprised to learn that the databases that are being consolidated are for some minor role or are separate instances with duplicate data for analytics or whatever. It sounds wildly unlikely that they are going to smush together all their customer accounts in one MongoDB instance. As well as being a huge technic challenge I’m sure regulators would have something to say about this.

Sounds like a win-win for them. They get to market themselves as staying up to date with tech (although the HSBC personal banking app I use indicates otherwise). And when they &quot;lose track of&quot; the money they move for the cartel and terrorists, they can blame MongoDB and spare some execs the jail time.

I was there in Aug 2019 and I did hear them talking about mongo, There was a programme at the time to &quot;refactor&quot; their estate, a part of that they wanted to replace bunch of ad-hoc databases with clunky- or no data governance with one (or fewer) central places, which will be under Data IT control. The rationale was to reduce risk of data loss, leak or general business continuity issue in what was 6-12 month project.<p>The cost of architecting relational model that would be cover for 65 mini databases in a bank will be astronomical. It is far easier to setup no-SQL entry point that would auto-conform for whatever requirements upstream applications might have.<p>It is a technical win for Mongo, but I don&#x27;t believe this is an attempt by HSBC to get up to speed with database trends. HSBC are removing internal audit strikes, nothing more than that.

There’s been a lot of talk about the Jepsen-Mongo affair on HN lately, but the problem I have with Mongo and NoSQL in general is much more basic - it’s modeling relationships, which always end up appearing in every data model I’ve ever designed.<p>I’m aware you can keep references from one doc to another but it always ends up being a messy affair even at smallish scales, and it feels as if the cognitive burden of managing these relationships ends up falling on the dev, instead of being managed by the DB.<p>For those of you using MongoDB in large scale large production apps, is this not a problem? Is your underlying business domain really non-relational, or do you manage to comfortably run highly relational models on a doc-based DB? How?

Everything about this sounds mad. I&#x27;d have put referential integrity high on a bank&#x27;s list of wants.<p>Clearly they have some expertise, I&#x27;d love a more in depth look at how they arrived at the decision.

Very rarely do headlines make me physically cringe but here we are.

I&#x27;m not in the banking industry but this sounds like the type of industry where you really need strong DB schemas in place and not something mongo-like ...

After the latest Jepsen analysis of Mongo I&#x27;m surprised anyone would use it for anything <i>that</i> serious.

Building in plausible deniability so they can resume their HSBC money laundering services with impunity?<p>Geniuses!<p>Edit: In case you missed the story <a href="https:&#x2F;&#x2F;www.bbc.co.uk&#x2F;news&#x2F;business-18880269" rel="nofollow">https:&#x2F;&#x2F;www.bbc.co.uk&#x2F;news&#x2F;business-18880269</a>

&quot;is looking to&quot; makes this sound aspirational. The absence of operational lessons learned that would come out of a deployment make me wonder if this actually happened.

Sounds like the opening scene of a horror movie.

A fortune 100 financial institution I once worked for had an initiative to migrate their extremely large, fairly well normalized DB2 database to schema-less dynamoDB.<p>All new tables had to go into dynamo, and if your service begins consuming an old DB2 table, it had the job of migrating that data to dynamo.<p>The end result of this was applications that half pointed to DB2, half dynamo, confusing new data with old, and tons of bugs relating to losing entries into dynamo tables under outdated keys, not being able to clearly match up customer data, and myriad problems that were never a consideration using a relational database. Needless to say, I pulled all of my assets out of this institution as soon as I had the chance.

The article makes this sound way bigger than it is. HSBC has <i>thousands</i> of applications and probably tens of thousands of databases. Migrating one app to use a different DB model means very little for the big picture.

Mongo works well for storing chunks of JSON from transactional browser apps (which I guess is what HSBC is targetting), doesn&#x27;t require you to have custom endpoints, has a good replication&#x2F;HA story (on paper at least, if your devs know what they&#x27;re doing and don&#x27;t use defaults plus multiple nodes with CORS, etc.), good mindshare among webdevs, and is even the de-facto API for JSON stores with AWS&#x27; &quot;DocumentDb&quot; and Azure&#x27;s Cosmos DB being drop-in replacements. But using it for banking&#x2F;backoffice apps would be pure madness.

The whole premise of this seems wrong. I&#x27;ve worked on large financial systems that have happily supported different rules for different countries using a relational database. The database was never the issue, it was how to handle testing and feature enablement. This seems like the wrong cure to the problem, and a cure that will end up causing more problems than it solves. i.e. a hack. I&#x27;d love to hear more about the rational. I just don&#x27;t understand it.

Each and every one of these MongoDB migration rationales contains some variation of &quot;schema design is hard, let&#x27;s go shopping.&quot;<p>Granted, there are plenty domains where you can get away with having a blurry schema with the occasional bug creating a new localized data anomaly, but banking, where such things lead to customer trust erosion - I just don&#x27;t get it.

Oh my. This seems like a really bad idea. I&#x27;m calling it now, this will go wrong.<p>That &quot;Micro Service Instance&quot; is not a microservice, it&#x27;s an Enterprise Service Bus (ESB), aka the Egregious Spaghetti Box.<p>That&#x27;s aside from the fact that relational data belongs in a relational database.<p>I really can&#x27;t imagine it being a single instance, that just does not make any sense.

When do they go live and how can you short them?<p>Ps. I think they never heard of database per service when looking at their microservice graph. Lol

Any time I have to use an HSBC online product (they throw in an occasional promotion for their credit cards and savings accounts) it feels like a trip back to the 90s - popups and extra windows on different domain names that are slowly &quot;loading...&quot; information for trivial operations like scheduling a payment on a credit card.

I think this isn&#x27;t primarily about a database migration&#x2F;consolidation and specifically not about MongoDB. IMHO it&#x27;s about cutting cost and complexity by building a single world-wide software platform. Of course this also means that local specialities and local teams will be questioned and probably be made redundant.

I recently came to this article[1] where Guardian switched to PG from MongoDB<p>[1] <a href="https:&#x2F;&#x2F;www.theguardian.com&#x2F;info&#x2F;2018&#x2F;nov&#x2F;30&#x2F;bye-bye-mongo-hello-postgres" rel="nofollow">https:&#x2F;&#x2F;www.theguardian.com&#x2F;info&#x2F;2018&#x2F;nov&#x2F;30&#x2F;bye-bye-mongo-h...</a>

Microservices and NoSQL - the wonder-weapons against every IT problem, aren‘t they?!<p>I really have to pivot my business - new name will be „The Microservice-NoSql Consulting Company“ and we will sell tailored versions of the „Microservice-NoSql Strategy“! (Changing names and colors of boxes for 2000$ per day)

The whole thing sounds like a terrible idea. Why would you want to put all the data from at least 65 different applications in the same table? In MongoDB? To save cost?<p>I simply don&#x27;t get it. It doesn&#x27;t make sense to me, but perhaps they know something we don&#x27;t.

I don’t see how one global mongo is going to help solve any of their issues. Maybe they just want to bury their issues under the carpet a little longer.<p>I also hope they’ve configured their mongo correctly since out of the box Config is not appropriate for many use cases

Hacker News has become just “mongodb bad, sql good”

This sounds problematic:<p>1) mongoDB does not offer the guarantees required by a bank.<p>2) Application developers using mongoDB rarely protect themselves against NoSQL injections. Most of them are unsuspecting that they even exist.<p>e.g.: What is your user id? {$ne: null}... whoops, now every user record is returned.<p>3) They better make sure they use the Decimal128 type for their currency fields, and make sure that the value is not being casted to float on the client. e.g.: on a JS client, every number is a float.<p>Unless they&#x27;ve taken the necessary precautions this is a disaster waiting to happen. Hopefully other banks do not do the same.

I would suspect they&#x27;d keep the core money transactions in the existing DBs, but use mongo for less important things like sending junk mail, customer support sessions.

I have seen many rewrites for financial institutions in my life; one of the biggest I had a good insight look at during the entire project was a Tandem Nonstop Cobol rewrite to Java; the famous 10s of millions of lines to nice clean Java code. Many of them never work; this one was, if I remember correctly, upwards of 50m Euros and was thrown away because it did not work in the end. I think the Tandems are still running.

It they just put commercial details follow up data + some stats in there, it&#x27;s ok.<p>It is very infrequently updated, integrity is not at too much risk. In case it&#x27;s lost, business is not impacted too hard as long as you can find contact details eslewhere.<p>But the replication story is good, and if they got tons of different schemas, it will make their life easier.<p>So yes, for transactions it would be bad, but maybe for this particular use case, it&#x27;s ok.

I can see how they would use in some parts: analytics, internal reports, etc.<p>It is interesting that you can use Mongo and keep the data in a geographical location and still be able to run a global query: <a href="https:&#x2F;&#x2F;docs.mongodb.com&#x2F;manual&#x2F;tutorial&#x2F;sharding-segmenting-data-by-location&#x2F;" rel="nofollow">https:&#x2F;&#x2F;docs.mongodb.com&#x2F;manual&#x2F;tutorial&#x2F;sharding-segmenting...</a>

I think they’re just using it for document storage not customer and financial data. Document storage and retrieval is a big cost for large institution.

To put this into context - I met with a senior tech person there (one layer below the group CIO) a few years back and he said they had something like 40000 distinct IT systems globally. So replacing 65 of them with one MongoDB instance is something like 1&#x2F;8th of one percent of their systems.

65 databases unified globally, for HSBC’s global presence, is ~2 databases per country. This is, probably, a minor trial effort for one of their services, not the core system (which is un-unifiable due to banking privacy laws in place) or any kind of cross-function unification.

This article is misleading. They have migrated some of their databases to mongo, not all of them

I need to LOL a little bit at all this, the headline, the article.<p>First off, how would such an article even come about? Feels like more of a recruiting&#x2F;marketing piece.<p>The old story at hsbc was that the ATM software hadn&#x27;t been updated in twenty years, cause stability....

If someone was involved could you share details on the rationale behind this? I used to like mongo but has it changed.<p>I remember specific flaws&#x2F;hacks with bitcoin websites coming down to mongo race conditions&#x2F;inconsistency issues.

Relax HN guys.. this is the reason for this:<p>&quot;Local requirements for each country will be built into the application, but there&#x27;s no need to maintain separate data models or separate databases anymore. We could easily design the global data model and database using the MongoDB JSON schema model. That brings data from all operating countries into one database and the application can run on just one database. Which is a lot of reduction in resource and maintenance cost.&quot;<p>Is there any Database that can do this? other than MongoDB? I am hearing about data corruption in MogoDB, I believe that is due to bad, out of the box settings, which I believe they would have mitigated when using in cooperation with MongoDB company (which I am sure they are).

Never mind the technology, a single data model would be a feat in itself.

If you &#x27;ve ever used HSBC web banking u ll know it&#x27;s one of the worst things mankind ever created. I m not sure if this is good news for MongoDB

Is it common that a sufficiently large doc db is just an un-normalized rdb? I&#x27;ve seen swagger uis of doc dbs that make me wonder wtf&#x2F;why.

What’s the over&#x2F;under odds on betting about how long it’ll be until it’s accidentally exposed to the internet and hacked?

There’s a lot of complaining here but MongoDB has been used by startups for like a decade?<p>I don’t think I’ve seen a single HN article complaining about actual data loss. That would be something that would get upvoted immediately.<p>So what gives? Especially since earlier and older versions of Mongo apparently had far less data stability.<p>I’ve probably read far more complaints about Postgres in HN articles (difficulty setting up, poor defaults, etc). And Postgres may not even be as popular as Mongo. So what gives?

I’m in the UK and glad I don’t bank with HSBC

Wasn’t there a problem where mongo would literally lose records under high loads ?<p>There was an article on it about it a few years ago.<p>Did they fix that?

This is probably some aspect of HSBCs computing needs, likely less than 2% of the data the store.

Yeah, this is about par for HSBC IT.

Hiding your complexity behind a (poorly designed) layer doesn&#x27;t make it go away.

How do they get ACID guarantees and schema enforcement?

And I am moving all my money out of HSBC...

Modern take on shredding papers

Yeah this can&#x27;t go well...

Behind Bad Indian Coder ...

And it’s gone.<p>(Sorry)

shocking

That was a mistake

Lol. Just lol.

Uh, how does this work with eg GDPR or data protection laws that require all customer data to remain within the country of operation?

isn&#x27;t this a bad idea

HSBC IT is a hollowed out outsourced shop. Just like Avis Budget, Disney, Walmart and Walgreens. They will all move to MongoDB data stores sooner than later.

And of course they will expose it to the web without authentication!

Old guys ... what dB they use in London and Hong Kong. Are they still use mainframe?

Lots of negative comments about MongoDB for folks who don&#x27;t use it, but perhaps give NoSQL a chance and keep an open mind? there is no need to structure the data into tables and schema does not need to be enforced at the DB level.<p>Google has been running its entire infrastructure on a NoSQL database for years.<p>Perhaps folks need to keep some open mind and see if that works instead of dismissing a new trend?