{"slug": "mysql", "name": "MySQL", "category": "databases", "category_name": "Databases", "description": "Widely used open-source relational database management system, now developed by Oracle.", "recommenders": 6, "commenters": 22, "warners": 3, "score": 6.527, "rising": 2.02, "first": "2025-12-09", "latest": "2026-10-24", "why": "Commenters like MySQL for being simpler to operate than Postgres, with no VACUUM or connection pooler needed, and for good performance on transactional workloads.", "why_is_quote": false, "has_verdict": true, "sentiment": {"recommend": 6, "neutral": 12, "compare": 2, "warn": 2}, "spark": [0, 0, 0, 0, 0, 0, 0, 1, 2, 2, 0, 1], "listed": true, "loved": ["Simplicity", "Performance"], "caveat": "Footguns", "short_quote": "for many simple needs MySQL is simpler than Postgres, with similar performance and consistency.", "icon": true, "domain": null, "github_repo": null, "official_url": "https://www.mysql.com/", "pricing": "open source", "aliases": ["MySQL"], "verdict": [{"text": "Commenters like MySQL for being simpler to operate than Postgres, with no VACUUM or connection pooler needed,", "cites": [{"id": 789790624, "item_id": 49361914, "url": "https://news.ycombinator.com/item?id=49361914", "by": "idoubtit", "date": "2026-08-19", "stance": "recommend", "quote": "for many simple needs MySQL is simpler than Postgres, with similar performance and consistency.", "excerpt": "Why write a fanboy text with unfair comparisons that hide the Postgres limitations? For instance, for many simple needs MySQL is simpler than Postgres, with similar performance and consistency. * No need for a connection pool, while many use cases with Postgres require PgBouncer and Co. * Easy sort (and basic search) of multilingual text, because MySQL has case insensitive UTF8 collations. * No need to VACUUM, which ", "context": "", "use_case": "simple web apps", "switched_from": "", "story": "PostgreSQL for Everything"}, {"id": 789788305, "item_id": 49361769, "url": "https://news.ycombinator.com/item?id=49361769", "by": "Ozzie_osman", "date": "2026-08-19", "stance": "compare", "quote": "MySQL was generally faster, and while MyISAM was a bit limited Innodb was pretty powerful", "excerpt": "I love postgres and use it heavily, but I still don't fully understand how it overlook MySQL. Maybe because of Heroku adopting it. MySQL was generally faster, and while MyISAM was a bit limited Innodb was pretty powerful, and you had the choice. It was also simpler (imo) and avoided a lot of the xid/vacuum issues. That said, still love Postgres. But at the time it started eclipsing MySQL, MySQL felt better positioned", "context": "", "use_case": "", "switched_from": "", "story": "PostgreSQL for Everything"}, {"id": 761724576, "item_id": 47607786, "url": "https://news.ycombinator.com/item?id=47607786", "by": "dzonga", "date": "2026-04-01", "stance": "compare", "quote": "MySQL for all its warts seems easier to run operationally and has a better scaling story(Vitess) than PostgreSQL.", "excerpt": "there now seems to be a split - with western companies tryna go all in on PostgreSQL while Eastern (Chinese) companies innovate on MysQL protocol. MySQL for all its warts seems easier to run operationally and has a better scaling story(Vitess) than PostgreSQL. even though I use PostgreSQL.", "context": "", "use_case": "", "switched_from": "", "story": "Google Cloud: Investing in the Future of PostgreSQL"}]}, {"text": " and for good performance on transactional workloads.", "cites": [{"id": 777741792, "item_id": 48608862, "url": "https://news.ycombinator.com/item?id=48608862", "by": "My_Name", "date": "2026-06-20", "stance": "recommend", "quote": "it is now fast enough to give me 20fps no matter the viewed range", "excerpt": "One of my projects was using a RRD database to store 10-second samples from 20 data streams with a RRD time of 1 year, which works out to around 82 million entries. I display this interactively on a raspberry pi and I used to use RRDTool in python, but switching to my own code leveraging mySQL (and using some judicious rollup tables) means that instead of a larger time span taking ~5 seconds to update, it is now fast", "context": "", "use_case": "time-series storage and display", "switched_from": "RRDtool", "story": "DuckDB Internals: Why Is DuckDB Fast? (Part 1)"}, {"id": 781442835, "item_id": 48840177, "url": "https://news.ycombinator.com/item?id=48840177", "by": "BajajScooter", "date": "2026-07-08", "stance": "recommend", "quote": "Traditional databases(mysql, postgres) are perfect for transactional data.", "excerpt": "Traditional databases(mysql, postgres) are perfect for transactional data. users, products, orders and the like. but they aren't made for tracking events which is typically huge volume. that's why we used clickhouse db here which scales to billions of events easily. We also have sdks that you can use in your app to publish the events to our services. You can also query these events on our app, create trends, funnels,", "context": "", "use_case": "transactional data", "switched_from": "", "story": "Show HN: Pug.sh \u2013 open-source product analytics"}, {"id": 789788305, "item_id": 49361769, "url": "https://news.ycombinator.com/item?id=49361769", "by": "Ozzie_osman", "date": "2026-08-19", "stance": "compare", "quote": "MySQL was generally faster, and while MyISAM was a bit limited Innodb was pretty powerful", "excerpt": "I love postgres and use it heavily, but I still don't fully understand how it overlook MySQL. Maybe because of Heroku adopting it. MySQL was generally faster, and while MyISAM was a bit limited Innodb was pretty powerful, and you had the choice. It was also simpler (imo) and avoided a lot of the xid/vacuum issues. That said, still love Postgres. But at the time it started eclipsing MySQL, MySQL felt better positioned", "context": "", "use_case": "", "switched_from": "", "story": "PostgreSQL for Everything"}]}, {"text": " The most common complaint is its quirks and footguns,", "cites": [{"id": 752159345, "item_id": 47009959, "url": "https://news.ycombinator.com/item?id=47009959", "by": "TexanFeller", "date": "2026-02-13", "stance": "warn", "quote": "Every time I've touched MySQL I've found a new footgun.", "excerpt": "One of the main reasons I use Postgres is I've rarely(never?) seen an article like this posted about it. Every time I've touched MySQL I've found a new footgun.", "context": "", "use_case": "", "switched_from": "", "story": "MySQL Foreign Key Cascade Operations Hit the Binary Log"}, {"id": 783828688, "item_id": 48989293, "url": "https://news.ycombinator.com/item?id=48989293", "by": "wolvoleo", "date": "2026-07-21", "stance": "recommend", "quote": "But it always worked well for me. Like I said I got used to its quirks.", "excerpt": "Yeah I know MySQL started out as the \"poor man's\" lightweight alternative to Postgres. But it always worked well for me. Like I said I got used to its quirks. I'm just surprised reading from this article that postgres has quirks too :)", "context": "", "use_case": "database", "switched_from": "", "story": "Why It's So Hard to Add a Column in the Middle of a PostgreSQL Table"}, {"id": 761724576, "item_id": 47607786, "url": "https://news.ycombinator.com/item?id=47607786", "by": "dzonga", "date": "2026-04-01", "stance": "compare", "quote": "MySQL for all its warts seems easier to run operationally and has a better scaling story(Vitess) than PostgreSQL.", "excerpt": "there now seems to be a split - with western companies tryna go all in on PostgreSQL while Eastern (Chinese) companies innovate on MysQL protocol. MySQL for all its warts seems easier to run operationally and has a better scaling story(Vitess) than PostgreSQL. even though I use PostgreSQL.", "context": "", "use_case": "", "switched_from": "", "story": "Google Cloud: Investing in the Future of PostgreSQL"}]}, {"text": " including a query planner one production user says still needs index hints.", "cites": [{"id": 783971696, "item_id": 48998231, "url": "https://news.ycombinator.com/item?id=48998231", "by": "zinodaur", "date": "2026-07-21", "stance": "warn", "quote": "we use the index hints 100% of the time because the query planner (still) doesn't work", "excerpt": "> The query planners have diverged between MySQL and MariaDB; which one are you talking about? Both have received improvements in recent years, so the specific version is relevant as well. And at least both systems have supported index hints MySQL - we use the index hints 100% of the time because the query planner (still) doesn't work > The real-world relevance is minor, especially since companies using external writ", "context": "runs MySQL in production", "use_case": "production database", "switched_from": "", "story": "Lobste.rs is now running on SQLite"}]}], "praise": [{"label": "Simplicity", "summary": "Seen as simpler than Postgres for many needs and easier to run operationally.", "quotes": [{"id": 789790624, "item_id": 49361914, "url": "https://news.ycombinator.com/item?id=49361914", "by": "idoubtit", "date": "2026-08-19", "stance": "recommend", "quote": "for many simple needs MySQL is simpler than Postgres, with similar performance and consistency.", "excerpt": "Why write a fanboy text with unfair comparisons that hide the Postgres limitations? For instance, for many simple needs MySQL is simpler than Postgres, with similar performance and consistency. * No need for a connection pool, while many use cases with Postgres require PgBouncer and Co. * Easy sort (and basic search) of multilingual text, because MySQL has case insensitive UTF8 collations. * No need to VACUUM, which ", "context": "", "use_case": "simple web apps", "switched_from": "", "story": "PostgreSQL for Everything"}, {"id": 789788305, "item_id": 49361769, "url": "https://news.ycombinator.com/item?id=49361769", "by": "Ozzie_osman", "date": "2026-08-19", "stance": "compare", "quote": "MySQL was generally faster, and while MyISAM was a bit limited Innodb was pretty powerful", "excerpt": "I love postgres and use it heavily, but I still don't fully understand how it overlook MySQL. Maybe because of Heroku adopting it. MySQL was generally faster, and while MyISAM was a bit limited Innodb was pretty powerful, and you had the choice. It was also simpler (imo) and avoided a lot of the xid/vacuum issues. That said, still love Postgres. But at the time it started eclipsing MySQL, MySQL felt better positioned", "context": "", "use_case": "", "switched_from": "", "story": "PostgreSQL for Everything"}, {"id": 761724576, "item_id": 47607786, "url": "https://news.ycombinator.com/item?id=47607786", "by": "dzonga", "date": "2026-04-01", "stance": "compare", "quote": "MySQL for all its warts seems easier to run operationally and has a better scaling story(Vitess) than PostgreSQL.", "excerpt": "there now seems to be a split - with western companies tryna go all in on PostgreSQL while Eastern (Chinese) companies innovate on MysQL protocol. MySQL for all its warts seems easier to run operationally and has a better scaling story(Vitess) than PostgreSQL. even though I use PostgreSQL.", "context": "", "use_case": "", "switched_from": "", "story": "Google Cloud: Investing in the Future of PostgreSQL"}]}, {"label": "Performance", "summary": "Described as fast, with one user getting 20fps over 82 million rows using rollup tables.", "quotes": [{"id": 777741792, "item_id": 48608862, "url": "https://news.ycombinator.com/item?id=48608862", "by": "My_Name", "date": "2026-06-20", "stance": "recommend", "quote": "it is now fast enough to give me 20fps no matter the viewed range", "excerpt": "One of my projects was using a RRD database to store 10-second samples from 20 data streams with a RRD time of 1 year, which works out to around 82 million entries. I display this interactively on a raspberry pi and I used to use RRDTool in python, but switching to my own code leveraging mySQL (and using some judicious rollup tables) means that instead of a larger time span taking ~5 seconds to update, it is now fast", "context": "", "use_case": "time-series storage and display", "switched_from": "RRDtool", "story": "DuckDB Internals: Why Is DuckDB Fast? (Part 1)"}, {"id": 789788305, "item_id": 49361769, "url": "https://news.ycombinator.com/item?id=49361769", "by": "Ozzie_osman", "date": "2026-08-19", "stance": "compare", "quote": "MySQL was generally faster, and while MyISAM was a bit limited Innodb was pretty powerful", "excerpt": "I love postgres and use it heavily, but I still don't fully understand how it overlook MySQL. Maybe because of Heroku adopting it. MySQL was generally faster, and while MyISAM was a bit limited Innodb was pretty powerful, and you had the choice. It was also simpler (imo) and avoided a lot of the xid/vacuum issues. That said, still love Postgres. But at the time it started eclipsing MySQL, MySQL felt better positioned", "context": "", "use_case": "", "switched_from": "", "story": "PostgreSQL for Everything"}, {"id": 789790624, "item_id": 49361914, "url": "https://news.ycombinator.com/item?id=49361914", "by": "idoubtit", "date": "2026-08-19", "stance": "recommend", "quote": "for many simple needs MySQL is simpler than Postgres, with similar performance and consistency.", "excerpt": "Why write a fanboy text with unfair comparisons that hide the Postgres limitations? For instance, for many simple needs MySQL is simpler than Postgres, with similar performance and consistency. * No need for a connection pool, while many use cases with Postgres require PgBouncer and Co. * Easy sort (and basic search) of multilingual text, because MySQL has case insensitive UTF8 collations. * No need to VACUUM, which ", "context": "", "use_case": "simple web apps", "switched_from": "", "story": "PostgreSQL for Everything"}]}, {"label": "No VACUUM", "summary": "Avoids Postgres-style VACUUM and xid issues and often needs no connection pooler.", "quotes": [{"id": 789790624, "item_id": 49361914, "url": "https://news.ycombinator.com/item?id=49361914", "by": "idoubtit", "date": "2026-08-19", "stance": "recommend", "quote": "for many simple needs MySQL is simpler than Postgres, with similar performance and consistency.", "excerpt": "Why write a fanboy text with unfair comparisons that hide the Postgres limitations? For instance, for many simple needs MySQL is simpler than Postgres, with similar performance and consistency. * No need for a connection pool, while many use cases with Postgres require PgBouncer and Co. * Easy sort (and basic search) of multilingual text, because MySQL has case insensitive UTF8 collations. * No need to VACUUM, which ", "context": "", "use_case": "simple web apps", "switched_from": "", "story": "PostgreSQL for Everything"}, {"id": 789788305, "item_id": 49361769, "url": "https://news.ycombinator.com/item?id=49361769", "by": "Ozzie_osman", "date": "2026-08-19", "stance": "compare", "quote": "MySQL was generally faster, and while MyISAM was a bit limited Innodb was pretty powerful", "excerpt": "I love postgres and use it heavily, but I still don't fully understand how it overlook MySQL. Maybe because of Heroku adopting it. MySQL was generally faster, and while MyISAM was a bit limited Innodb was pretty powerful, and you had the choice. It was also simpler (imo) and avoided a lot of the xid/vacuum issues. That said, still love Postgres. But at the time it started eclipsing MySQL, MySQL felt better positioned", "context": "", "use_case": "", "switched_from": "", "story": "PostgreSQL for Everything"}]}, {"label": "Scaling story", "summary": "Credited with a better scaling story than PostgreSQL through Vitess.", "quotes": [{"id": 761724576, "item_id": 47607786, "url": "https://news.ycombinator.com/item?id=47607786", "by": "dzonga", "date": "2026-04-01", "stance": "compare", "quote": "MySQL for all its warts seems easier to run operationally and has a better scaling story(Vitess) than PostgreSQL.", "excerpt": "there now seems to be a split - with western companies tryna go all in on PostgreSQL while Eastern (Chinese) companies innovate on MysQL protocol. MySQL for all its warts seems easier to run operationally and has a better scaling story(Vitess) than PostgreSQL. even though I use PostgreSQL.", "context": "", "use_case": "", "switched_from": "", "story": "Google Cloud: Investing in the Future of PostgreSQL"}, {"id": 794350193, "item_id": 49646887, "url": "https://news.ycombinator.com/item?id=49646887", "by": "erulabs", "date": "2026-09-10", "stance": "neutral", "quote": "as a heavy Vitess/MySQL user", "excerpt": "I love to see this but as a heavy Vitess/MySQL user I do fear the split focus from PlanetScale. Hoping to see continued improvements on the Vitess side as well. Selfish doubts aside, congrats to Planetscale on the launch!", "context": "heavy Vitess/MySQL user", "use_case": "", "switched_from": "", "story": "Neki \u2013 Sharded Postgres"}]}, {"label": "Transactional data", "summary": "Called a good fit for users, products, orders and similar transactional data.", "quotes": [{"id": 781442835, "item_id": 48840177, "url": "https://news.ycombinator.com/item?id=48840177", "by": "BajajScooter", "date": "2026-07-08", "stance": "recommend", "quote": "Traditional databases(mysql, postgres) are perfect for transactional data.", "excerpt": "Traditional databases(mysql, postgres) are perfect for transactional data. users, products, orders and the like. but they aren't made for tracking events which is typically huge volume. that's why we used clickhouse db here which scales to billions of events easily. We also have sdks that you can use in your app to publish the events to our services. You can also query these events on our app, create trends, funnels,", "context": "", "use_case": "transactional data", "switched_from": "", "story": "Show HN: Pug.sh \u2013 open-source product analytics"}, {"id": 783828688, "item_id": 48989293, "url": "https://news.ycombinator.com/item?id=48989293", "by": "wolvoleo", "date": "2026-07-21", "stance": "recommend", "quote": "But it always worked well for me. Like I said I got used to its quirks.", "excerpt": "Yeah I know MySQL started out as the \"poor man's\" lightweight alternative to Postgres. But it always worked well for me. Like I said I got used to its quirks. I'm just surprised reading from this article that postgres has quirks too :)", "context": "", "use_case": "database", "switched_from": "", "story": "Why It's So Hard to Add a Column in the Middle of a PostgreSQL Table"}]}, {"label": "Postgres alternative", "summary": "Mentioned as a destination when moving off Postgres or Oracle.", "quotes": [{"id": 800030992, "item_id": 50001937, "url": "https://news.ycombinator.com/item?id=50001937", "by": "deepsun", "date": "2026-10-08", "stance": "recommend", "quote": "Why Uber Engineering Switched from Postgres to MySQL", "excerpt": "\"Why Uber Engineering Switched from Postgres to MySQL\" https://www.uber.com/us/en/blog/postgres-to-mysql-migration/", "context": "", "use_case": "", "switched_from": "PostgreSQL", "story": "A new write and space optimized storage engine for MySQL is here"}, {"id": 739242050, "item_id": 46202628, "url": "https://news.ycombinator.com/item?id=46202628", "by": "ManBeardPc", "date": "2025-12-09", "stance": "neutral", "quote": "everyone who could switched to alternatives like MySQL or Postgres.", "excerpt": "My next company\u2018s boss was pretty much Windows only (server and desktops/laptops, some Linux servers). Linux on the server was already replacing more and more machines. Now I am even allowed to use MacBooks or Linux laptops. Current company is already using the Google suite, MS Office was an exception if required for some reason. I saw the same shift with Oracle. Previously nearly everyone wanted Oracle as a DB, then", "context": "", "use_case": "database", "switched_from": "Oracle Database", "story": "Microsoft increases Office 365 and Microsoft 365 license prices"}]}], "caveats": [{"label": "Footguns", "summary": "Users report quirks, warts and repeated footguns.", "quotes": [{"id": 752159345, "item_id": 47009959, "url": "https://news.ycombinator.com/item?id=47009959", "by": "TexanFeller", "date": "2026-02-13", "stance": "warn", "quote": "Every time I've touched MySQL I've found a new footgun.", "excerpt": "One of the main reasons I use Postgres is I've rarely(never?) seen an article like this posted about it. Every time I've touched MySQL I've found a new footgun.", "context": "", "use_case": "", "switched_from": "", "story": "MySQL Foreign Key Cascade Operations Hit the Binary Log"}, {"id": 783828688, "item_id": 48989293, "url": "https://news.ycombinator.com/item?id=48989293", "by": "wolvoleo", "date": "2026-07-21", "stance": "recommend", "quote": "But it always worked well for me. Like I said I got used to its quirks.", "excerpt": "Yeah I know MySQL started out as the \"poor man's\" lightweight alternative to Postgres. But it always worked well for me. Like I said I got used to its quirks. I'm just surprised reading from this article that postgres has quirks too :)", "context": "", "use_case": "database", "switched_from": "", "story": "Why It's So Hard to Add a Column in the Middle of a PostgreSQL Table"}, {"id": 761724576, "item_id": 47607786, "url": "https://news.ycombinator.com/item?id=47607786", "by": "dzonga", "date": "2026-04-01", "stance": "compare", "quote": "MySQL for all its warts seems easier to run operationally and has a better scaling story(Vitess) than PostgreSQL.", "excerpt": "there now seems to be a split - with western companies tryna go all in on PostgreSQL while Eastern (Chinese) companies innovate on MysQL protocol. MySQL for all its warts seems easier to run operationally and has a better scaling story(Vitess) than PostgreSQL. even though I use PostgreSQL.", "context": "", "use_case": "", "switched_from": "", "story": "Google Cloud: Investing in the Future of PostgreSQL"}]}, {"label": "Query planner", "summary": "One production user relies on index hints because the query planner still does not work for them.", "quotes": [{"id": 783971696, "item_id": 48998231, "url": "https://news.ycombinator.com/item?id=48998231", "by": "zinodaur", "date": "2026-07-21", "stance": "warn", "quote": "we use the index hints 100% of the time because the query planner (still) doesn't work", "excerpt": "> The query planners have diverged between MySQL and MariaDB; which one are you talking about? Both have received improvements in recent years, so the specific version is relevant as well. And at least both systems have supported index hints MySQL - we use the index hints 100% of the time because the query planner (still) doesn't work > The real-world relevance is minor, especially since companies using external writ", "context": "runs MySQL in production", "use_case": "production database", "switched_from": "", "story": "Lobste.rs is now running on SQLite"}]}, {"label": "Event data", "summary": "Not designed for tracking high-volume event data.", "quotes": [{"id": 781442835, "item_id": 48840177, "url": "https://news.ycombinator.com/item?id=48840177", "by": "BajajScooter", "date": "2026-07-08", "stance": "recommend", "quote": "Traditional databases(mysql, postgres) are perfect for transactional data.", "excerpt": "Traditional databases(mysql, postgres) are perfect for transactional data. users, products, orders and the like. but they aren't made for tracking events which is typically huge volume. that's why we used clickhouse db here which scales to billions of events easily. We also have sdks that you can use in your app to publish the events to our services. You can also query these events on our app, create trends, funnels,", "context": "", "use_case": "transactional data", "switched_from": "", "story": "Show HN: Pug.sh \u2013 open-source product analytics"}]}], "who": [{"by": "erulabs", "context": "heavy Vitess/MySQL user", "url": "https://news.ycombinator.com/item?id=49646887", "date": "2026-09-10"}, {"by": "f3b5", "context": "data-intensive startup founder", "url": "https://news.ycombinator.com/item?id=48946143", "date": "2026-07-17"}, {"by": "eltados", "context": "solo developer", "url": "https://news.ycombinator.com/item?id=48030129", "date": "2026-05-05"}, {"by": "bhouston", "context": "worked at Threekit", "url": "https://news.ycombinator.com/item?id=47861726", "date": "2026-04-22"}], "tags": ["for transactional data", "scales with Vitess", "for PHP apps", "for solo devs"], "use_cases": ["production database", "database", "block id allocation", "storing boolean flags", "work database crud apps", "simple web apps"], "compared": [{"slug": "postgresql", "name": "PostgreSQL", "co": 18, "switched_from": 1, "switched_to": 0}, {"slug": "sqlite", "name": "SQLite", "co": 4, "switched_from": 1, "switched_to": 0}, {"slug": "rrdtool", "name": "rrdtool", "co": 1, "switched_from": 1, "switched_to": 0}, {"slug": "duckdb", "name": "DuckDB", "co": 2, "switched_from": 0, "switched_to": 0}], "makers": [], "threads": [{"url": "https://news.ycombinator.com/item?id=49361279", "title": "PostgreSQL for Everything", "mentions": 2}, {"url": "https://news.ycombinator.com/item?id=48553388", "title": "DuckDB Internals: Why Is DuckDB Fast? (Part 1)", "mentions": 2}, {"url": "https://news.ycombinator.com/item?id=50211746", "title": "UUIDv7: Timestamps aren\u2019t time-ordered and other oddities", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=49963568", "title": "A new write and space optimized storage engine for MySQL is here", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=49854875", "title": "How to keep enjoying programming in a world of LLMs", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=49673689", "title": "Compressing a flag to 11 bits", "mentions": 1}], "sentiment_by_month": {"2025-11": {}, "2025-12": {"neutral": 1}, "2026-01": {}, "2026-02": {"warn": 1, "neutral": 1}, "2026-03": {}, "2026-04": {"compare": 1, "neutral": 1}, "2026-05": {"neutral": 1}, "2026-06": {"neutral": 2, "recommend": 1}, "2026-07": {"recommend": 2, "neutral": 1, "warn": 1}, "2026-08": {"recommend": 2, "compare": 1, "neutral": 1}, "2026-09": {"neutral": 3}, "2026-10": {"recommend": 1, "neutral": 1}}, "quotes": [{"id": 803580640, "item_id": 50223790, "url": "https://news.ycombinator.com/item?id=50223790", "by": "rplnt", "date": "2026-10-24", "stance": "neutral", "quote": "I use this pattern in mysql.", "excerpt": "I use this pattern in mysql. One row, and one update query gets you a block of IDs. Don't want to attempt to write it out here without looking, but the trick is using the last insert id in the query (and on the result). It's one query, so shouldn't require a plugin I hope.", "context": "", "use_case": "block ID allocation", "switched_from": "", "story": "UUIDv7: Timestamps aren\u2019t time-ordered and other oddities"}, {"id": 800030992, "item_id": 50001937, "url": "https://news.ycombinator.com/item?id=50001937", "by": "deepsun", "date": "2026-10-08", "stance": "recommend", "quote": "Why Uber Engineering Switched from Postgres to MySQL", "excerpt": "\"Why Uber Engineering Switched from Postgres to MySQL\" https://www.uber.com/us/en/blog/postgres-to-mysql-migration/", "context": "", "use_case": "", "switched_from": "PostgreSQL", "story": "A new write and space optimized storage engine for MySQL is here"}, {"id": 797679811, "item_id": 49854988, "url": "https://news.ycombinator.com/item?id=49854988", "by": "superjose", "date": "2026-09-26", "stance": "neutral", "quote": "reads one of the MySQL replicas", "excerpt": "One thing I've been doing is to use it for: 1. Compare the code against production data with MCP. We use a read only platform called Metabase which reads one of the MySQL replicas. I tell the agent to fetch production data and make a static pass (it doesn't run the code) in which it compares shapes and inputs, and oh boy it has caught a few misnomers. 2. To debug production data and create graphs. It connects to data", "context": "", "use_case": "production database", "switched_from": "", "story": "How to keep enjoying programming in a world of LLMs"}, {"id": 795292432, "item_id": 49705777, "url": "https://news.ycombinator.com/item?id=49705777", "by": "xp84", "date": "2026-09-14", "stance": "neutral", "quote": "we used to use TINYINT in MySQL to store boolean flags", "excerpt": "Slightly reminds me of how we used to use TINYINT in MySQL to store boolean flags (which can store a range from -128 to 127 or 0-255 if unsigned). I'm the kind of nerd who secretly wished to store many such bools in one integer and use the bitwise operators to query them, but restrained myself from ever doing this, since if I managed to sneak that through code review, the number of curses of my name would no doubt be", "context": "", "use_case": "storing boolean flags", "switched_from": "", "story": "Compressing a flag to 11 bits"}, {"id": 794350193, "item_id": 49646887, "url": "https://news.ycombinator.com/item?id=49646887", "by": "erulabs", "date": "2026-09-10", "stance": "neutral", "quote": "as a heavy Vitess/MySQL user", "excerpt": "I love to see this but as a heavy Vitess/MySQL user I do fear the split focus from PlanetScale. Hoping to see continued improvements on the Vitess side as well. Selfish doubts aside, congrats to Planetscale on the launch!", "context": "heavy Vitess/MySQL user", "use_case": "", "switched_from": "", "story": "Neki \u2013 Sharded Postgres"}, {"id": 791785520, "item_id": 49486595, "url": "https://news.ycombinator.com/item?id=49486595", "by": "havaloc", "date": "2026-08-29", "stance": "neutral", "quote": "I used to write all my work apps in plain jane PHP/MySQL", "excerpt": "It's day job tasks/database CRUD, so I tell the LLM what I need. I used to write all my work apps in plain jane PHP/MySQL and I use that as a guide for the LLM, as in use this app as a guide on how I want things. The bonus of using plain PHP/MySQL/PDO is that the apps are small, so no issues with context windows or using complex frameworks.", "context": "", "use_case": "work database CRUD apps", "switched_from": "", "story": "Htmx 4.0"}, {"id": 789790624, "item_id": 49361914, "url": "https://news.ycombinator.com/item?id=49361914", "by": "idoubtit", "date": "2026-08-19", "stance": "recommend", "quote": "for many simple needs MySQL is simpler than Postgres, with similar performance and consistency.", "excerpt": "Why write a fanboy text with unfair comparisons that hide the Postgres limitations? For instance, for many simple needs MySQL is simpler than Postgres, with similar performance and consistency. * No need for a connection pool, while many use cases with Postgres require PgBouncer and Co. * Easy sort (and basic search) of multilingual text, because MySQL has case insensitive UTF8 collations. * No need to VACUUM, which ", "context": "", "use_case": "simple web apps", "switched_from": "", "story": "PostgreSQL for Everything"}, {"id": 789788305, "item_id": 49361769, "url": "https://news.ycombinator.com/item?id=49361769", "by": "Ozzie_osman", "date": "2026-08-19", "stance": "compare", "quote": "MySQL was generally faster, and while MyISAM was a bit limited Innodb was pretty powerful", "excerpt": "I love postgres and use it heavily, but I still don't fully understand how it overlook MySQL. Maybe because of Heroku adopting it. MySQL was generally faster, and while MyISAM was a bit limited Innodb was pretty powerful, and you had the choice. It was also simpler (imo) and avoided a lot of the xid/vacuum issues. That said, still love Postgres. But at the time it started eclipsing MySQL, MySQL felt better positioned", "context": "", "use_case": "", "switched_from": "", "story": "PostgreSQL for Everything"}, {"id": 789772274, "item_id": 49360767, "url": "https://news.ycombinator.com/item?id=49360767", "by": "generalkroll", "date": "2026-08-19", "stance": "recommend", "quote": "I have had hours of fun with postgres and mysql in particular.", "excerpt": "Looks to be something like a 3-tier app plus cache... nice. And the chosen tech stack are industry mainstays, so your time will not be wasted. I see some good points already commented, I will try not to be too repetitive. Keep things as simple and lean as possible to begin with, then add complexity when needed. Not before. Claude and other LLMs are great for content generation and are to be embraced but not trusted. ", "context": "", "use_case": "studying codebases", "switched_from": "", "story": "Ask HN: Can I realistically make an app as a junior dev?"}, {"id": 783971696, "item_id": 48998231, "url": "https://news.ycombinator.com/item?id=48998231", "by": "zinodaur", "date": "2026-07-21", "stance": "warn", "quote": "we use the index hints 100% of the time because the query planner (still) doesn't work", "excerpt": "> The query planners have diverged between MySQL and MariaDB; which one are you talking about? Both have received improvements in recent years, so the specific version is relevant as well. And at least both systems have supported index hints MySQL - we use the index hints 100% of the time because the query planner (still) doesn't work > The real-world relevance is minor, especially since companies using external writ", "context": "runs MySQL in production", "use_case": "production database", "switched_from": "", "story": "Lobste.rs is now running on SQLite"}, {"id": 783828688, "item_id": 48989293, "url": "https://news.ycombinator.com/item?id=48989293", "by": "wolvoleo", "date": "2026-07-21", "stance": "recommend", "quote": "But it always worked well for me. Like I said I got used to its quirks.", "excerpt": "Yeah I know MySQL started out as the \"poor man's\" lightweight alternative to Postgres. But it always worked well for me. Like I said I got used to its quirks. I'm just surprised reading from this article that postgres has quirks too :)", "context": "", "use_case": "database", "switched_from": "", "story": "Why It's So Hard to Add a Column in the Middle of a PostgreSQL Table"}, {"id": 783138289, "item_id": 48946143, "url": "https://news.ycombinator.com/item?id=48946143", "by": "f3b5", "date": "2026-07-17", "stance": "neutral", "quote": "So I had to migrate the production db under live load from sqlite to mysql", "excerpt": "I was such a big sqlite fan that I used it for my data-intensive startup. Once I actually started scaling it up I ran into crippling file system race conditions. This was because we were hosted on a distributed file system in the cloud which I learned is very very bad for sqlite. So I had to migrate the production db under live load from sqlite to mysql which was a quite ...intense week. I still like sqlite but I'd b", "context": "data-intensive startup founder", "use_case": "production database", "switched_from": "SQLite", "story": "SQLite Is All You Need"}, {"id": 781442835, "item_id": 48840177, "url": "https://news.ycombinator.com/item?id=48840177", "by": "BajajScooter", "date": "2026-07-08", "stance": "recommend", "quote": "Traditional databases(mysql, postgres) are perfect for transactional data.", "excerpt": "Traditional databases(mysql, postgres) are perfect for transactional data. users, products, orders and the like. but they aren't made for tracking events which is typically huge volume. that's why we used clickhouse db here which scales to billions of events easily. We also have sdks that you can use in your app to publish the events to our services. You can also query these events on our app, create trends, funnels,", "context": "", "use_case": "transactional data", "switched_from": "", "story": "Show HN: Pug.sh \u2013 open-source product analytics"}, {"id": 778996881, "item_id": 48687305, "url": "https://news.ycombinator.com/item?id=48687305", "by": "nobleach", "date": "2026-06-26", "stance": "neutral", "quote": "a full rewrite with MySQL + Perl DBI was what we chose", "excerpt": "It's been long enough that I have nothing but rose-colored affinity for the dBase III, FoxPro and CA Clipper apps that I used to work on. In the early days, my company looked at Harbour (https://harbour.github.io/) as a \"quick way\" to get some of our account payable systems onto the web back in the late 90s. In the end, a full rewrite with MySQL + Perl DBI was what we chose. I remember that being far more painful. I ", "context": "", "use_case": "rewriting accounting system", "switched_from": "", "story": "Show HN: WebBase-III \u2013 dBASE III rebuilt in the browser with its own interpreter"}, {"id": 777741792, "item_id": 48608862, "url": "https://news.ycombinator.com/item?id=48608862", "by": "My_Name", "date": "2026-06-20", "stance": "recommend", "quote": "it is now fast enough to give me 20fps no matter the viewed range", "excerpt": "One of my projects was using a RRD database to store 10-second samples from 20 data streams with a RRD time of 1 year, which works out to around 82 million entries. I display this interactively on a raspberry pi and I used to use RRDTool in python, but switching to my own code leveraging mySQL (and using some judicious rollup tables) means that instead of a larger time span taking ~5 seconds to update, it is now fast", "context": "", "use_case": "time-series storage and display", "switched_from": "RRDtool", "story": "DuckDB Internals: Why Is DuckDB Fast? (Part 1)"}, {"id": 777520049, "item_id": 48595003, "url": "https://news.ycombinator.com/item?id=48595003", "by": "jdw64", "date": "2026-06-18", "stance": "neutral", "quote": "I mainly use MySQL or PostgreSQL.", "excerpt": "The data scientists I work with use this. Why do they use it? I don't really know much about it, but I've noticed they use it quite often. I mainly use MySQL or PostgreSQL. What are the advantages of DuckDB? It seems like they usually use it as an alternative to Pandas.", "context": "", "use_case": "", "switched_from": "", "story": "DuckDB Internals: Why Is DuckDB Fast? (Part 1)"}, {"id": 768482066, "item_id": 48030129, "url": "https://news.ycombinator.com/item?id=48030129", "by": "eltados", "date": "2026-05-05", "stance": "neutral", "quote": "The site has been built with some pretty unremarkable tech stack Java / Spring / Mysql / HTMX", "excerpt": "I've been working on Izeria for a few months now and I'm looking for some feedback. I built it because I wanted to go beyond the same popular spots and want to discover and and reconnect with my local area I've been testing it around my home in Edinburgh and it's been fun to go for a walk or cycle and discover local historical spots and hidden gems I never knew existed. I am a solo developer and I'm planning to take ", "context": "solo developer", "use_case": "database for Izeria", "switched_from": "", "story": "Izeria.com a website/app to discover spots and gamify visiting your local area"}, {"id": 766936592, "item_id": 47933537, "url": "https://news.ycombinator.com/item?id=47933537", "by": "dzonga", "date": "2026-04-28", "stance": "warn", "quote": "blame MySQL", "excerpt": "blame MySQL. Blame Ruby. on another note - is the exponential growth from 'agentic' workflows actually resulting in productive software in the wild. Or it is just noise. On my end I haven't seen the software I use getting better.", "context": "", "use_case": "", "switched_from": "", "story": "An Update on GitHub Availability"}, {"id": 765787617, "item_id": 47861726, "url": "https://news.ycombinator.com/item?id=47861726", "by": "bhouston", "date": "2026-04-22", "stance": "neutral", "quote": "we had to use MySQL for our primary copy", "excerpt": "It was https://threekit.com. It was a while ago now but we had to use MySQL for our primary copy that users used (e.g. prod), and only when they were working on branches did we use dolt. I think the second complication was that Dolt was not stable enough to use in heavy load scenarios as well. I can delete this comment if you do not want to discuss this publicly.", "context": "worked at Threekit", "use_case": "primary production database", "switched_from": "", "story": "What if database branching was easy?"}, {"id": 761724576, "item_id": 47607786, "url": "https://news.ycombinator.com/item?id=47607786", "by": "dzonga", "date": "2026-04-01", "stance": "compare", "quote": "MySQL for all its warts seems easier to run operationally and has a better scaling story(Vitess) than PostgreSQL.", "excerpt": "there now seems to be a split - with western companies tryna go all in on PostgreSQL while Eastern (Chinese) companies innovate on MysQL protocol. MySQL for all its warts seems easier to run operationally and has a better scaling story(Vitess) than PostgreSQL. even though I use PostgreSQL.", "context": "", "use_case": "", "switched_from": "", "story": "Google Cloud: Investing in the Future of PostgreSQL"}, {"id": 754328049, "item_id": 47145503, "url": "https://news.ycombinator.com/item?id=47145503", "by": "thegrey_one", "date": "2026-02-24", "stance": "neutral", "quote": "Connects to local mysql server, pulls the values and then assembles it.", "excerpt": "I took an even simpler route. After jailbreak and ssh I just made two scripts on the Kindle, one is triggered every minute, the other every half hour. Both draw the same image from the same location, the 30 minute one just adds a full refresh. This way the display is not fully refreshed every minute, but in time image is degrading so full refresh once every 30 minutes seems work out fine. This way Kindle has a very s", "context": "", "use_case": "storing air quality data", "switched_from": "", "story": "Hacking an old Kindle to display bus arrival times"}, {"id": 752159345, "item_id": 47009959, "url": "https://news.ycombinator.com/item?id=47009959", "by": "TexanFeller", "date": "2026-02-13", "stance": "warn", "quote": "Every time I've touched MySQL I've found a new footgun.", "excerpt": "One of the main reasons I use Postgres is I've rarely(never?) seen an article like this posted about it. Every time I've touched MySQL I've found a new footgun.", "context": "", "use_case": "", "switched_from": "", "story": "MySQL Foreign Key Cascade Operations Hit the Binary Log"}, {"id": 739242050, "item_id": 46202628, "url": "https://news.ycombinator.com/item?id=46202628", "by": "ManBeardPc", "date": "2025-12-09", "stance": "neutral", "quote": "everyone who could switched to alternatives like MySQL or Postgres.", "excerpt": "My next company\u2018s boss was pretty much Windows only (server and desktops/laptops, some Linux servers). Linux on the server was already replacing more and more machines. Now I am even allowed to use MacBooks or Linux laptops. Current company is already using the Google suite, MS Office was an exception if required for some reason. I saw the same shift with Oracle. Previously nearly everyone wanted Oracle as a DB, then", "context": "", "use_case": "database", "switched_from": "Oracle Database", "story": "Microsoft increases Office 365 and Microsoft 365 license prices"}]}