ibrar74

I wrote this after shipping multiple RAG systems that broke in production. This post focuses on architecture choices, failure modes, and tradeoffs. No prompt tricks. No hype. Feedback from people running RAG in production is welcome.

I am one of the authors. This post explains how we implemented vector search directly inside PostgreSQL, including index design, query execution, and operational tradeoffs. The goal is to keep embeddings and search close to the data instead of adding another external service. Happy to answer technical questions.

This post explains why we still run AI workloads close to the database in some production setups. The focus is on data gravity, latency, compliance, and operational cost, not on rejecting the cloud outright. Cloud works well for many teams, especially early on. This piece documents cases where on-prem or hybrid setups stayed cheaper, more straightforward, or more predictable once vector search, embeddings, and retrieval moved into the data plane. Feedback and counterexamples welcome.

NeuronDB runs vector storage, similarity search, and RAG primitives directly inside PostgreSQL. The goal focuses on keeping embeddings, metadata, and query planning in one system. The repository includes a PostgreSQL extension, vector indexing logic, and SQL-first query patterns. Feedback on design tradeoffs, performance behavior, and failure modes under load would help.

This article does a good job separating model capability from system behavior. One point worth emphasizing is that most real failures come from the surrounding system, not the model itself. Tokenization choices, context truncation, retrieval quality, and update frequency often dominate output quality more than model size. In production, debugging usually means tracing data flow and state, not tuning prompts.

It is valid syntax, you are comparing an "x" with "no value" and result will be "no value"

Yes, that's the problem this blog try to explain. NULL means "no value", but this is not true for all the languages. So you better know what is the value of NULL in the language you are trying to use.

What do you mean by never set? In the database, you can either enter a string (empty or non-empty) or NULL in a column. There no such thing called never set.

Actually this blog is not about how many ways you can use NULL in the database. It's all about the people who have programming experience (C/C++/JAVA) and try to write the SQL queries.

Thanks for reading that.

It is not outdated, it has less information. The parallel joins is a bigger topic itself. In this blog, I want to give a brief introduction about parallelism in PostgreSQL.

I will definitely read what you suggested. But keep in touch I will post more blogs for each sub-topic to cover it all.

Great Post

Do you have sample sql script and paste what error you are getting?