6 ms·
The problem is that you want to build something that can scale in the future.
by I_am_tiberius 6y ago
The problem is that you want to build something that can scale in the future.
- theshrike79 6y agoI think I've heard a saying about this, something about premature optimisation...
- I_am_tiberius 6y agoSure you shouldn't care about scaling at the beginning. But why should you start using a system that you already know won't scale in the future?
- oblio 6y ago> Sure you shouldn't care about scaling at the beginning. But why should you start using a system that you already know won't scale in the future? Because it's well supported and solid otherwise? There's a wealth of documentation, resources of many kinds, software built around it (debugging, tracing, UIs, etc.). Because there's a solid community available that can help you with your problems? What alternative technology is there that scales better? I guess MySQL could be it, but doesn't MySQL also come with a ton of its own footguns?
- I_am_tiberius 6y agoI use Postgres at the moment and I'm happy except for the process per connection part and the upgrade part. Knowing what I know now I think MySQL would have made me happier. On the other hand, it may have caused other issues I don't have with Postgres. I just hope the Postgres team maintains its roadmap based on posts like this.
- why_Mr_Anderson 6y agoBut you have to get to that future first! If you lose your customers because you can't deliver something on time due to complexity of your 'scaling-proof' system or because you can't accommodate changes requested by clients because they would compromise your architecture, scaling will be last of your worries.
- theshrike79 6y agoOnly if I _know_ I'm creating something that will definitely have huge amounts of concurrent users and someone pays me to make it scale from the start. For a hobby project that might take off or might not, there's really no point in making everything "webscale"[0] just in case. [0] https://youtu.be/b2F-DItXtZs https://youtu.be/b2F-DItXtZs
- WJW 6y agoBecause the hyperscalable databases are much more difficult to set up, use and administer. It's not a "free" upgrade, it'll slow down everything else you do.
- spaetzleesser 6y agoThere are a lot of dimensions to scaling. It's hard to predict where you really will have to scale up.
- o_p 6y agoIts better to work on getting all those users before planning what color the ferrari will be..
- I_am_tiberius 6y agoExactly. That's why it would be good to have a system which is prepared for scaling in the future.
- oblio 6y agoWhat's that system? MySQL? Are there any other OSS RDBMSes which are comparable and scale better?
- I_am_tiberius 6y agoI would only have thought of MySQL.
- doctor_eval 6y agoMySQL isn't a general solution to problems of scale, because you don't know what problems you're going to have until you have them. So for example if your scaling problem is ACID compliant database updates - say you're the next fintech - then I was under the impression that MySQL would be the last database you'd want to be using. Have I missed something?
- redis_mlc 6y agoThe default MySQL storage engine since 2010 has been Innodb, which is ACID-compliant. Overall, MySQL and Postgres are great Open Source databases, but MySQL has the edge for enterprise features (ie. replication options) and a simpler grant system. Source: DBA.
- I_am_tiberius 6y agoI'm no expert and can't answer that. It was just my impression, and I might be wrong, that for scaling purposes MySQL is better suited. Currently I'm working on a Saas product and the test instance that runs on Digital Ocean sometimes causes connection limit issues (with connection pool) sometimes. Sure my code is maybe not perfectly utilizing connections but I'm really afraid that this happens in production and I don't know how to fix it. On my test environment I just restart everything but on a productive environment I can't do that all the time.
- marcus_holmes 6y agoffs, this attitude causes massively more problems than it solves. 1. You can always change later. Uber switched from Postgres to MySQL when they had already achieved massive scale. 2. You don't know what scaling problems you're going to get until you've scaled. 3. Systems designed to scale properly sacrifice other abilities in order to do that. You're actively hurting your velocity with this attitude. 4. Every single expert in the field who has done this, says to start with a monolith and break it out into microservices as the product matures. Yet every startup is founding on K8s because "we'll need it when we hit scale so we might as well start with it" 5. Twitter's Fail Whale - the problems that failing to scale properly bring are less than the problems of not being flexible enough in the early stages. Build it simple, and adapt it as you go. Messing up your architecture and slowing down your development now to cope with a problem you don't have is crazy.
- I_am_tiberius 6y agoffs, this attitude causes massively more problems than it solves. I don't think that it causes so many problems to just use MySQL instead of Postgres from the very beginning of a project. I like using Postgres and I understand that I shouldn't care about scaling but if a make a good decision from the very beginning it can't hurt.
- doctor_eval 6y agoIs MySQL a general solution to scaling? What if your scaling problem is with writes?
- derekperkins 6y agoThat's why Vitess is so awesome - you can scale writes infinitely. There's not a truly comparable option for Postgres
- chrisandchris 6y agoI would rather use Postgres and have a RDBMS that is quite strict and migrate data later instead of having a RDBMS that just does what it likes sometimes. For example, query your table „picture“ with a first column „uuid“ (varchar) with the following query: SELECT * FROM picture WHERE uuid = 123; I don‘t know what you expect, I expect the query to fail because a number is not a string. MySQL thinks otherwise.