K1 Buys MariaDB(prnewswire.com)
prnewswire.com
K1 Buys MariaDB
https://www.prnewswire.com/news-releases/k1-acquires-mariadb-a-leading-database-software-company-and-appoints-new-ceo-302243508.html
93 comments
I’d say less. This acquisition screams that some MBA looked at their financials, saw money left on table, likely by not completely screwing over customers, and said, let’s do this! Think Broadcom/VMware on smaller scale.
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.
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.
I'm usually skeptical of private equity, but in this case I see reasons to not be immediately cynical. The purchase price was only ~$37 million USD, which is quite reasonable considering MariaDB's reach and potential.
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.
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.
They are, let’s call it 40 Million in the hole. That’s not money invested in RD or anything. It was given to shareholders and they will pocket it.
The company sold at a considerable loss to shareholders. No one got rich there. Their SPAC was not good and should never have happened. Even if they hadn't sold the company, their stock would have been de-listed anyway, due to being deficient on both market cap and share price. A reverse-split can temporarily fix the latter but not the former.
There were, however, multiple interested buyers (at least 3 from what I recall reading over the past year) because there's a lot of potential upside if their execution improves.
If you think my statements are incorrect, what do you propose was the motivation for this purchase?
There were, however, multiple interested buyers (at least 3 from what I recall reading over the past year) because there's a lot of potential upside if their execution improves.
If you think my statements are incorrect, what do you propose was the motivation for this purchase?
The motivation for the purchase is Enterprise Database software is extremely sticky. So what I said in my original post, jack up the licensing the costs and cut expenses and squeeze the customer base for more money.
It doesn't matter about loss to shareholders, money paid is NOT going to the company, it's going to shareholders unless the company is significant shareholder. K1 has -40Million on Spreadsheet about MariaDB BEFORE any additional investments and they want that money back. So how is K1 going to make its money back? My gut is my original post is more correct than some investing in the product to make a better database and beat out the competitors. I'll point out the new CEO, while having engineering degrees, seems to be more a business type person.
It doesn't matter about loss to shareholders, money paid is NOT going to the company, it's going to shareholders unless the company is significant shareholder. K1 has -40Million on Spreadsheet about MariaDB BEFORE any additional investments and they want that money back. So how is K1 going to make its money back? My gut is my original post is more correct than some investing in the product to make a better database and beat out the competitors. I'll point out the new CEO, while having engineering degrees, seems to be more a business type person.
> Enterprise Database software is extremely sticky. So what I said in my original post, jack up the licensing the costs
Nope, that doesn't make any sense in my view. Let's say e.g. the cost of both MariaDB Enterprise and MaxScale is jacked up significantly. Then customers can easily switch back to MariaDB Community Server, and/or get paid support and products from Oracle MySQL, or Percona, or ProxySQL, or Pythian, or Vettabase, or Mydbops, or any number of other companies with significant experience in this exact space.
> and cut expenses
Prior to this sale, MariaDB plc already had major rounds of layoffs, discontinued several product lines, and spun off their cloud database. What do you suggest the new owner is going to cut, specifically?
> money paid is NOT going to the company
That is blatantly obvious, why do you keep repeating it? No one in this thread is saying the money goes to the company. That's not how acquisitions ever work!
> I'll point out the new CEO, while having engineering degrees, seems to be more a business type person.
Looks to me like a very similar profile to their two previous CEOs, except the outgoing one didn't have an engineering degree!
Nope, that doesn't make any sense in my view. Let's say e.g. the cost of both MariaDB Enterprise and MaxScale is jacked up significantly. Then customers can easily switch back to MariaDB Community Server, and/or get paid support and products from Oracle MySQL, or Percona, or ProxySQL, or Pythian, or Vettabase, or Mydbops, or any number of other companies with significant experience in this exact space.
> and cut expenses
Prior to this sale, MariaDB plc already had major rounds of layoffs, discontinued several product lines, and spun off their cloud database. What do you suggest the new owner is going to cut, specifically?
> money paid is NOT going to the company
That is blatantly obvious, why do you keep repeating it? No one in this thread is saying the money goes to the company. That's not how acquisitions ever work!
> I'll point out the new CEO, while having engineering degrees, seems to be more a business type person.
Looks to me like a very similar profile to their two previous CEOs, except the outgoing one didn't have an engineering degree!
It's a weird scenario where a bunch of people bemoaned Oracle owning MySQL (hence MariaDB exists), and yet Oracle have maintained and allowed MySQL to see huge improvements, and they include their sql proxy under GPL as well.
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.
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.
Oracle is kind of a shitty company to deal with, but they seem to be doing relatively well with open source these days.
> and yet Oracle have maintained and allowed MySQL to see huge improvements
In the latest twist Oracle is adding things other Heatwave and not MySQL i.e. not open source.
It's an ever-changing situation.
> (hence MariaDB exists)
That's sort of the old take. Lots of new features aren't compatible on both sides. MariaDB has diverged. It just hasn't gained enough traction for those things to matter.
In the latest twist Oracle is adding things other Heatwave and not MySQL i.e. not open source.
It's an ever-changing situation.
> (hence MariaDB exists)
That's sort of the old take. Lots of new features aren't compatible on both sides. MariaDB has diverged. It just hasn't gained enough traction for those things to matter.
> That's sort of the old take. Lots of new features aren't compatible on both sides.
If by "the old take" you mean "the stated reason they created the fork" then sure. I guess everyone's a revisionist when it's convenient.
If by "the old take" you mean "the stated reason they created the fork" then sure. I guess everyone's a revisionist when it's convenient.
I moved to postgres over a decade ago but have occasionally had to interlope into MySQL/MariaDB infrastructure. IMHO it has been a lesser choice for a long time, typically just clinging onto it because of legacy reasons or an over-involved executive but these people are also typically very proud and protective over the thing they know.
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.
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.
From my POV, it's a supplier that is no longer beholden to shareholders demands for profit. A platform and service that can operate using customer sourced revenue and respond to market demand without a profit driven board is a big win for everyone while funding development and maintenance of a great open source project.
I think that’s exactly the wrong impression I get. Private equity is going to cause them to quickly get to better profitability through price increases, layoffs, and reduced R&D.
> it's a supplier that is no longer beholden to shareholders demands for profit.
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.
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.
I jumped ship from mysql/mariadb to psql over a decade ago and can't imagine why I would ever look back.
Monty needs a new kid for his next db
https://en.m.wikipedia.org/wiki/Michael_Widenius
I did not realize MySQL was also named after one of his kids.
Little bobby tables they called him
For those who haven't seen/don't recall the xkcd comic - https://xkcd.com/327/
[deleted]
Yeah, "My" is actually pronounced wrong by 99% of all MySQL users.
Sure, but
> The official way to pronounce “MySQL” is “My Ess Que Ell” (not “my sequel”), but we do not mind if you pronounce it as “my sequel” or in some other localized way.
https://dev.mysql.com/doc/refman/8.4/en/what-is-mysql.html
> The official way to pronounce “MySQL” is “My Ess Que Ell” (not “my sequel”), but we do not mind if you pronounce it as “my sequel” or in some other localized way.
https://dev.mysql.com/doc/refman/8.4/en/what-is-mysql.html
The SQL part as well, it should be pronounced "squeal".
[deleted]
What's the correct way to pronounce it?
Roughly rhymes with the "vu" in "Déjà vu"
He already has Max. MaxDB sounds like good name tbh.
He already used that! https://en.wikipedia.org/wiki/MaxDB
MaxDB is already developed by SAP, weirdly enough, No relation tho
https://en.m.wikipedia.org/wiki/MaxDB
https://en.m.wikipedia.org/wiki/MaxDB
There is actually a relation, it used to be called SAP DB and MySQL AB renamed it to MaxDB.
It must be tough for the business, as more and more web development has fallen in love with PostgreSQL. While the support business for PostgreSQL exists, I am not sure if they can get similar profit margins / earning multipliers as early 2000 software businesses, even open source ones.
Developers and on HN sure, but the web runs on LAMP (mostly WP). Also, it is sure possible to optimise your postgres setup, but we had some scaling/sharding niche cases where mysql worked and performed out of the box and postgres was (is) struggling; I am not very interested wasting my life trying to get it to work while mysql just works without any tweaking (for that case: other cases we still pick mysql as it always performs the same or better than postgres for our cases; it doesn't have all the features pg has, but we don't need those (yet)). I have not seen the reverse yet.
> as more and more web development has fallen in love with PostgreSQL
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.
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.
People have been using PostgreSQL for decades for web stuff. I think the first time I used it was around 2003 or so. The project goes back to 1996 (and even that was based on previous code going back to 1982).
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.
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.
> But claiming it's a "hype" is not a serious comment.
Maybe you're missing the context (it's a chain of replies)? I never said PostgreSQL was bad or that people shouldn't use it.
The original comment I was responding to inferred that "every web developer" was now using PostgreSQL and that part is definitely due to the "hype" - whether social media, youtube or blogs, etc. Well there's also the who's providing a "free" database...
> People have been using PostgreSQL for decades for web stuff.
Sure, but not "every" so much so that it should hurt MySQL / MariaDB at all.
> That's obviously stupid.
That's the point. There are influencers and hypers going around and responding PostgreSQL like an an auto answering machine and then many that just believe it.
Maybe you're missing the context (it's a chain of replies)? I never said PostgreSQL was bad or that people shouldn't use it.
The original comment I was responding to inferred that "every web developer" was now using PostgreSQL and that part is definitely due to the "hype" - whether social media, youtube or blogs, etc. Well there's also the who's providing a "free" database...
> People have been using PostgreSQL for decades for web stuff.
Sure, but not "every" so much so that it should hurt MySQL / MariaDB at all.
> That's obviously stupid.
That's the point. There are influencers and hypers going around and responding PostgreSQL like an an auto answering machine and then many that just believe it.
> The original comment I was responding to inferred that "every web developer" was now using PostgreSQL
No one used to word "every'. It merely stated that "more" web dev stuff uses PostgreSQL, which is not the same as "every" at all. You "inferred" that word from your negativity, cynicism, and some sort of psychological need to spread your toxic bile.
No one used to word "every'. It merely stated that "more" web dev stuff uses PostgreSQL, which is not the same as "every" at all. You "inferred" that word from your negativity, cynicism, and some sort of psychological need to spread your toxic bile.
> It merely stated that "more" web dev stuff uses PostgreSQL
Merely?
Here, quote: "It must be tough for the business, as more and more"... that sounds like an alarming trend?
How do you get to merely? If it's merely it won't be tough for businesses?
> You "inferred" that word from your negativity, cynicism, and some sort of psychological need to spread your toxic bile.
Now we're down to personal attacks? And where did you infer your drama from? Right, the pot calls the kettle black.
Merely?
Here, quote: "It must be tough for the business, as more and more"... that sounds like an alarming trend?
How do you get to merely? If it's merely it won't be tough for businesses?
> You "inferred" that word from your negativity, cynicism, and some sort of psychological need to spread your toxic bile.
Now we're down to personal attacks? And where did you infer your drama from? Right, the pot calls the kettle black.
they learned about jsonb support from postgres so they migrated from mongodb to postgres
It is mostly Oracle and SQL Server around here.
mathnode(1)
Only question is will it remain open source and free.
MariaDB Server is GPL and must always remain GPL, as it's a fork of MySQL which was also GPL.
Also the MariaDB Foundation is separate from the commercial/enterprise entity MariaDB plc. This article is about the latter being taken private.
Also the MariaDB Foundation is separate from the commercial/enterprise entity MariaDB plc. This article is about the latter being taken private.
This code base has been sold like 3x now and is still around.
Ehh, not exactly, personally I wouldn't agree that the first half of that statement is correct.
I think it's important to stress that this article (press release, really) is about MariaDB plc being sold. That was the previously-publicly-traded commercial entity which develops MariaDB Enterprise and other paid solutions. But the MariaDB Community Server code base is maintained by the MariaDB Foundation, which is totally separate. (That said, MariaDB plc is the largest outside code contributor to MariaDB Community Server as well; but they're technically not the maintainers of it.)
It's also important to understand that MariaDB and MySQL have diverged in functionality over the years, and MySQL is still actively developed by Oracle, who have consistently put some serious engineering effort into it. Many folks on HN seem to think that MySQL died and MariaDB replaced it, as some sort of successor across a linear history; that's not accurate and in reality MySQL is extremely widely used.
I think it's important to stress that this article (press release, really) is about MariaDB plc being sold. That was the previously-publicly-traded commercial entity which develops MariaDB Enterprise and other paid solutions. But the MariaDB Community Server code base is maintained by the MariaDB Foundation, which is totally separate. (That said, MariaDB plc is the largest outside code contributor to MariaDB Community Server as well; but they're technically not the maintainers of it.)
It's also important to understand that MariaDB and MySQL have diverged in functionality over the years, and MySQL is still actively developed by Oracle, who have consistently put some serious engineering effort into it. Many folks on HN seem to think that MySQL died and MariaDB replaced it, as some sort of successor across a linear history; that's not accurate and in reality MySQL is extremely widely used.
Also worth noting that Oracle makes their sql proxy (mysql router) available under gpl too.
MariaDB's sql proxy was GPL but went BSL at v2.0 (around 2016 iirc).
MariaDB's sql proxy was GPL but went BSL at v2.0 (around 2016 iirc).
Would be very interesting to hear about plans of MariaDB PLC and New CEO - what are they going to do differently and if that strategy makes sense.
MariaDB does not need to win against MySQL, it really needs to win against PostgreSQL
MariaDB does not need to win against MySQL, it really needs to win against PostgreSQL
What are some reasons to use MariaDB over PostgreSQL?
At scale, there are some workloads where it can be a great choice:
* 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.
* 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.
Partitioning has been supported for quite a while
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
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
> Partitioning has been supported for quite a while
My comment (which you're replying to) didn't mention partitioning at all.
> Logical replication...
My comment specifically said that logical replication of DDL statements is not supported out-of-the-box in FOSS Postgres, which is absolutely accurate. See the very first thing mentioned on https://www.postgresql.org/docs/current/logical-replication-...
You can pay EnterpriseDB for a solution, among other vendors. That situation is far from ideal.
> PostgreSQL has gained autovacuum support.
That doesn't even remotely solve the inherent problems of Postgres's MVCC implementation. See https://www.cs.cmu.edu/~pavlo/blog/2023/04/the-part-of-postg...
My comment (which you're replying to) didn't mention partitioning at all.
> Logical replication...
My comment specifically said that logical replication of DDL statements is not supported out-of-the-box in FOSS Postgres, which is absolutely accurate. See the very first thing mentioned on https://www.postgresql.org/docs/current/logical-replication-...
You can pay EnterpriseDB for a solution, among other vendors. That situation is far from ideal.
> PostgreSQL has gained autovacuum support.
That doesn't even remotely solve the inherent problems of Postgres's MVCC implementation. See https://www.cs.cmu.edu/~pavlo/blog/2023/04/the-part-of-postg...
The fact that vacuum runs automatically does not stop stuck/slow vacuum and transaction ID wrap-around issues from being a death sentence for a high-write-volume Postgres instance. There are many stories on the internet about this, the Notion one (my employer) is here: https://www.notion.so/blog/sharding-postgres-at-notion
Logical replication does exist in pgsql, which is great. What it still lacks however (and I am sure they will very quickly catch up on) is the user facing process of being able to fix or sync a broken node without a rebuild. I'm also pretty sure pgsql logical replication is single threaded?
Things like pg_rewind are layered on fixes that other database users don't have to depend on or learn. Except Oracle (because it's a mess).
I very much appreciate your deep knowledge of MySQL, and willingness to share amidst the sea of postgres fans. There's a reason both are popular and widely used.
I would say the main advantage is scale and uptime. If you need to replicate, duplicate, or maintain state beyond one server; there are very few good RDBMS options, let alone open source. The MariaDB ecosystem competes with IBM Purescale and Oracle RAC; it's hard to appreciate that, until you really need it.
My reason has been relative simplicity. PostgreSQL comes off as much more complex (though whether that is actually true is probably dependent on what you're doing with it).
I'm also not working with super-high-performance production-critical loads, though, so grain of salt and all that.
I'm also not working with super-high-performance production-critical loads, though, so grain of salt and all that.
Mysql is mercurial, Postgres is git. With mysql everything comes somewhat intuitive. Postgres is antiintutive in a lot of places. Probably the people that created it didn't realize that the complexity of Oracle was not needed but was a job program for expensive consultants /s
My own take:
"With MySQL everything seems somewhat more intuitive at first, until it doesn't. Postgres seems antiintutive in some ways at first, until it isn't."
"With MySQL everything seems somewhat more intuitive at first, until it doesn't. Postgres seems antiintutive in some ways at first, until it isn't."
MariaDB scales much better, with native clustering support, native partitioning support, as well as better single-node performance: https://www.databasebenchmarks.net/benchmark-charts.html
That link isn't particularly convincing. As far as I can see, the only Postgres test performed on the hardware that the top MariaDB entries had was on a positively ancient Postgres version (9.2.1).
The top-performing Postgres instance among all benchmarks is v. 11.0.1008: https://www.passmark.com/baselines/V11/advanced-database-ben...
And I'm seeing versions tested up through 16.3 which was released in May. In fact even 9.2.1 is less than three years old.
And I'm seeing versions tested up through 16.3 which was released in May. In fact even 9.2.1 is less than three years old.
* In that link, V11 is not the version of Postgres, it's the version of the test. Scroll down to DB Version.
* Lots of versions are tested, but 9.2.1 is the only version I see on the same hardware that the top MariaDB versions are tested against. The others are on much weaker hardware.
* Postgres 9.2.1 is 12 years old.
Interesting, I found the page comparing performance on AWS useful.
https://www.databasebenchmarks.net/benchmark-charts.html/?aw...
https://www.databasebenchmarks.net/benchmark-charts.html/?aw...
Native bitemporal tables: https://mariadb.com/resources/blog/temporal-tables-part-5/
All of these sibling comments are listing good technical reasons but the most compelling reason by far that I’ve run into for using MariaDB over Postgres is that the underlying software you are trying to deploy only supports MySQL/MariaDB. When my options are “MariaDB” or “Use an entirely different application” I often opt for MariaDB
I know it may seem like a weird reason but I think MySQL Workbench is a MUCH better tool than any other open source interface for interacting with PostgreSQL. I usually use PostgreSQL for other reasons, but MySQL Workbench is the main thing which makes the decision difficult for me.
They are honestly equally fine for most use cases. I find MariaDB tooling better and have a lower mental overhead dealing with it, but perhaps I'm just more used to it.
We used to hit a wall when reaching 100bn rows on MySQL but that was 15 years ago.
We used to hit a wall when reaching 100bn rows on MySQL but that was 15 years ago.
Scale and ease of “sysadmin” level management for things such as clustering, replication, etc.
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.
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.
From the experience of my one man big web project with 12 languages I had a hard time setting up a search that ignores things like éê from other languages in postgres while mariadb innodb just ignores it.
They’re both great systems but there are a few differences primarily in small ways for most applications:
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.
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.
> Maria supports partitioning, Postgres (as of my last knowledge) does not.
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...
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...
> based on the time period
Is it the kind of thing where the TimescaleDB extension would make sense?
https://github.com/timescale/timescaledb
Is it the kind of thing where the TimescaleDB extension would make sense?
https://github.com/timescale/timescaledb
In my case, pg_partman is actually more than enough. It's just a situation where the data isn't useful after a certain point. Timescale as I understand it would be massive overkill for my situation.
> Maria supports partitioning, Postgres (as of my last knowledge) does not.
Modern versions of postgres have all the partioning features you'd expect (except automatic ranged partion creation)
Modern versions of postgres have all the partioning features you'd expect (except automatic ranged partion creation)
postgres have table partitions now, mariadb can however partition a table over multiple servers or shards using the engines like spider and connect, or proxies like maxscale and proxsql.
Local or remote, read your database manual about the fun and caveats that come from partitions.
For a legacy system originally built on MySQL back before Postgres was so strong.
i'm predicting K1 flips MariaDB to Oracle as soon as the dust settles
Interesting thought. I wonder if someone did analyses on how long K1 tends to keep their companies before exist, and what is typical exit path - sell to strategic (Oracle? IBM?) sell to some other PE or take public
I don't know anything about K1, so all I have is confusion (and a sudden urge to switch entirely to postgres).