Introducing the first major release of TideSQL for MySQL. A transactional storage engine built from first principles and on modern research that's write and space optimized, highly effective on reads, and offers parity with InnoDB. Do check it out, we would love your thoughts!
I've spent my entire life reading, writing, condensing and explaining stuff, and I'm pretty good at it, but I find reading this stuff intensely tiring.
But my underlying concern remains. Why are people who want to communicate important ideas leaving it to Claude — which writes like an obscurantist gnome wizard from a bad fantasy novel — to do so, only to lead us to use LLMs to corral it into a less gnomic form?
People used to describe their own products in their own words.
It is available for MariaDB 11.4.x forward to latest 13.x.x and offers real vector support where the MySQL plugin is still lacking though there are proposals in place.
Finally a replacement for RocksDB / MyRocks.
I want to move from MySQL to Postgres, but without a space optimized storage as the MySQL has in Percona, it is impossible to me.
Indeed! Postgres vacuum can be troublesome on lots of write and delete heavy workloads and no way to just set a table to another engine. TidesDB is highly efficient on amplification rather that be write, read, or space for an LSM based engine. Reads are also pretty great with our LSMB+tree hybrid architecture; You can read about TPC-C analysis against InnoDB in MariaDB (larger than memory) and see TidesDB keeping up and even surpassing InnoDB on this very heavy benchmark.
MyRocks have been archived for MySQL. MyRocks in MariaDB is using a very old version of RocksDB in which is rather buggy. TideSQL is similar to MyRocks but it goes a lot further with it's features, trying to offer parity with InnoDB. TideSQL's core is using TidesDB the library which is a write, and space optimized storage engine written in C from first principles, so from the ground up.
Not sure at the moment what they are moving to or have moved to. I just heard from Mark Callaghan few months ago about the archiving, not much besides that.
Not needing a connection pooler (MySQL scales to thousands of connections via threads without breaking a sweat) and not having to deal with garbage collection (vacuuming) are two.
I mean, quite a bit. You use the right tool for the job. To use Postgres for everything is wrong to me. The beauty of MySQL based servers is the internal extensibility where Postgres is still rather lacking. MySQL and MariaDB are caching up on the external extensibility front.
Of course MySQL has obviously the deep support for custom storage engines, then it has loadable functions, auth, component service and these are currently internal extensibility but going forward we are working on a way to manage this extensibility externally through a new proposal which I will be going over in the upcoming MySQL contributor summit in November. Postgres though highly externally extensible doesn't cut into the core like MySQL or MariaDB does thus making it hard to for example make TidesDB integration as TidesDB has to handle the MVCC, for example. OrioleDB is another example and it has to utilize a custom Postgres fork for this reason, the core not being very extensible, though I hear this is being worked on heavily.
Link: https://claude.ai/share/6cf78509-e283-49cc-89b1-c892bfce0641
In fact... I read most of HN like this nowadays, including the comments.
I've spent my entire life reading, writing, condensing and explaining stuff, and I'm pretty good at it, but I find reading this stuff intensely tiring.
But my underlying concern remains. Why are people who want to communicate important ideas leaving it to Claude — which writes like an obscurantist gnome wizard from a bad fantasy novel — to do so, only to lead us to use LLMs to corral it into a less gnomic form?
People used to describe their own products in their own words.
That's just your unsubstantiated opinion. I'm saving time and getting the meat.
https://tidesdb.com/articles/benchmark-analysis-hammerdb-tpc...
https://www.uber.com/us/en/blog/postgres-to-mysql-migration/