91–100 of 121 posts
Earlier quoted context omitted.
If YOUR life is good but you want to continue to make your analysts' life a living hell => Don't change anything Otherwise, switch to Postgres. At the very least, for the love of god, make sure your MySQL is >=v8.0
Care to expand on why MySQL < 8 will be problematic for analysts? Anything else than the lack of window function?
Earlier quoted context omitted.
> Example: Model.objects.get(), because nobody could understand Model.get(), right? /s That has a simple explanation: each Model can have multiple Managers [1], and the `objects` is the default one. Also, by convention, methods on the Model are usually relative to "one DB record", and methods on the manager are relative to N records. [1]: https://docs.djangoproject.com/en/2.2/topics/db/managers/
Thank you, I know now why Django inflicts that .objects method to everybody :-) I'd rather design a less verbose API for the default manager Model.get() Model.filter() ... and Model.manager.get() if one really needs custom managers. The fact that I didn't know about managers after years of Django (and nobody told me) should be telling of me and my team, of course, but also how needed managers are. Having to go throug…
As much as I like PostgreSQL's features, MySQL does have advantages in some situations. The copy on write/mvcc type stuff in particular has bit me hard in the past. It's great in most cases but can cause some serious issues with huge tables where every row is updated many times. Even with frequent table cleanup/analyze/etc, the tables bloat up and can become completely unworkable whereas in MySQL there are no problem…
MySQL's InnoDB is MVCC as well, at least when used with transaction isolation. That said, MySQL does have more mature replication options built-in.
MySQL InnoDB tables handle the use case much much better, so just guessing but it's probably a difference in how the indexes handle updates/multiple versions and how the query planner works for dirty indexes.
If your project is already on MySQL and you have no issue => Don't change anything If your project is already on MySQL and you have issues => understand the issues you are facing and make sure that moving to Postgres would fix them (99% chance it won't) If you have a new project and have very precise informations about the constraint you will face (pretty rare) => Do your research and choose what's best for your use…
The first time you need to run a DDL statement on live data (usually: "2.sql"), you'll be thankful for transactions. The places where Postgres shines aren't exactly uncommon situations.
Isn't that about just switching the db driver in the ORM? Sorry for being sarcastic, but was that not exactly the point of countless database abstraction layer projects?
The abstraction is useful. The abstraction is leaky.
I'm a huge PG fan but switching your database on an existing project is a non-small undertaking. If you're starting from scratch, then yes, you take PG every time. There's a lot...a lot that goes into saying that and if you haven't made the jump, a lot of the reasons aren't going to seem important because you currently "don't do" the things that PG lets you do with your data. Like this: https://www.brightball.com/art…
So there’s some nice things about Postgres, but by far the thing I miss the most when I go back to other systems (incl. MySQL/Maria) is transactional DDL. Knowing that a bad migration isn’t going to leave my DB in a half-changed fucked up state is worth it.
This and window functions and safety of data. I'm using MySQL and PostgreSQL in different projects (customers choice) and sometimes there are things I can't do in the MySQL one or would be much more complicated. Sometimes MySQL silently slips bad data in the db because it truncates strings that don't fit varchars or those impossible 0000-00-00 00:00:00 dates. To be fair, the latter are not much of a problem. I'd go P…
Heh, I've only done a few migrations from MySQL to PostgreSQL, and in every case the hardest part has been dealing with bad data in the source DB. It's always been pretty illuminating for the client when they discover how much bad data they actually have in the DB, even though their "ORM Validations" were keeping it "clean" to make up for MySQL's shortfalls.
Isn't that about just switching the db driver in the ORM? Sorry for being sarcastic, but was that not exactly the point of countless database abstraction layer projects?
Postgres has significant issues with vacuum and index write amplification, as noted in the Uber blog post a few years ago - nothing has changed.
Additionally, there is no clear compliance story regarding schema configuration, grants and restricting COPY with Postgres, while those are no-brainers with MySQL.
If you're an AWS user, then MySQL has more advanced managed options as of 2019.
In summary, Postgres is fine if you don't have paying users yet - any database would do fine.
But there's a reason Google and Facebook have stayed with MySQL, and that's because it is manageable at scale whereas Postgres simply isn't.
On the other hand, if you want to use Vertica (derived from the Postgres code base) as a column-store database, then managing it is the same as Postgres.