To each his own, but that would just about answer the question for me.
Ask HN: PostgreSQL or MySQL?
121–130 of 181 posts
Re: Ask HN: PostgreSQL or MySQL?
#122Earlier quoted context omitted.
Did you mean replication rather than partitioning perhaps? I've found MySQL replication quite easy to use, whereas PostgreSQL has been rather clunkier in my experience. However, I've had the exact opposite experience with respect to partitioning.
MySQL partitioning shines with one specific use-case: time-based data retention. e.g., by using RANGE partitioning over a temporal value, you can very efficiently drop large amounts of old data when no longer needed, and can automate this fairly easily. For anything else, MySQL partitioning rule-of-thumb is you'll have a bad time, mainly for performance reasons.
Re: Ask HN: PostgreSQL or MySQL?
#123This entirely depends on the domain and data model, and unless you need SQL - mongodb should be a consideration too.
No. MongoDB has a track record of losing data and not actually providing durability. It is considered a joke in the professional community.
They are database veterans. Wiredtiger is really nicely written.
Re: Ask HN: PostgreSQL or MySQL?
#124Is there a Galera-equivalent system available of Postgres? I.e., multi-master replication. I know of BDR, but that doesn't seem to be publicly available for recent versions of Pg?
Re: Ask HN: PostgreSQL or MySQL?
#125SQLite has json extensions. You need to select them at compile time though, so you can't just assume they'll be there by default.
Re: Ask HN: PostgreSQL or MySQL?
#126I really like the direct DB to filesystem mappings of the MyISAM engine in MySql. A database is simply a directory. A table is simply 3 files in that directory: - One for the structure - One for the data - One for the indexes You can simply copy a MyISAM database by copying the directory (while the MySql server is stopped). MariaDB has forked the MyISAM engine and created the Aria engine. It is a crash safe version o…
Re: Ask HN: PostgreSQL or MySQL?
#1271. Depends. If you have a lot of update queries, MySQL wins [ https://eng.uber.com/mysql-migration/ ]. MySQL also has better replication and sharding support at the moment. 2. PostgreSQL and MYSQL also sport JSON... JSON functions can be a little tricky. Still, they work. 3. Depends on the structure of your XML. Might even possible to use RegEx to achieve this objective. XML to JSON is easier though. That can be save…
Re: Ask HN: PostgreSQL or MySQL?
#128> 2. Is it possible to build a hybrid database schema? For example, SQLite+JSON? Postgres and MySQL both have JSON support that can do fancy things which includes indexes, but it's extra work and I don't think it actually gains you anything. I'd recommend using regular old columns for anything you ever plan to want a query on. But if you have other stuff, it's perfectly reasonable to dump a bunch of random garbage in…
Re: Ask HN: PostgreSQL or MySQL?
#129Personally I prefer PostgreSQL and the main benefit of using MySQL is how easy it is to set up replication and operate in master-slave, master-master, or group replication.
For high write volumes, TokuDB and now RocksDB do work well, the former for sequential writes and the latter is LSM Tree based.
Re: Ask HN: PostgreSQL or MySQL?
#130Answering Q1: MySQL over Postgres. Postgres has 2 critical things going against it - The query optimizer is a mess - It's implementation of secondary indexes is not cache friendly, so it can be slow
Can you get into more details about this? What about the implementation is not cache friendly?