Premature Optimization is Evil unless
As software developers, we are told many things as we begin our journey in this crazy and complex world of opinions and patterns. The one I always like hearing is premature optimization is the root of all evil. And this is true, especially for start-ups! A start-up needs to be fast, nimble, and scrappy. You should be iterating on your product continuously, looking at usage data, identifying patterns and trends, and solving customer problems. And for those saying, “but, what if we have a massive amount of people use our service right away, what if we have millions of customers overnight…”. Congrats! This is a good problem to have, this means you built something people want to use and while you may see or hear performance is not the best, the customers are using it you and you can begin to optimize.
I could end the post there, but I want to talk about something far more important — it is optimizing before you even begin to write your first line of code. Rather than getting lost in the debate of NoSQL vs SQL, or Document vs Relational vs Graph. Let’s focus again on what a start-up should be doing… shipping code and a product. I’ve seen many start-ups begin with NoSQL for their project to ultimately realize they didn’t actually understand how the data was going to be accessed and/or used. This causes your engineers to do a bunch of heavy lifting either in their service layer or on the client. Honestly, if you do not know your access patterns and how your data will be used, you should stick with RDBMS. I know there are valid use cases for document stores, graph databases, wide-column, etc., but you just said you don’t know what your access patterns are or what they will look like, you need the flexibility of an RDBMS and SQL. I will call this pre-optimization #1 and one you can thank me for later.
Now that we have determined our start-up should use an RDBMS, we can focus on shipping code and start capturing data on customer usage patterns. So which database do you use Postgres, MySQL, Spanner, Cockroach, Planetscale? It honestly doesn’t matter they will all do fine and all have their own strengths and weaknesses. But, as a former CIO/CTO of a $1B e-commerce start-up and having worked on a number of large complex applications for customers including professional sports leagues to large Fortune 500 companies, I can tell you I would pick Planetscale to start my new projects.
Planetscale really hit the DX out of the park. The non-block schema migrations, the database branching, and the underlying technology of Vitess — which was conceived by and powered Youtube, are simply amazing.
At the latest start-up I have been advising, we added Planetscale as the newest tool in their toolbox, enabling their team to continuously work on the product and ship it to the customers. If you have not had a chance, I highly recommend you take a look at Planetscale and take them up on their generous free tier. I call this pre-optimization #2 and again, you can thank me later. As for when to optimize the other areas of your project… Only you and your team will know, but the one thing you should not need to worry about is the ability of your database to scale.
