91–99 of 99 posts
Earlier quoted context omitted.
It does become necessary when you really do need the computing power of hundreds of servers but that is rare.
It's so rare that it's barely worth mentioning. Sure, there are use cases where any rare thing might become necessary, but it's far from the default everyone assumes it to be.
Earlier quoted context omitted.
you really should scale vertically until you can't anymore. a server with two 64 core epyc CPUs and 3TB of RAM and 24 NVMe flash SSDs is going to be able to handle 99% of companies SQL DB needs.
Won't really solve latency too if you're operating globally. But yes.
Added to my list of troubles & worries I avoided because I didn't rely on a random external company for critical infrastructure.
First Fauna graduates from Hololive, and now she graduates from being a company. Rip.
First Fauna graduates from Hololive, and now she graduates from being a company. Rip.
elaborate
https://www.jaxon.gg/ceres-fauna-graduation-announced-why-is...
One of the services that can replace the fauna service is DocumentDB Postgres plugin (+proxy that is not open sourced yet, but will be shortly). It's available on Azure, but I can also see other Postgres Providers will start picking this up. https://github.com/microsoft/documentdb
Earlier quoted context omitted.
The one constant in my career has been mongoDB -- specifically, projects to replace it with a relational database after a deployment had failed to deliver any of the expected benefits, and introduced unforeseen downsides that had become untenable. Mongo has literally never come up in any context for me where it wasn't either already, or eventually, slated for retirement. I absolutely don't doubt a document store incl…
The reason to change is scale. If your Postgres spend is in the six digits a month range, JSONB is probably very painful for you. It does not perform very well. Additionally, you've probably spent a good amount of engineering time painstakingly sharding your database at the application level and hoping you've done it correctly. MongoDB solves these problems out of the box, among others. I have run both of these above…
Earlier quoted context omitted.
The one constant in my career has been mongoDB -- specifically, projects to replace it with a relational database after a deployment had failed to deliver any of the expected benefits, and introduced unforeseen downsides that had become untenable. Mongo has literally never come up in any context for me where it wasn't either already, or eventually, slated for retirement. I absolutely don't doubt a document store incl…
The reason to change is scale. If your Postgres spend is in the six digits a month range, JSONB is probably very painful for you. It does not perform very well. Additionally, you've probably spent a good amount of engineering time painstakingly sharding your database at the application level and hoping you've done it correctly. MongoDB solves these problems out of the box, among others. I have run both of these above…
I've personally never had to shard anything in my professional career. Although IDK how painstaking the sharding would really be for most uses I can imagine besides like, social media. Facebook has to deal with everyone interacting with everyone. But the vast majority of situations most developers see isn't like that. You can run Salesforce purely sharding at the tenant level, since I only need to see my tenant's data.
Anyway I feel the need to be emphatic, I'm sure Mongo's benefits can be realized somewhere, just not in any small or medium sized company that doesn't need sharding, and does need a schema.