Yes, me, but I will rest my case by doing the reverse, saying that SQL should have less believers :D
As I study databases more and more, the reasons to use a RDBMS/standard SQL are getting fewer and fewer. From the only hammer I knew how to use (a few years ago), I became an anti-SQL basically.
A few examples:
If you have a (fast iteration product) prototype/startup/small project there is no reason to waste precious time to handle a schema and applying migrations every day, so NoSQL is the smart choice.
If you have a huge project you would need a scalable DB, if you shard you will lose the benefits of relationships. You can insist on using SQL at this scale, but you will have to write/use something like Vitess.
*I don't include Spanner/CosmosDB/Cassandra in this topic, I'm referring to "regular SQLs" like mysql, oracle, sql server, postgres.
If you have (too) many relationships (2+ degrees of connections) you would want to move them into a Graph, and whats left probably could fit into a NoSQL.
If you have a financial product you would be crazy if you don't use an event-sourcing architecture (which can be later aggregated into SQLs, thats true).
If you want to store text for search, you would use something like ElasticSearch.
Let's not forget about TimeSeries (logs, analytics) and GeoData data, which none are best fit with SQL engines.
Like I said, fewer and fewer use cases the *SQL products have nowdays.
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.
Yes, me, but I will rest my case by doing the reverse, saying that SQL should have less believers :D
As I study databases more and more, the reasons to use a RDBMS/standard SQL are getting fewer and fewer. From the only hammer I knew how to use (a few years ago), I became an anti-SQL basically.
A few examples:
If you have a (fast iteration product) prototype/startup/small project there is no reason to waste precious time to handle a schema and applying migrations every day, so NoSQL is the smart choice.
If you have a huge project you would need a scalable DB, if you shard you will lose the benefits of relationships. You can insist on using SQL at this scale, but you will have to write/use something like Vitess.
*I don't include Spanner/CosmosDB/Cassandra in this topic, I'm referring to "regular SQLs" like mysql, oracle, sql server, postgres.
If you have (too) many relationships (2+ degrees of connections) you would want to move them into a Graph, and whats left probably could fit into a NoSQL.
If you have a financial product you would be crazy if you don't use an event-sourcing architecture (which can be later aggregated into SQLs, thats true).
If you want to store text for search, you would use something like ElasticSearch.
Let's not forget about TimeSeries (logs, analytics) and GeoData data, which none are best fit with SQL engines.
Like I said, fewer and fewer use cases the *SQL products have nowdays.