Most apps will never have a huge amount of traffic, or data, or any special requirement appart from basic CRUD operations. And this is by design.
Other apps could benefit from one of the few features that are exclusive of one DB but:
1 - By the time you start the app, you probably don't know what the requeriments will be.
2 - By the time your app has this requeriments, the DB may have released a couple of new versions, with a different set of features and fixed for former drawback.
3 - Some parts of your app may benefit from the features of one db, while other parts of the app may benefit from features from the other db.
4 - From time to time, there's a blogpost from a major company explaining why they switched from X to Y. And then it's time to sit back and enjoy all the cargo culters claiming how X is completelly outdated and everybody need to migrate to Y.
It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
None of that is a compelling reason to hamstring your application development by intentionally ignoring widely useful but non-universal features like (for Postgres) check constraints, varlena, RETURNING, or array fields. These and others have a direct impact on how efficiently and effectively you can organize and access the information you're storing, which is the very foundation of "basic CRUD operations", to say nothing of anything non-trivial. Different databases are appropriate for different situations, but what you're saying boils down to "we don't know exactly what we need, so we're not going to think about it".
We don't know exactly what we need, so we're not going to think about it.
If you have experience creating products, you will agree with me that, when you start developing it, you have no idea of how this product will end up looking like when it hits the market.
And just to finish this conversation. I like fotography and I use to hang out with fotographers. And I found out that there are different types of fotographers.
There are some photographers who buy extremelly expensive gear, know all the physics related to lenses, know all the features of the camera and even play with the firmware. And, still, they take shitty pictures. Basically, because they think that the camera is the most important for a fotography.
Other fotographers, they just take their iPhone out of their pocket and take wonderful photographies. Because, knowing the limitations of their iPhone, they understand that what makes a great photography is the light, the composition, the subject, the color, the intention... And not the camera.
For web development, it happens exactly the same. Some people just find the simplest solutions to create a product and put it in the market.
Other people bring their startup to a financial or technical banckrupcy while talking about kubernetes, microservices, mongodb and graphql.
It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
I have several years of experience creating products, and I disagree emphatically. As a software architect (or at least when wearing that particular hat), it's my job to think about how a given product will end up looking when it hits the market. The picture evolves based on feedback and shifting requirements, but it's still a picture representing the same fundamental idea. And that fundamental idea, the process of thought that the product itself is supposed to embody, is an idea about information. How you organize, store, and retrieve that information is one of the first critical decisions you make in the course of bringing the product to life. Agility, minimum viability, and so forth are great ways to minimize risk and iterate safely, but they don't excuse you from thinking about what you're doing.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Most apps will never have a huge amount of traffic, or data, or any special requirement appart from basic CRUD operations. And this is by design.
Other apps could benefit from one of the few features that are exclusive of one DB but:
1 - By the time you start the app, you probably don't know what the requeriments will be.
2 - By the time your app has this requeriments, the DB may have released a couple of new versions, with a different set of features and fixed for former drawback.
3 - Some parts of your app may benefit from the features of one db, while other parts of the app may benefit from features from the other db.
4 - From time to time, there's a blogpost from a major company explaining why they switched from X to Y. And then it's time to sit back and enjoy all the cargo culters claiming how X is completelly outdated and everybody need to migrate to Y.
None of that is a compelling reason to hamstring your application development by intentionally ignoring widely useful but non-universal features like (for Postgres) check constraints, varlena,
RETURNING, or array fields. These and others have a direct impact on how efficiently and effectively you can organize and access the information you're storing, which is the very foundation of "basic CRUD operations", to say nothing of anything non-trivial. Different databases are appropriate for different situations, but what you're saying boils down to "we don't know exactly what we need, so we're not going to think about it".If you have experience creating products, you will agree with me that, when you start developing it, you have no idea of how this product will end up looking like when it hits the market.
And just to finish this conversation. I like fotography and I use to hang out with fotographers. And I found out that there are different types of fotographers.
There are some photographers who buy extremelly expensive gear, know all the physics related to lenses, know all the features of the camera and even play with the firmware. And, still, they take shitty pictures. Basically, because they think that the camera is the most important for a fotography.
Other fotographers, they just take their iPhone out of their pocket and take wonderful photographies. Because, knowing the limitations of their iPhone, they understand that what makes a great photography is the light, the composition, the subject, the color, the intention... And not the camera.
For web development, it happens exactly the same. Some people just find the simplest solutions to create a product and put it in the market.
Other people bring their startup to a financial or technical banckrupcy while talking about kubernetes, microservices, mongodb and graphql.
I have several years of experience creating products, and I disagree emphatically. As a software architect (or at least when wearing that particular hat), it's my job to think about how a given product will end up looking when it hits the market. The picture evolves based on feedback and shifting requirements, but it's still a picture representing the same fundamental idea. And that fundamental idea, the process of thought that the product itself is supposed to embody, is an idea about information. How you organize, store, and retrieve that information is one of the first critical decisions you make in the course of bringing the product to life. Agility, minimum viability, and so forth are great ways to minimize risk and iterate safely, but they don't excuse you from thinking about what you're doing.