101–110 of 181 posts
My company recently looked at MySQL vs PostgreSQL. While we chose Postgres there is one thing that stood out in my research, I haven't found any comments on this: We were looking at scalable, HA, possibly multi-DC workloads and such, and yes, relational DBs are not necessarily the right choice, but MySQL looked a bit better in this regard, especially for master-master replication. There are several high-profile teams…
Earlier quoted context omitted.
If the requirements are still up in the air, but you know that you're going to be storing some data, definitely go with a database, even if just a single SQLite file. Using plain files means figuring out the file format, which turns into a huge mess when requirements get tacked on later. The other option would be to store a JSON file or a bunch of JSON files in a directory, at which point you're building a shitty ver…
The grandparent comment is right about one thing: you need to figure out what your use case is, in order to make a good judgment call. “Some data” can mean a lot of things. Transactional data? Sure, get a sql database in. Images, video, or plain json documents? SQL databases are a poor fit there. One should also consider if they even need to manage data persistence. I’ve had success using Google Sheets as the backing…
The following isn’t the top reason I recommend Postgres, but is the reason I think least likely to be echoed in a dozen other comments: Postgres has some of the best documentation of any software product I’ve ever used. If someone wants to learn about SQL or databases, I always have to restrain myself from recommending that they just read the Postgres manual front to back. It’s comprehensive, it’s well written, it’s…
I will respond only to Q1, taking the perspective of analytics and data science. Answer: PostgreSQL > MySQL Postgres implementation of SQL includes a few useful clauses that are useful for analytics that MySQL does not support. It used to be that MySQL had no window functions, and that made it wholly inferior to Postgres when it came to analytics. However, it seems MySQL began supporting window functions two years ag…
Having consulted for hundreds of analysts writing SQL to explore their data and create reports, I would agree with this assessment. Additionally, I tend to avoid recommending MySQL because of a strange behavior when using Group By. In Postgres, every column must be either aggregated or grouped by when using a grouping expression. In MySQL, this requirement is not present, and the ambiguity of the query is resolved by…
Earlier quoted context omitted.
> InnoDB MVCC doesn't handle those well either; a long-running tx blocks the purge thread and causes a pile-up of old row versions. Remember that what they moved to isn't directly MySQL eitger, but only uses it underneath.
It's still MySQL/InnoDB under the hood. I don't follow your point -- why does it matter whether an application is talking directly to MySQL, vs using an intermediate service with a non-SQL API? If the intermediate service supports long-running transactions, you'll hit the same underlying issue regardless... If your point is that they also happened to move to a new access pattern that eliminated long-running transacti…
I just need to go back and read the conversation on the pg-general list, it was very good in that it did discuss that some of the issues mentioned by Uber were real. https://www.postgresql.org/message-id/579795DF.10502%40comma... and perhaps some other blogs from around the time this was being discussed.
I know of BDR, but that doesn't seem to be publicly available for recent versions of Pg?
I'm not a very tech savvy and know very little about databases. But I have read countless posts/comments over the years and everywhere everyone recommends postgres. Again, I have no clue about other database systems, but postgres documentation is just awesome. I believe you can practically everything from its documentation.
This 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.
A lot of MongoDB users who wouldn't be considered a "joke" https://www.mongodb.com/who-uses-mongodb
Rather than listen to unqualified nonsense, they run tests. And gather facts to guide technology decisions. and yes, I work for MongoDB - just before anyone starts whining about disclosure You're welcome