Every database will become a vector database sooner or later

RDBMS is such a mature and powerful technology, and with the vast power in modern single-node hardware, they will scale to considerable sizes. But there is a limit.

Once a table or set of tables hit a certain scale, it needs to be distributed. Once you get to those scales, you are likely dealing with the threat of exponential data growth, so doing the "distributed Postgres" will bandaid the problem ... but you are starting to run into the CAP theorem's problems.

You'll need to AP-scale the biggest data tables, and since that almost always means a big coding change lift and introduction of an AP-scaling database, it will almost always be a six months to a year transition, and possibly adding an entirely new DB technology (Cassandra / DynamoDB / maybe FoundationDB).

I have yet to have anyone explain how joins scale on an AP distributed database except in limited situations where the joined data is somehow node-local to the other tables, usually some hierarchical situation. Otherwise you are pulling data from lots of nodes and aggregating and comparing the different sets to account for node drift / partitions / network failures. Cassandra and Dynamo basically say "you are scaling a single table/query/update/pre-joined data table".

Which really isn't fun for RDBMS folks. Because it is a shitload of denormalization on top of all the AP headaches and distributed transactions / updates.

As I said, megahuge machines really make that an outside case unless your use case really emphasizes the "A" in CAP, where write speed can be tolerated to be low and you want to tolerate entire cloud or datacenter outages.

But yeah, nosql was never going to kill the rdbms. The functionality/power of rdbms/SQL is so so so so much higher. Just be aware when you're about to shoot over the limit and prepare for the code changes to handle true scale in the (unlikely) event you're going to need it.

https://github.com/asg017/sqlite-vss

Not associated with the project, just love SQLite and find it very useful.

That statement can definitely be true for many technologies, either because of a lot of hype and promises surrounding them (e.g. the history of MongoDB and how the NoSQL movement was like initially), or due to the mistaken belief that you need them from the very beginning of development even in cases when they are a good fit. I guess the first part is basically describing the Gartner hype cycle, which feels vaguely truthful: https://en.wikipedia.org/wiki/Gartner_hype_cycle Even good tech is susceptible to this, until people actually figure out what it's best used for and when.

If you're in the early stage of developing a prototype, or are working on a system for a small business, then a single RDBMS can indeed work for most use cases - even when you need to store JSON, use full-text indices or even store a reasonable amount of binary data (or even a NoSQL solution, depending on the constraints). It's the same with how you can build an entire business on a monolith written in boring tech, like .NET or Java, with whatever you want for the front end.

Eventually, you might be well served to branch out - at the point where the need for something more specialized becomes more pressing and you can actually afford the time and human resources to manage the complexity/integration effort and so on, or even hire people proficient in that particular tech in the first place. If you have an entire team just for search, then you're probably at that point. If it's just another ticket in your issue tracker for a developer or two to implement, just use the simple index approach with hopefully good enough results.

If it's a greenfield project and you're doing something very novel, all bets are probably off, though.

Massive RDBMS instances are awful to manage. Hard to backup/restore/fork. Hard to migrate tables and schemas without causing downtime. Accidental downtime happens all the time due to locks, bad indexes, bad query plans , etc etc. at large scale they are capricious beasts, care and feeding and most importantly changing them becomes a dark art.

Don’t let them get too big you’ll regret it :)

You pair a vector db with a metadata store (can be anything, but ideally you want low gravity with the vdb and disk for fast retrieval... i.e. leveldb, sqlite equivalents... or hell a traditional db - and the author is right traditional dbs dont need to work too hard to create a ANN extension)

In general, the greater challenge is the data engineering and overhead of managing retrieval stores (in terms of the data-integration/model pipelines) ... so I'm bull on the solutions addressing opportunities here.