March 13, 2024 at 12:00 am
Comments posted to this topic are about the item Navigating the Database Landscape
March 13, 2024 at 1:30 pm
I have kept an eye on https://db-engines.com/en/ranking
There are a few things to note
There are a number of DB platforms that are either compatible with PostGres and MySQL (AWS Aurora, AWS RDS, GCP CloudSQL, GCP AlloyDB), based on PostGres (AWS RedShift, Greenplum) or have evolved from PostGres (Vertica).
The technology sprawl I see in various organisations is at odds with the architectural principle of controlling the technical complexity. I feel that that principle is one of the most disregarded principles in the architectural cannon. If you think it is bad in the DB space you should see what the situation is in the web framework space. It would be more accurate to call it web coat hangers rather than frameworks because you choose 2 for your technological wardrobe and the next time you open that door there are dozens!
In the DB world I can understand why a company has MySQL or PostGres or SQL Server but not all of them or even more!
Steve, as you point out there is no way you can be an expert in all the DB technologies or even in all the DB technologies in your organisation. My experience is that it is not really possible to be an expert in the entire SQL Server stack, it is just too big. The worrying thing is that I'm not convinced that sufficient expertise exists for a typical technology stack at an organisational level. Instead of pools of expertise with pockets of ignorance we seem to have pools of ignorance with small pockets of expertise. Things that looked great and made sense on Powerpoint have all sorts of niggly details that don't show up until they hit the real world.
The perfect team is not made up of perfect players, it is made up of players that work well as a team. This is true of technologies as well as people. A team that works well together can punch well above their weight. Remember the original Microsoft FastTrack SQL Server machines? Carefully chosen commodity hardware with well thought out best practises offering performance significantly higher than you'd expect at the price.
March 15, 2024 at 8:01 pm
Tend to agree, David. Pools of making decisions without knowing how to best use/support/code/etc. across technologies.
I see too many people bringing in a NoSQL platform, or changing the RDBMS because they have some expertise and think it's better, but often their expertise doesn't translate to all others on the team, or to the other groups. The number of orgs with 4+ db platforms is high, and unless those are very specific uses (Redis, Neo4J), it's still.
I can see why you might have PostgreSQL and SQL Server, especially if you are thinking to transition from one to the other, but adding in, or allowing production use of a third platform seems silly. Of course, if you were an Oracle shop adding PostgreSQL, I could see how a particular software package got you to SQL Server as well.
Orgs should have an approved list of tech. Whether db, web tech, language, etc. Only those items should be used for anything production, though there should be a process to evaluate and decide if a new tech is allowed.
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply