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"

I know that it's a valid expression, but are there any use cases for it?

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.

That's my question, if you have a field that represents something and that field is a string that can be empty, null or contains anny string, if you don't use NULL how do you make the difference between an empty string and a null string ( user set "" vs never set anything )

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.