This reminds me of the saying "it's not the hammer's fault that it won't drive a screw. It's the carpenter's"
Use the right database for the job. Relational is good at OLTP data. Document makes sense when you don't want to join 6 tables to simply render a webpage. For transactions use time oriented dbs like timescale or wide column. If you need text search ship the data to elastic.
The best advice is to not worry about any of these issues until you need to scale horizontally. If you still don't want to bother with any of that too then just pick a new sql system like cockroachdb or even better just use a cloud provider like memsql, dynamo or cosmos.yeah your going to pay for it but then you can focus on building great things instead of worrying about n+1 problems and over fetching of rows.
The point of a database is to persist data... Use cases are many and that is reflected in the choices at our disposal. Moral: Pick the right tools for the task at hand.
My main job is not in IT, but I do have a CS degree and have been programming for over 20 years (only born in 1984). I hate dealing with Servers, and want Graph Databases to be the new norm.
Well put. I am a firm believe that you should use the right tool for the job. That being said, people need to see the alternatives that CAN do what Firestore can't do out of the box. That is what this post is about. I believe competition creates innovation.
My main job is not in IT, but I do have a CS degree and have been programming for over 20 years (only born in 1984). I hate dealing with Servers, and want Graph Databases to be the new norm.
Hi Michael. I really didn't mean for this post to be click bait, I just had a lot of ideas I wanted to put in one post, and maybe I chose the title poorly. Perhaps it should have been a question instead of a statement.
I don't think I agree with those statements.
Most people join the Firebase platform due to Firestore. Firebase is still in development, but Firestore is not. The development is definitely dead on Firestore, and I purposely want to get their attention and call them out on that. Every other database grows after a year in features, but they have stopped.
I also do believe there WILL be a nearly perfect database, perhaps as early as next year. We shall see.
I am a firm believer that you should not have to manage two databases, when one database should add simple features like Full Text Search and Counters. MongoDB is a perfect example of how this should be done.
Let me take a different angle here. According to Gartner the database market size is a 60+ BILLION dollar industry. If there's going to be one perfect database in 2023, then there are a bunch of companies out there spending a lot of resources on what surely seems like a hopeless cause.
Hey there is no doubt we are seeing convergence in the industry as each product works to scale horizontally and adopt different data models (relational, search, document, wide-column, key-value, Realtime, timeseries, and graph.) One thing the industry is learning from each other is that each model has an appropriate use case, and no one model is the "best".
Sure Moore's law and the cloud will eventually make some of these decisions less relevant, but never irrelevant.
Cloud providers creating back-ends as services with pay as you go auto scale - like firebase - are what will really make databases irrelevant to programmers. And I for one, welcome it. I'd rather build interesting applications and spend my time on user experience than coding up DTOs, repository patterns, REST endpoints and graphQL interfaces so that I can self host on Kubernetes or swap out my back end databases on a whim. Been there, done that. Anyone is right to argue that using these services create lock in - especially if your code is not designed to be loosely coupled - but the real question is - why should it matter in 2022?
There will always be a need for SQL and data engineering, for example shipping data changes in real time from cloud firestore into some other database more conducive to ad-hoc analytics. But these skills will not be required of full stack developers of the future.
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.
Besides the article title being clickbait....
This reminds me of the saying "it's not the hammer's fault that it won't drive a screw. It's the carpenter's"
Use the right database for the job. Relational is good at OLTP data. Document makes sense when you don't want to join 6 tables to simply render a webpage. For transactions use time oriented dbs like timescale or wide column. If you need text search ship the data to elastic.
The best advice is to not worry about any of these issues until you need to scale horizontally. If you still don't want to bother with any of that too then just pick a new sql system like cockroachdb or even better just use a cloud provider like memsql, dynamo or cosmos.yeah your going to pay for it but then you can focus on building great things instead of worrying about n+1 problems and over fetching of rows.
The point of a database is to persist data... Use cases are many and that is reflected in the choices at our disposal. Moral: Pick the right tools for the task at hand.
Well put. I am a firm believe that you should use the right tool for the job. That being said, people need to see the alternatives that CAN do what Firestore can't do out of the box. That is what this post is about. I believe competition creates innovation.
Well if that's what the post is about how about a title that reflects that??
You've already debunked the two statements in your post title
Hi Michael. I really didn't mean for this post to be click bait, I just had a lot of ideas I wanted to put in one post, and maybe I chose the title poorly. Perhaps it should have been a question instead of a statement.
I don't think I agree with those statements.
Most people join the Firebase platform due to Firestore. Firebase is still in development, but Firestore is not. The development is definitely dead on Firestore, and I purposely want to get their attention and call them out on that. Every other database grows after a year in features, but they have stopped.
I also do believe there WILL be a nearly perfect database, perhaps as early as next year. We shall see.
I am a firm believer that you should not have to manage two databases, when one database should add simple features like Full Text Search and Counters. MongoDB is a perfect example of how this should be done.
J
Let me take a different angle here. According to Gartner the database market size is a 60+ BILLION dollar industry. If there's going to be one perfect database in 2023, then there are a bunch of companies out there spending a lot of resources on what surely seems like a hopeless cause.
Hey there is no doubt we are seeing convergence in the industry as each product works to scale horizontally and adopt different data models (relational, search, document, wide-column, key-value, Realtime, timeseries, and graph.) One thing the industry is learning from each other is that each model has an appropriate use case, and no one model is the "best".
Sure Moore's law and the cloud will eventually make some of these decisions less relevant, but never irrelevant.
Cloud providers creating back-ends as services with pay as you go auto scale - like firebase - are what will really make databases irrelevant to programmers. And I for one, welcome it. I'd rather build interesting applications and spend my time on user experience than coding up DTOs, repository patterns, REST endpoints and graphQL interfaces so that I can self host on Kubernetes or swap out my back end databases on a whim. Been there, done that. Anyone is right to argue that using these services create lock in - especially if your code is not designed to be loosely coupled - but the real question is - why should it matter in 2022?
There will always be a need for SQL and data engineering, for example shipping data changes in real time from cloud firestore into some other database more conducive to ad-hoc analytics. But these skills will not be required of full stack developers of the future.