postgresml VS good_job

The Python client SDK is so small, because it's just a wrapper around the Rust client SDK: https://github.com/postgresml/postgresml/tree/master/pgml-sdks/rust/pgml. Currently we also support JS/Typescript SDKs as well, all generated from the same safe and efficient underlying Rust implementation, using some fancy Rust macros.

I don't think you'd replace a materialized view with pg_later, but it might help you populate or update your materialized view if you are trying to do that asynchronously. pglater.exec() works with DDL too!

I use it a lot for long running queries when doing data science and machine learning work, and a lot of times when executing queries from a jupyter notebook or CLI. That way if my jupyter kernel dies, my query execution continues even if the network or my environment has an issue. I've started using it a bit more with https://github.com/postgresml/postgresml for model training tasks too, since those can be quite long running depending on the situation.

PostgresML comes with pgvector as a vector database. The cool thing is it can run your models in the same memory space as a database extension. We’re also working on ggml support for huggingface transformers, but could use some help testing more LLMs for compatibility. https://github.com/postgresml/postgresml/pull/748

We've been working on a Python SDK[1] for PostgresML to make it easier for application developers to get the performance and scalability benefits of integrated memory for LLMs, by combining embedding generation, vector recall and LLM tasks from HuggingFace in a single database query.

This work builds on our previous efforts that give a 10x performance improvement from generating the LLM embedding[2] from input text along with tuning vector recall[3] in a single process to avoid excessive network transit.

We'd love your feedback on our roadmap[4] for this extension, if you have other use cases for an ML application database. So far, we've implemented our best practices for scalable vector storage to provide an example reference implementation for interacting with an ML application database based on Postgres.

[1]: https://github.com/postgresml/postgresml/tree/master/pgml-sd...

We've been working on a Python SDK for PostgresML to make it easier for application developers to get the performance and scalability benefits of integrated memory for LLMs, by combining embedding generation, vector recall and LLM tasks from HuggingFace in a single database query.

Links:

[1]: https://huggingface.co/spaces/mteb/leaderboard

[2]: https://postgresml.org/blog/generating-llm-embeddings-with-o...

[3]: https://postgresml.org/blog/tuning-vector-recall-while-gener...

[4]: https://postgresml.org/blog/personalize-embedding-vector-sea...

Github: https://github.com/postgresml/postgresml

Github: https://github.com/postgresml/postgresml

I'd encourage you to do inference outside of PostgreSQL (use TF serving and make requests against it, or do batch inference), but if you're determined to do so, they have an extension that integrates with the transformers library and allows for calling models directly from SQL.

This is the most direct competitor of good_job in my opinion.

Once we are done with default gems, should we look into something we usually use? That's jwt because we need session tokens for our API. Next comes our one and only sidekiq. For a long period of time it was the best in town solution for background jobs. Now we could also consider solid_queue or good_job. In development and testing groups we need rspec-rails, factory_bot_rails and ffaker. Dealing with money? Start doing it properly from the beginning! Do not forget to install money-rails. Once everything is added to the Gemfile do not forget to trigger bundle install.

In the world of Ruby, GoodJob [0] has been doing a _good job_ so far.

[0] - https://github.com/bensheldon/good_job

For Rails apps, you can do this using the ActiveJob interface via

https://github.com/bensheldon/good_job

Had it in production for about a quarter and it’s worked well.

Idk about pgagent but any table is a resilient queue with the multiple locks available in pg along with some SELECT pg_advisory_lock or SELECT FOR UPDATE queries, and/or LISTEN/NOTIFY.

Several bg job libs are built around native locking functionality

> Relies upon Postgres integrity, session-level Advisory Locks to provide run-once safety and stay within the limits of schema.rb, and LISTEN/NOTIFY to reduce queuing latency.

https://github.com/bensheldon/good_job

> |> lock("FOR UPDATE SKIP LOCKED")

https://github.com/sorentwo/oban/blob/8acfe4dcfb3e55bbf233aa...

The suggestion from /u/tofus is a good one. If you are already using redis as your ActionCable adapter I would use sidekiq. If not and you're using postgres I would consider https://github.com/bensheldon/good_job

Probably worth mentioning that aside from delayed_job there are at least two more modern alternatives backed by the DB: Que and good_job.

Good article. Sidekiq is a good, well respected too. However if you are starting out I would recommend not using it, and instead choosing a DB based queue system. We have great success with que, but there are others like good_job.

Sidekiq Pro is great, we're paying for it! 10k a year I think.

But for people who are interested in alternatives, I'd also suggest Good Job (runs on Postgresql).

https://github.com/bensheldon/good_job

I'm the GoodJob author. Here's the class that is responsible for implementing Postgres's LISTEN/NOTIFY functionality in GoodJob:

https://github.com/bensheldon/good_job/blob/10e9d9b714a668dc...

That's heavily inspired by Rail's Action Cable (websockets) Adapter for Postgres, which is a bit simpler and easier to understand:

https://github.com/rails/rails/blob/be287ac0d5000e667510faba...

Briefly, it spins up a background thread with a dedicated database connection and doings a blocking Postgres LISTEN query returns results, and then it forwards the result to other subscribing objects.