Q: Vector database vs relational database — what's the difference in practice?

They answer different kinds of questions. A relational database (Postgres, MySQL) answers exact questions about structured data: "all orders over $100 in July," matched precisely, joined across tables with SQL. A vector database answers similarity questions about meaning: "the chunks of text closest in meaning to this query," ranked by how close.

Neither replaces the other, and real AI applications typically run both: the relational database holds your users, orders, and application data, while the vector database holds document chunks with their embeddings for retrieval. The line is even blurring — pgvector, a popular extension, adds vector search inside Postgres, which is often the simplest production choice if you already run Postgres.

If you come from the database world, here's the translation. Schema design becomes embedding decisions: which embedding model, how big your chunks are, one vector per item or several. Indexing for query speed becomes approximate-nearest-neighbor indexing, which the vector database handles for you. And the unglamorous parts of your discipline (governance, access control, knowing where data came from) transfer completely, and are easier to get wrong in a young technology.