> For some, it's the only DB they are familiar with ("I used it before") I'm sure some of the reasons you use your RDBMS of choice over another implementation

> For some, it's the only DB they are familiar with ("I used it before") I'm sure some of the reasons you use your RDBMS of choice over another implementation or a NoSQL system distill to, at some point, "I used it before". Familiarity is a feature. This is especially true if your org invests in tooling that improves the usability of a DB. > badly-argued reasons such as "the schema might change" or "it's faster to just use MongoDB" Why are these badly-argued reasons? I currently work on a codebase that is making heavy use of MongoDB. We are using it as a way to store protobufs which will change very frequently in structure (adding new fields, removing old fields, etc). Our software is built so that it supports older versions of protos which is already needed for backwards-compatibility in APIs. Because we're using Mongo I've written a simple connector that maps our protos into Mongo that allows documents in a collection to map well into proto access semantics (default to emptiness). If a frontend developer wants to save some new field into a database they: 1. Add the field into the proto 2. Validation field in service (optional) We don't have any ops work needed. We don't have any roll forward or roll back planning needed. Since we're a really small team this flexibility afforded to us is a huge velocity boon. Since we use gRPC we push people towards not making backwards incomparable API which makes our mongo-mapper very basic. We are also planning on making use of things like `watch()` which is possible to do in some hacky ways in postgres but it's very easy to do with this architecture. I've never had as smooth an experience with PG/MySQL/SQLite, even with ORMs. > Seasoned DBAs almost always shook their heads in disapproval I'm assuming that seasoned typists shook their head when business people started to buy computers to typeset their own documents. I'm sure they were also proven right in the early days as documents were poorly formatted or took long to produce. But, it wasn't that way for long. Any time you have a field of people that is hyper optimized on maintaining a single workflow/tool/thing it will take a lot of effort to replace. There being a large amount of effort to replace a tool does not mean it shouldn't be replaced.