alexpadula

No, not really.

Luddism, did not expect to ever hear that word with Postgres development :>

That's a weird take. Do you have an example tibbar?

I do tend to agree with this ( i write database internals and engines for a living _). Letting software accumulate even little bugs is not a good look. Yes prioritize but definitely don't leave the smaller things, they will just pile up and make next work even harder.

Makes sense. Code base is over 30 years old. Lot's of hands went into shaping it. There will be bugs as not one contributor as the entire codebase in their head. The testing is where bugs should be caught. Not by ones knowledge. I actually think there will be more bugs that come out of nowhere either found by humans or automation.

That would be cool

I expected way more books for software engineering.

You know hebetube, my mother once said "if you have nothing nice to say: don't say it". You saying those things probably aren't going to make them turn over the license. "Project dead before it started" like who writes those kinds of things over someones work they spent time on. I'd love for you to explain your logic.

I've never heard of this system. Came out of nowhere and closed source it seems. Could not find much analysis on it at all which is not the best sign.

StackOverflow would be a super hard business to sustain today.

Flying cars before GTA6.

Hope I don’t get it soon then.

Why “when you get” instead of “if you get”. Title assumes we all end up with cancer.

It’s there. Titled “Announcing pg_vectorsearch: Scalable Open-Source Vector Search in PostgreSQL”. In paragraph: “ The result: an index that is significantly faster”

Dark side of the PRISM! The image on the repo 100% inspired by Dark Side of The Moon by Pink Floyd.

Great project, SEV-SNP attestation in zig! awesome that it works offline too.

I’d say Postgres is generally very fast for the average workload in analysis and the external extensibility is truly great, being able to use different index types for example. Postgres also has good support for modern SQL and many datatypes. With those 2 aspects the ecosystem is rather large thus lots of ways to extend Postgres. MySQL and MariaDB are now starting to expand their horizons in this regard.

For the analysis comparison question, yes many articles but because InnoDB does sync compression and not async like TidesDB it’s not performant, but there is analysis on our blog, and against RocksDB as well at library and server level.

Very much possible over time. Currently it’s not. We are working closely with MariaDB and Oracle on making TidesDB available in server releases through extended means. MariaDB you can already use TidesDB from version 11, included through their Foundry.

For MySQL yes on by default, for MariaDB no off by default. In this articles analysis compression was on indeed.

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.

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.

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.

https://tidesdb.com/articles/benchmark-analysis-hammerdb-tpc...

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.

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.

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.

An article where I go through caching with TidesDB and its integrations like TideSQL for MariaDB and MySQL.