I recently worked on a system that was initially built using pgvector, where vector embeddings were stored alongside their corresponding text data in a Postgres database. This approach has some clear advantages. First, it simplifies data consistency. Inserts, updates, and deletes can be handled in a single transaction, making it straightforward to keep embeddings and

Retrieval-augmented search sounds clean: retrieve, then generate from what you retrieved. In practice, both steps are sensitive to what was in the query string. If a user’s wording encodes race, gender, age, religion, or similar dimensions—and the system blindly embeds that string, filters on it, or asks an LLM to paraphrase it—you get two problems at once: outcomes can track attributes you never meant to

When building a new system, it’s easy to focus on core functionality first—APIs, data models, and business logic—and leave concerns like rate limiting for later. But rate limiting isn’t just a “nice to have.” It directly impacts system stability, cost control, and tenant isolation. While designing a recent system, I had to decide early on:

I have recently been working on an AI-native search software based on a RAG framework. The system treats each indexed JSON document as an entity with relationships that point at other entity items via unique IDs. Those links are normalized into a tenant-scoped graph: stored edges, reverse indexes for “who points at whom,” Redis caches

Healthcare-facing search sits in an awkward place: you might not be building an EHR, but queries and indexed content can still look like PHI — names in a search box, provider directories that resemble patient-adjacent workflows, snippets flowing to logs and third-party APIs. HIPAA’s technical safeguards are about access, audit, integrity, and transmission — not about ranking philosophy. One