1. "Vector database" is two different philosophies. Chroma exists only to do vector search. pgvector is a plugin that teaches your existing Postgres to do it. If an enterprise already runs Postgres (most do), pgvector means one fewer system to back up, secure, and monitor — vectors live in the same row as your normal data. That "reuse what you already operate" instinct is very familiar to anyone from ops.
2. The distance metric is a real decision, not a default. I proved to myself that cosine and L2 can rank the same vectors differently — two vectors pointing the same direction but different lengths were "identical" to cosine and "far apart" to L2. For text embeddings (where meaning lives in direction, not magnitude), cosine is usually the honest choice. With normalized embeddings like MiniLM's, they converge — so metric choice becomes a cost decision.
3. The index is where my infra brain lit up. Brute-force search is O(n) per query — fine for 5 rows, a problem at millions. The two approximate-nearest-neighbor indexes trade a little recall for big speed:

• IVFFlat — clusters the space, searches only the nearest clusters. Cheap memory, but goes stale as data grows → needs rebuilds.
• HNSW — a navigable graph you "walk" toward the query. Faster queries, graceful inserts — but the link graph lives in RAM, so at tens of millions of vectors it becomes a real cost line item.

The architect's call: default to HNSW for query performance and streaming inserts; reach for IVFFlat when memory/cost at scale dominates or the corpus is static. Same recall-vs-speed-vs-cost tradeoff I've made a hundred times in other systems — just a new runtime.

The through-line: a vector store is a distributed system with the same old tradeoffs — memory, cost, freshness, latency. The vocabulary is new; the engineering judgment isn't.

Hand-built and measured myself (AI-assist off while I learn). Code in my public ai-fundamentals-lab.(https://github.com/srivastava-adarsh/ai-fundamentals-lab)

But here's an honest admission: when it comes to AI systems, I've mostly been a user. I can wire things together and get results. What I couldn't always do was explain, from first principles, why they work — or defend the design decisions under hard questioning.

I decided that wasn't good enough. So I'm changing it, in public.

Why now

AI isn't a side technology anymore; it's becoming part of how everything gets built. As someone who has always understood the systems I work with at a deep level, being a surface-level AI user started to feel like a gap I didn't want to carry.

I don't want to just use retrieval-augmented generation, agents, and embeddings. I want to understand them well enough to design them, reason about their trade-offs, and explain them to a room of skeptical engineers. That's a different bar — and it's the one I'm aiming for.

The approach: learn by building, in public

A few rules I've set for myself:

• Build from primitives. Before reaching for a framework, I write the basic version by hand so I actually understand what the framework is doing for me.

• AI-assist off while learning. It's tempting to let AI generate the code. But the whole point is to understand it, so during learning I type it myself — and debug my own mistakes.

• Document everything. Every step goes into a public repo and a learning log. If I can't explain it, I don't really know it.

• Low drama, steady pace. About an hour a day. Consistency over intensity.

Everything lives here: github.com/srivastava-adarsh/ai-fundamentals-lab

Week 1: back to fundamentals

I started where it makes sense for someone rebuilding hands-on muscle — Python fundamentals, framed around things I'd actually use for AI work.

In the first week I:

• Rewrote an operations shell script (a disk-usage checker) in Python — learning variables, running shell commands from code, parsing output, and handling real-world edge cases where the data isn't as clean as you'd like.

• Worked through lists and dictionaries, and built the exact data structure that every LLM API uses to represent a conversation (a list of {"role": ..., "content": ...} messages).

• Refactored my code into reusable functions — separating computing a result from displaying it.

• Handled files and JSON: the load → modify → save cycle that underpins config and API data.

Along the way I hit every classic beginner bug — indentation that changes your logic, booleans that must be capitalized, a stray shell-style $ where a % belonged. Debugging those myself was the point.

What's next

From here the plan moves outward:

• Calling APIs from Python

• Building a small wrapper to talk to a language model programmatically

• Retrieval and embeddings — understanding semantic search by building it

• Agents and tool use

• Evaluation, observability, cost, and safety — the things that separate a demo from a production system

I'll write these up as I go — including what breaks, because that's usually where the learning is.

Why write it down

Two reasons. First, explaining something forces me to actually understand it. Second, I think there's value in showing the unglamorous middle of learning — not a polished expert, but an experienced engineer deliberately rebuilding a skill in the open.

If you're on a similar path — experienced in one area, deliberately going deep in another — I'd genuinely like to hear how you're approaching it.

More soon.