I don't understand why everyone keeps saying that no one is going to want to use PostgreSQL for inference... of course not, no one is suggesting that. But they are going to want to store embeddings of their data and be able to query those embeddings by similarity. Just like they do today in the various existing vector databases.
But then once in a while you have this one client with a task that can be solved easily with something like postgis, and you rejoice, and praise gods and developers and things, and drink beer happily ever after to their health, and add tasty sauces to your dinner potatoes.
I think one of the most important and interesting questions regarding using pgvector is performance, and in particular, how it compares to Qdrant, Weaviate, etc. This post hints at that where it says "I presented a lightning talk called Vectors are the new JSON where I shared use-cases and some upcoming challenges with improving PostgreSQL and pgvector performance for querying vector data. Some problems to tackle (many of which are in progress!) involve adding more parallelism to pgvector, adding support for indexing for vectors with more than 2,000 dimensions, and leverage hardware acceleration where possible to speed up calculations.". But the post doesn't give any numbers. I tried to read the linked lightning talk, but it's on https://www.slideshare.net/, which is a really weird website now -- every few slides it tried to force me to watch a 30 second commercial!?
I'm a big fan of Postgres, and my app backends are usually very Postgres-heavy. But yeah, I don't get why you'd want to use Postgres for AI inference unless there's some performance reason.
I'm assuming the cost/effort of getting whatever customized Postgres instance supports efficient (i.e not using the CPU alone) ML inference is more than orchestrating something else.
someone has opportunity to prepackage and even sell such product (postgres has BSD license, so you can totally close sources and sell as your own product).
Also, I think there are many cases when smaller models can totally run on CPU.
Right, but they can (and do) also prepackage ML inference services that don't involve Postgres. I think the small model use case would be the biggest reason, same as how I've sometimes used a Postgres table as a cache in a pinch.
> Right, but they can (and do) also prepackage ML inference services that don't involve Postgres.
but then you would need some dataprocessing/warehousing infra integrated to produce dataset for inference and then do something with inference results. Having one db with everything packaged would reduce complexity significantly.
ML training workflow also could be integrated into this DB, so you could have few queries to generate data for training, model training, generate data for inference, produce inference results and do something with inference results.
I was just looking at inference, meaning you need some separate infra to do the training either way. If the DB does the training too, then yeah. I think we're pretty far from that, and Postgres by itself might not be the platform for it. There are platforms with SQL-like interfaces that use databases underneath, but there's a lot happening on top.
I think it is all few months work project, given you can run any arbitrary py/c code in extension in postgres, so it is a matter of data wrangling: convert pg table to recordio, run train/inference, convert results back to pg table, wrap logic into pg/py or pg/c functions.
Someone wants to get started in AI/ML today and they have beginner-level understanding of Python/Javascript. Without any further context, but a desire to learn AI/ML and building on what they know should that person next look to:
1) learn PostgreSQL, pgvector, and whenever the "new" comes
2) learn PyTorch, TensorFlow in Python
3) learn TensorFlow.js
Presume hobby-level interest, not production-safe best practices - so I guess there is that additional context
Read papers about the problem you wish you to apply ML to, and implement them in pyTorch. I would get a book too. You could read the first three sections of this, for starters: https://probml.github.io/pml-book/book1.html
#2. Databases like Postgres are central to backend applications, but for AI the real action is happening on those tensor frameworks.
Honestly I can't see pgvector becoming a mainstream way of running inference. I used pg cube for that on one project a while ago. Yeah it worked, but even ignoring the performance issues, the only reason we considered it was because of our weird use case. We were also doing other funky stuff like large sparse matrix math using just float8 cols, with parallelism (by splitting one query into ~32).
Most likely #2 would be the best bet for both hobby level and above. You could do some fun stuff with Postgres and pgvector, but you'll be "limited" to creating some embeddings with an existing model, storing them in pgvector and again using that to add context to an existing model (more or less).
#3 would limit you to running existing models in a browser.
Only #2 would allow you to actually understand and create new meaningful models.
