Growing up with MySQL: How we scaled our primary datastore
In this technical retrospective (2016), @andrewvijay shares practical architectural lessons learned from running, scaling, or migrating production software under lean constraints.
Core Principles for Independent Builders:
Defaulting to simpler architectures (such as monolithic frameworks, SQLite, or managed VPS) prevents early engineering bankruptcy.
Evaluating true compute and egress costs reveals that high cloud bills can often be slashed by 80%+ through judicious re-platforming.
Code you write at 2 AM as a solo engineer must be easy to debug six months later without complex microservice dependencies.
Community Debate Themes:
HN engineers debated the tradeoffs between cloud convenience and raw server economics, database indexing strategies, and resisting premature architectural complexity.
CATEGORY Frugal Engineering →
HISTORICAL ERA Cloud & Mobile Era (2014–2019)
COMMUNITY SCORE ★ 39 points
TOTAL DISCUSSIONS 8 comments
I love these kind of articles. But I think it's a bit weird that most devs choose to horizontally scale at the data persistence layer, instead of the application layer. And that they choose a SQL database to basically store just text blobs.
As this is a mail app, and users doesn't need to read each others private messages. I would put say 100 users per (virtual) server and also store the data there. And have a simple traffic router.
I am the author of ProxySQL, and I am very glad it helped a wonderful service like Nylas to easily scale the database infrastructure. I will be happy to answer any question on ProxySQL.
Pretty quiet here. :) Let us know if you have any questions or comments. This was a pretty big project and I think we're the largest deployment of ProxySQL right now!