Beyond Tables: Graph, Vector & Modern Databases Explained
When relationships are the data (graphs) or meaning is the query (vectors) — plus how Graph RAG ties it all together.
- databases
- graph
- vector
- guide
Tables are great — until they aren't
Relational tables dominate because most business data is neat rows. But two workloads break the mold: deeply connected data (friends, fraud rings, supply chains — where JOINs spiral) and meaning-based search (find docs like this one — where keywords fail). Graphs and vectors are the answers.
New to databases entirely? Start with our Database Fundamentals guide, then come back.
The ideas that matter most
- Graph databases — store entities already connected. Traversing relationships is a walk, not a 7-table JOIN.
- Cypher — the pattern-drawing query language: describe the shape, get every match.
- Traversal & pathfinding — shortest paths, ripples, recommendations: the algorithms that make graphs powerful.
- Vector embeddings — meaning as coordinates. Similar meanings point the same way.
- Vector databases — nearest-neighbor search over billions of vectors in milliseconds. The memory layer of every RAG system.
- Graph RAG — documents become a knowledge graph; answers come from walking to them. Retrieval with reasoning baked in.
A sane learning order
- Connections (graph-db → cypher-basics → graph-traversal)
- Meaning (vector-embeddings → vector-database)
- Fusion (graph-rag)
Go interactive in our Databases course.
Mistakes beginners make
- Graphs for everything. Tabular, aggregatable data (orders, revenue) belongs in relational tables — graphs win on traversal, not reporting.
- Vectors as the only retrieval. Exact matches (IDs, codes) need keyword/BM25 alongside — see hybrid search.
- Embeddings without evals. "Similar" is task-dependent; measure retrieval quality on your data, not vibes.
- Ignoring the graph you already have. Foreign keys are a graph — sometimes the leap is modeling it explicitly, not new infrastructure.
FAQ
Graph vs relational — how do I choose? Relational for structured records and aggregations; graph when queries are about connections (paths, neighborhoods, patterns) more than a couple of hops deep.
What are embeddings, really? A model converts text into a long list of numbers (a vector) positioned so similar meanings sit near each other. "King − man + woman ≈ queen" is the classic demo of that geometry.
Do I need a dedicated vector database? At small scale, Postgres with pgvector is plenty. Dedicated engines earn their keep at billions of vectors, heavy filtering, or strict latency SLAs.
What is Graph RAG? Instead of retrieving text chunks, you build a knowledge graph from documents and retrieve by walking relationships — multi-hop questions ("who funded the founder of X?") that chunk retrieval fumbles.