Databricks mapped the data world into five main territories. The interesting part is what happens when those worlds start to meet.
I liked how Databricks laid out the data world recently. They described it as a set of five main territories, almost like fiefdoms in a larger realm.
Here they are.
And yes, there was also the catch-all world of niche databases sitting at the edges of the map.
This framing is simple, but it is useful. It shows how broad the data landscape really is. These are not small categories. Each one represents a different need, a different kind of work, and a different way an organisation turns data into value.
The bigger story is what happens when these worlds start coming closer together. That is where modern data platforms get much more interesting. Let us walk the map slowly first, then talk about the borders.
When you are new to data, every tool looks like a separate thing to learn. Postgres, Spark, a warehouse, a streaming engine, a vector store. The list never ends, and it feels like memorising names.
A map helps because it changes the question. Instead of asking "which tool is this," you ask "which territory am I standing in, and what does this place need." Tools come and go. Territories stay surprisingly stable.
So before we look at any single technology, let us understand the five places and what each one is really for.
OLTP means online transaction processing. This is the land of the systems of record.
When you place an order, update your profile, or move money between accounts, an OLTP database handles it. The work is made of many small operations that must be fast and correct. A few rows in, a few rows out, all the time, with no mistakes.
These databases care most about getting one record right, right now. They are tuned for quick reads and writes on small amounts of data. Think of a busy front desk that handles one visitor at a time, very quickly, all day long.
This is where most business data is born. It is accurate and fresh, but it is not shaped for big questions across millions of rows. That is a different territory.
Data engineering is the land of movement and shape.
Raw data is rarely ready to use. It arrives from many systems, in many formats, with gaps and surprises. Data engineering is the work of moving that data, cleaning it, joining it, and making it trustworthy enough for others to build on.
This is where pipelines live. This is where you decide what "a customer" means, how late data is handled, and how a number you report today still makes sense next month.
People sometimes think the hard part of data is the fancy model at the end. In practice the hard part is here. If the foundation is messy, everything built on top of it wobbles. Good data engineering is quiet, but everything else depends on it.
Data science is the land of learning from data.
This is where you look for patterns, test ideas, and build models that predict or classify. It is curious work. You form a question, try an approach, measure it, and try again.
Data science needs room to experiment and access to clean, well-organised data. When the engineering territory is healthy, this work moves fast. When it is not, data scientists spend most of their time fixing data instead of learning from it.
That dependency is a hint about the borders we will talk about soon. Data science cannot stand alone. It leans heavily on the territory next door.
The data warehouse is the land of business questions at scale.
Here the goal is to ask things like "how did sales change by region this quarter" or "which products are growing." These questions touch large amounts of data and need fast, reliable answers.
A warehouse is tuned for reading and summarising big tables, not for handling single small transactions. It is the opposite shape of an OLTP database. One is built for many tiny writes, the other for large, sweeping reads.
This is the territory where data becomes decisions. Dashboards, reports, and the numbers leaders trust usually come from here.
Real-time analytics is the land of acting while things happen.
Some questions cannot wait for tomorrow's report. Is this payment fraud. Is this machine about to fail. Should we show this user a different screen right now. These need answers in seconds, not hours.
This territory deals with data in motion. Events stream in continuously, and the system reacts as they arrive. The value here is speed of response, not depth of history.
Real-time work used to feel exotic and separate. More and more, it sits right beside the other territories, sharing the same data and the same definitions.
At the borders of the realm sits the catch-all world of niche databases.
Graph databases for relationships. Time-series databases for sensor and metric data. Search engines for text. Vector databases for similarity and modern AI features. Each one is excellent at a specific shape of problem.
These are not lesser places. They exist because some questions are awkward everywhere else. The point is to know they exist so you reach for them on purpose, not by accident.
For a long time these territories were genuinely separate, and for good reasons.
Each one was optimised for its own job. An OLTP database tuned for tiny fast writes is a poor fit for scanning billions of rows. A warehouse tuned for huge scans is a poor fit for handling one order at a time. Streaming systems were built around motion, while warehouses were built around history.
Different needs led to different designs. Different designs led to different tools. Different tools led to different teams, and often different copies of the same data.
So organisations copied data from one territory to another, again and again. Out of OLTP, through engineering, into the warehouse, off to data science, across to real-time. Every copy added delay, cost, and a fresh chance for the numbers to disagree.
That copying was the price of keeping the worlds apart.
Here is the part that makes modern platforms interesting. Those hard borders are softening.
The lakehouse idea is one clear example. Instead of one place for engineering and a separate place for the warehouse, you keep one well-governed copy of the data and let many kinds of work share it. Engineering, analytics, data science, and increasingly real-time work all read from the same foundation.
When the borders fade, the painful copying shrinks. You define what a customer is once. You govern access once. You trust one set of numbers instead of arguing about which export is correct.
This does not erase the territories. OLTP is still OLTP. A streaming question is still different from a historical one. The shapes of the work remain. What changes is the distance between them. You can move from one to the next without rebuilding everything in between.
That is the quiet revolution. Not a new tool, but a smaller gap between the worlds.
It is tempting to read this map as a list of products to learn. That is the wrong takeaway.
The real skill is recognising which territory a problem belongs to. When someone hands you a task, ask a few calm questions. Is this many small writes or a few large reads. Does it need an answer now or a deep look back. Is it about relationships, text, time, or similarity.
Once you know the territory, the right shape of solution becomes clear. The specific tool matters less than the fit.
The second skill is noticing the borders. Most real systems do not live in one fiefdom. Data is born in OLTP, shaped by engineering, summarised in the warehouse, learned from in data science, and sometimes acted on in real time. Your job is often to help it travel between these places safely, with its meaning intact.
A unified platform helps because it lowers the cost of that travel. But the platform only pays off if you understand the territories well enough to use it wisely.
This map is useful no matter where you work or which tools your company uses.
If you are starting out, it gives you a calm structure. You are not learning a hundred random tools. You are learning a small number of territories and the bridges between them.
If you are a software engineer moving into data, it explains why data systems feel different. You are used to OLTP thinking, fast and transactional. The warehouse and engineering territories ask you to think in large batches and shared definitions instead.
If you are already working in data, the map is a reminder to design for the borders. The hardest bugs and the longest arguments usually happen at the edges, where data crosses from one territory to another and quietly changes meaning.
Learn the territories. Learn where they blur. Then practise on a real platform until the map becomes instinct.
This way of thinking is the heart of what we do at BricksNotes.
Our book, Thinking in Data Engineering with Databricks, is built around understanding systems rather than memorising tools. The five fiefdoms are exactly the kind of mental map we want you to carry, because it stays true even as the tools change around you.
Everything in BricksNotes is practice first. You can explore these territories hands on using Databricks Free Edition, where engineering, analytics, and data science share one place. That is the lakehouse idea in your own hands, not just in a diagram.
If this map made the data world feel a little smaller and a little clearer, that is the goal. Start where the journey begins and build the intuition one step at a time.
Continue learning: start here with the first lessons.