Peak "$XXXXXXXX" database is when your particular flavor of DB is completely consumed into traditional RDBMSes.
Vector databases (and all other incremental or transformational improvements) are just features of regular plain traditional RDBMSes that have not been implemented in traditional RDBMSes yet.
I have seen every new DB tech subsumed by traditional databases over time as compute capability improved.
No exceptions.
The list is endless:
- object databases (e.g. blobs, JSON)
- OLAP
- in DB programming ( XX-SQL eg PL/SQL, T-SQL, ANSI-SQL)
- column-oriented data stores
- key-value
- graph databases
- No SQL
- Cloud, distributed, whatever
- statistical analysis databases
- document databases
All these used to be standalone, very expensive, specialty products but are now just one more checkbox on the Oracles/SQL-Servers/DB2s of this world.
All these have been swallowed by the borg of commercial databases without so much as a burp.
There is no winning the commercial market long term for these products. Big business buys traditional RDBMSes because they are the kitchen sink. They do EVERYTHING and they will eventually do this new hot thing, the business will just have to pay big dollars for it. Which is not a problem for big business.
There is a reason that cartoon about the Oracle org hierarchy was made (bottom right): all the company does is make product (Engineering) and protect that product. And it is very good at making good product.
Traditional DBs already kinda support vector DBs via pg_vector extensions and such.
There is a YC startup, latnern, that also built their own extension for postgres that is open source and is better for vector DB use cases: https://github.com/lanterndata/lantern
But yeah! Traditional DBs already support this, if you consider this extension to be part of Postgres.
Literally. We do a lot of vector DB and RAG stuff (who isn't these days, right?) and after a bunch of testing and benchmarking went with pgvector integrated into our existing PostgreSQL database. Operationally simple, performs perfectly adequately. I'm sure there are some niche use-cases where the dedicated vector DBs make sense, but for anyone just getting into it, don't underestimate PostgreSQL and pgvector.
Peak "$XXXXXXXX" database is when your particular flavor of DB is completely consumed into traditional RDBMSes.
Vector databases (and all other incremental or transformational improvements) are just features of regular plain traditional RDBMSes that have not been implemented in traditional RDBMSes yet.
I have seen every new DB tech subsumed by traditional databases over time as compute capability improved.
No exceptions.
The list is endless:
- object databases (e.g. blobs, JSON)
- OLAP
- in DB programming ( XX-SQL eg PL/SQL, T-SQL, ANSI-SQL)
- column-oriented data stores
- key-value
- graph databases
- No SQL
- Cloud, distributed, whatever
- statistical analysis databases
- document databases
All these used to be standalone, very expensive, specialty products but are now just one more checkbox on the Oracles/SQL-Servers/DB2s of this world.
All these have been swallowed by the borg of commercial databases without so much as a burp.
There is no winning the commercial market long term for these products. Big business buys traditional RDBMSes because they are the kitchen sink. They do EVERYTHING and they will eventually do this new hot thing, the business will just have to pay big dollars for it. Which is not a problem for big business.
There is a reason that cartoon about the Oracle org hierarchy was made (bottom right): all the company does is make product (Engineering) and protect that product. And it is very good at making good product.
https://i0.wp.com/stratechery.com/wp-content/uploads/2013/07...