*[SQL Extension](api/sql-extension/README.md)

*[pgml.deploy()](api/sql-extension/pgml.deploy.md)

*[pgml.embed()](api/sql-extension/pgml.embed.md)

*[pgml.chunk()](api/sql-extension/pgml.chunk.md)

*[pgml.generate()](api/sql-extension/pgml.generate.md)

*[pgml.predict()](api/sql-extension/pgml.predict/README.md)

*[Batch Predictions](api/sql-extension/pgml.predict/batch-predictions.md)

PostgreSQL is designed to be_**extensible**_. This has created a rich open-source ecosystem of additional functionality built around the core project. Some[extensions](https://www.postgresql.org/docs/current/contrib.html) are include in the base Postgres distribution, but others are also available via the[PostgreSQL Extension Network](https://pgxn.org/).\

There are 2 foundational extensions included in a PostgresML deployment that provide functionality inside the database through SQL APIs.

***pgml** - provides Machine Learning and Artificial Intelligence APIs with access to more than 50 ML algorithms to train classification, clustering and regression models on your own data, or you can perform dozens of tasks with thousands of models downloaded from HuggingFace.

description:Split some text into chunks using the specified splitter.

Chunks are pieces of documents split using some specified splitter. This is typically done before embedding.

pgml.chunk(

splitterTEXT,-- splitter name

textTEXT,-- text to embed

kwargs JSON-- optional arguments (see below)

)

SELECTpgml.chunk('recursive_character','test');

SELECTpgml.chunk('recursive_character','test','{"chunk_size": 1000, "chunk_overlap": 40}'::jsonb);

SELECTpgml.chunk('markdown','# Some test');

Note that the input text for those splitters is so small it isn't splitting it at all, a real world example would look more like:

SELECTpgml.chunk('recursive_character', content)FROM documents;

Where`documents` is some table that has a`text` column called`content`

We support the following splitters:

For more information on splitters see[ LangChain's docs](https://python.langchain.com/docs/modules/data\_connection/document\_transformers/)

_Discrete quantization is not a new idea. It's been used by both algorithms and artists for more than a hundred years._

_Discrete quantization is not a new idea. It's been used by both algorithms and artists for more than a hundred years._\\

Going beyond 16-bit down to 8 or 4 bits is possible, but not with hardware accelerated floating point operations. If we want hardware acceleration for smaller types, we'll need to use small integers w/ vectorized instruction sets. This is the process of_quantization_. Quantization can be applied to existing models trained with 32-bit floats, by converting the weights to smaller integer primitives that will still benefit from hardware accelerated instruction sets like Intel's[AVX](https://en.wikipedia.org/wiki/Advanced\_Vector\_Extensions). A simple way to quantize a model can be done by first finding the maximum and minimum values of the weights, then dividing the range of values into the number of buckets available in your integer type, 256 for 8-bit, 16 for 4-bit. This is called_post-training quantization_, and it's the simplest way to quantize a model.

<figure><imgsrc="../../.gitbook/assets/pgcat_prepared_throughput.svg"alt=""><figcaption></figcaption></figure>

| Full Text Search| -| ✅|

| Geospatial Search| -| ✅|

Both MindsDB and PostgresML support many classical machine learning algorithms to do classification and regression. They are both able to load~~the latest LLMs~~ some models from Hugging Face, supported by underlying implementations in libtorch. I had to cross that out after exploring all the caveats in the MindsDB implementations. PostgresML supports the models released immediately as long as underlying dependencies are met. MindsDB has to release an update to support any new models, and their current model support is extremely limited. New algorithms, tasks, and models are constantly released, so it's worth checking the documentation for the latest list.

Another difference is that PostgresML also supports embedding models, and closely integrates them with vector search inside the database, which is well beyond the scope of MindsDB, since it's not a database at all. PostgresML has direct access to all the functionality provided by other Postgres extensions, like vector indexes from[pgvector](https://github.com/pgvector/pgvector) to perform efficient KNN & ANN vector recall, or[PostGIS](http://postgis.net/) for geospatial information as well as built in full text search. Multiple algorithms and extensions can be combined in compound queries to build state-of-the-art systems, like search and recommendations or fraud detection that generate an end to end result with a single query, something that might take a dozen different machine learning models and microservices in a more traditional architecture.

The architectural implementations for these projects is significantly different. PostgresML takes a data centric approach with Postgres as the provider for both storage_and_ compute. To provide horizontal scalability for inference, the PostgresML team has also created[PgCat](https://github.com/postgresml/pgcat) to distribute workloads across many Postgres databases. On the other hand, MindsDB takes a service oriented approach that connects to various databases over the network.

<figure><imgsrc="../../.gitbook/assets/mindsdb-pgml-architecture.png"alt=""><figcaption></figcaption></figure>

| On Premise| ✅| ✅|

| Web UI| ✅| ✅|

The difference in architecture leads to different tradeoffs and challenges. There are already hundreds of ways to get data into and out of a Postgres database, from just about every other service, language and platform that makes PostgresML highly compatible with other application workflows. On the other hand, the MindsDB Python service accepts connections from specifically supported clients like`psql` and provides a pseudo-SQL interface to the functionality. The service will parse incoming MindsDB commands that look similar to SQL (but are not), for tasks like configuring database connections, or doing actual machine learning. These commands typically have what looks like a sub-select, that will actually fetch data over the wire from configured databases for Machine Learning training and inference.

| translation\_en\_to\_es| t5-base| 1573| 1148| 294|

| summarization| sshleifer/distilbart-cnn-12-6| 4289| 3450| 479|

There is a general trend, the larger and slower the model is, the more work is spent inside libtorch, the less the performance of the rest matters, but for interactive models and use cases there is a significant difference. We've tried to cover the most generous use case we could between these two. If we were to compare XGBoost or other classical algorithms, that can have sub millisecond prediction times in PostgresML, the 20ms Python service overhead of MindsDB just to parse the incoming query would be hundreds of times slower.

| GPU| 17ms| $72| 6 hours|

| OpenAI| 300ms| $299| millennia|

You can also find embedding models that outperform OpenAI's`text-embedding-ada-002` model across many different tests on the[leaderboard](https://huggingface.co/spaces/mteb/leaderboard). It's always best to do your own benchmarking with your data, models, and hardware to find the best fit for your use case.