* InnoDB (default storage engine in MySQL and MariaDB) uses a clustered index, which can handle an extremely high volume of primary key range scan queries
* Ability to handle several thousand connections per second without needing a proxy or pool (the connection model in MySQL and MariaDB is multi-threaded instead of multi-process)
* Workloads that lean heavily on UPDATE or DELETE have terrible MVCC pain (vacuum) in Postgres, rarely a problem in MySQL or MariaDB due to using an undo log design
* Support for index hints and forced indexes, preventing huge outages when the query planner makes a random mistake at an off hour
* Built-in support for direct I/O is important for very high-volume OLTP workloads -- InnoDB's buffer pool design is completely independent of filesystem/OS caching
* If you need best-in-industry compression, the MyRocks storage engine is easy to use in MariaDB
* Logical replication can handle DDL out-of-the-box in FOSS MariaDB or MySQL, whereas in Postgres you must pay for an enterprise solution
* Much better collation support out-of-the-box
* Tooling ecosystem which includes multiple battle-tested external online schema change tools, for safely making alterations of any type to tables with billions of rows
* MariaDB has built-in support for using system-versioned tables, application-time periods, or both (bitemporal tables)
That all said -- Postgres is an amazing database with many awesome features which MariaDB lacks. Overall unless your situation is very high scale or an unusual edge-case, it's usually best to just go with what you know / what your team knows / what you can hire for, etc.
https://www.postgresql.org/docs/current/ddl-partitioning.htm...
Logical replication...
https://www.postgresql.org/docs/current/logical-replication....
https://github.com/2ndQuadrant/pglogical?tab=readme-ov-file#...
https://docs.aws.amazon.com/dms/latest/sbs/chap-manageddatab...
In 'recent years' (in database support terms), PostgreSQL has gained autovacuum support.
https://www.enterprisedb.com/blog/postgresql-vacuum-and-anal...
This stack overflow question was insightful, in that most of the slowness many experience may be related to foreign key check lookups on unindexed columns that point to external keys. https://dba.stackexchange.com/questions/328884/why-is-the-de... Partitioned data and batches to spread out updates also appear to be current best practices https://www.dragonflydb.io/faq/postgres-delete-performance
I'm also not working with super-high-performance production-critical loads, though, so grain of salt and all that.
https://www.databasebenchmarks.net/benchmark-charts.html/?aw...
We used to hit a wall when reaching 100bn rows on MySQL but that was 15 years ago.
Some of that will be personal preference but I’ve never found administration of a Postgres database cluster to be nearly as intuitive as MySQL/MariaDB.
Maria supports partitioning, Postgres (as of my last knowledge) does not.
Unstructured data is more flexible in Maria natively, but Postgres can support it in a variety of ways.
You can find lists and lists of head to head comparisons out there which will highlight all of the niche differences that each brings over the other.
Ultimately either will work just fine for 99% of use cases.
PostgreSQL's manual indicates that partitioning is a thing[1]. Is the something different than what you're thinking of?
One of my projects has the need to drop millions of rows a month based on the time period, and I've been considering a switch to postgres because they also have a module that will do that automatically.
What am I missing?
[1] https://www.postgresql.org/docs/current/ddl-partitioning.htm...
Modern versions of postgres have all the partioning features you'd expect (except automatic ranged partion creation)
I don't know anything about K1, so all I have is confusion (and a sudden urge to switch entirely to postgres).
You don’t put yourself in debt and replace the CEO unless you see some value not currently being realized.
They might even try license shenanigans but with GPLv2, not sure what they can do.
MariaDB plc has some really talented C++ engineers who are experts in database internals. Their DB has some compelling features that many competitors lack, for example system-versioned tables, Oracle DB compatibility layer, and soon a really nice multi-tenancy feature (catalogs). MariaDB plc has a strong presence in Europe, which I would assume is very appealing for potential European customers. And now they finally have an owner with deeper pockets, which hasn't been true in recent history; their previous financial state likely hindered commercial adoption.
If MariaDB can execute well on support and services, I'd imagine their new owners can get a good return on their investment as-is. No need for squeezing and strip-mining them, I don't see how that would even work in this case.
As a weird twist of coincidence and irony, MariaDB's sql proxy is BSL only.
I don't think either license is a reason to use/not use the respective DB system (HAproxy exists) but it's always funny to me how the "we must keep it open" group did exactly what they accused Oracle of planning to do.
Realistically if you need the MySQL semantics (eww) and wire protocol TiDB or a hosted offering like Aurora DB have been better choices for a long time now.
For complex multi-member clusters Maria/MySQL are quite far ahead.
That doesn't seem correct. It's now owned by a single shareholder, that's literally a financial organisation of the kind likely to turn the screws until the last drop of blood is gone.
As in the hype train? They used to love mongodb in its broken state.
If only most of them actually investigate, compare and evaluate to make this choice.
I'm not saying PostgreSQL is perfect or the best choice for everything. That's obviously stupid. But claiming it's a "hype" is not a serious comment.
Also the MariaDB Foundation is separate from the commercial/enterprise entity MariaDB plc. This article is about the latter being taken private.
MariaDB does not need to win against MySQL, it really needs to win against PostgreSQL