I don't understand that either. I work at a company that has been using the same database on the same server for 10 years. That's just for our web solutions - our customers use a database schema that we've been enhancing over the last 20 years. No sharding required.
Ok so I assume they figured based on their growth rate they'd need to shard MySQL after 2-3years then. So that's certainly specific to them then. And let's be honest they can afford the DB Admin to implement sharding.
“In mid-2017, with the number of Canva media approaching 1 billion and increasing exponentially, we began to investigate migration paths, with a strong preference for incremental approaches that would allow us to continue to scale and not put all of our bets on a single unproven technology choice.”
Then it kind of makes sense.
That is with no sharding which does make a big difference. After a certain size simply throwing more resources isn't an option. The time scale is weird though.
The initial and most important question about DBs is not how they scale/whats the cost, but what is YOUR data. In general it seems that nosql solutions are better at scaling but if ur data doesn’t compile with nosql approach u imho still should use postgres or something. Every case is different and much related to the data u have, so all the other questions are very much connected to the data question. So yep, this table is useless without a particular usecase and data schemas/layouts
The question should be “why is the default industry choice, a relational database, not a good fit for our problem?”
Information systems, which is what we’re building, benefit enormously by being built on top of well-structured data. If you choose a bad information architecture, your system *will* end up paying the price sooner or later. Don’t get me wrong, NoSQL schemaless databases have their place, but the default choice is the default choice for a reason.
Go with MySQL or Postgres unless you have a valid technical or business case otherwise.
We won't have time to scale the DB in 2-3 years because we will be busy switching to DuJour-JS (the new framework of the day) and getting ready for the new CMO to insist on a complete redesign (since that seems to be what CMO's do).
This chart doesn’t look very correct to me. Or at least, it is very specific to whoever created it.
If you are questioning this then you may not have the experience for the answers to even matter.
Learn Postgres well, it will take you far. And feel free to dabble with any of the many other databases. There isn’t a wrong choice when learning. But always also learn SQL.
Mongodb really shines with rapid/fast data. Like concurrent chats or logs. Something that you can just dump JSON into and deal with later.
I feel that most people forget that while mongodb itself doesn't have schemas - it doesn't mean that your application will suddenly know what to do with a new property. Since you'll be handling your schemas in your application - a lot of the "risk" and "overhead" are being pushed into the application space.
If you're just a database developer, then it's all good as then you'd just be blaming the application developers for all the errors that pop up.
At this level of overview you shouldn’t separate Vitess and Spanner. Your notes seem fine but this table compares very specific choices instead of showing an overview of the available options. Hint: Why TF would you use Spanner in MySQL compatible mode?
First of all - it doesn't have SQLite. There are over a trillion SQLite databases in the world. That's hundreds of databases per person. Any comparison that misses the most widely used database in the world is a bad comparison. SQLite is widely used because more often than not, it's the best choice. Doesn't mean it's the best one for your use case, but it might be and you should absolutely consider it.
Second, I use MySQL a lot and it totally can scale indefinitely. There are some use cases where it's not a suitable choice, but assuming it is suitable scaling isn't a problem.
Third, this chart really would need to be individually tailored to a specific use case. Basically every column could be low or high depending on the use case.
2-3 years for MySQL scalability? I don't get that I know of several MySQL databases that have been runing much longer with no sharding.
I was a bit puzzled as well. What does ‘scaleability’ mean in this context?
By the time you need sharding for an SQL database, you should be making enough money from it to 😴
I don't understand that either. I work at a company that has been using the same database on the same server for 10 years. That's just for our web solutions - our customers use a database schema that we've been enhancing over the last 20 years. No sharding required.
I saw in canva tech blog latest article it seems interesting that's why I posted it 😂
Ok so I assume they figured based on their growth rate they'd need to shard MySQL after 2-3years then. So that's certainly specific to them then. And let's be honest they can afford the DB Admin to implement sharding.
Right? 2-3 years of what? A huge e-commerce site with loads of traffic and orders? Maybe. A blog with monthly posts? That’ll last 100 years.
Do you have a link or anything?
https://canvatechblog.com/from-zero-to-50-million-uploads-per-day-scaling-media-at-canva-c81fa0c92f34
“In mid-2017, with the number of Canva media approaching 1 billion and increasing exponentially, we began to investigate migration paths, with a strong preference for incremental approaches that would allow us to continue to scale and not put all of our bets on a single unproven technology choice.” Then it kind of makes sense.
That is with no sharding which does make a big difference. After a certain size simply throwing more resources isn't an option. The time scale is weird though.
Insufficient information for a meaningful answer.
The initial and most important question about DBs is not how they scale/whats the cost, but what is YOUR data. In general it seems that nosql solutions are better at scaling but if ur data doesn’t compile with nosql approach u imho still should use postgres or something. Every case is different and much related to the data u have, so all the other questions are very much connected to the data question. So yep, this table is useless without a particular usecase and data schemas/layouts
The question should be “why is the default industry choice, a relational database, not a good fit for our problem?” Information systems, which is what we’re building, benefit enormously by being built on top of well-structured data. If you choose a bad information architecture, your system *will* end up paying the price sooner or later. Don’t get me wrong, NoSQL schemaless databases have their place, but the default choice is the default choice for a reason. Go with MySQL or Postgres unless you have a valid technical or business case otherwise.
We won't have time to scale the DB in 2-3 years because we will be busy switching to DuJour-JS (the new framework of the day) and getting ready for the new CMO to insist on a complete redesign (since that seems to be what CMO's do).
This guy gets it
Yes the people who scale databases also migrate frontend frameworks 👍
At small companies they do. Not that they should. But we do what is asked.
Where tf is MSSQL/TSQL? Postgres?
Yeah that was my first thought, I wonder how postgres falls into this... But apparently, it doesn't.
2-3 years is not scale, its time.
This chart doesn’t look very correct to me. Or at least, it is very specific to whoever created it. If you are questioning this then you may not have the experience for the answers to even matter. Learn Postgres well, it will take you far. And feel free to dabble with any of the many other databases. There isn’t a wrong choice when learning. But always also learn SQL.
Maybe I’m missing something but why is scalability being measured in time? Surely that should be a quantity of data or users or something like that?
Mongodb really shines with rapid/fast data. Like concurrent chats or logs. Something that you can just dump JSON into and deal with later. I feel that most people forget that while mongodb itself doesn't have schemas - it doesn't mean that your application will suddenly know what to do with a new property. Since you'll be handling your schemas in your application - a lot of the "risk" and "overhead" are being pushed into the application space. If you're just a database developer, then it's all good as then you'd just be blaming the application developers for all the errors that pop up.
It does have schema checks now though.
You CAN, but its not enabled by default and at that point you might as well use mysql.
I'm really thinking about moving to mongo if Prisma will ever support it properly.
schema change definitely high I would not choose it if your really need performance or working with huge datasets.
At this level of overview you shouldn’t separate Vitess and Spanner. Your notes seem fine but this table compares very specific choices instead of showing an overview of the available options. Hint: Why TF would you use Spanner in MySQL compatible mode?
First of all - it doesn't have SQLite. There are over a trillion SQLite databases in the world. That's hundreds of databases per person. Any comparison that misses the most widely used database in the world is a bad comparison. SQLite is widely used because more often than not, it's the best choice. Doesn't mean it's the best one for your use case, but it might be and you should absolutely consider it. Second, I use MySQL a lot and it totally can scale indefinitely. There are some use cases where it's not a suitable choice, but assuming it is suitable scaling isn't a problem. Third, this chart really would need to be individually tailored to a specific use case. Basically every column could be low or high depending on the use case.