Data Structures Explained: The 7 You Need and When to Use Each

by Souy Soeng /October 02, 2026

Diagram of seven data structures: array, linked list, stack, queue, hash table, tree and graph

Data structures, explained simply, are ways to store and organize information so a program can use it quickly. This guide covers the seven big ones: arrays, linked lists, stacks, queues, hash tables, trees and graphs. It uses everyday examples instead of math.

Why care? Two apps can hold exactly the same data on the same phone, and one feels instant while the other stutters. The difference is often how the data is arranged. By the end, you'll know how each structure works, what it's good and bad at, and how to match it to the job.

In short

A data structure is a way to store and organize data so it's fast to use.
Every structure trades speed at finding things against speed at changing things.
Arrays suit access by position, hash tables suit lookups by name, stacks put the newest first and queues put the oldest first.
Trees model hierarchies, and graphs model networks of connections.
Pick the structure by asking what your app does with the data most often.

What is a data structure, and why does it matter?

A data structure sounds academic, but it's the same instinct you use when you sort socks into a drawer instead of throwing them in a pile. Think of a library that shelves books by category so you can find one in seconds. The shelving system is the data structure. Every structure is just a different shelving plan.

It matters because the wrong plan makes apps slow. Picture a search box that lags after every letter. Very often that app checks every item one by one instead of jumping straight to what it needs. With ten test items nobody notices. Once real users add thousands of photos, messages or contacts, the app crawls. Slow apps get uninstalled, drain batteries and cost companies money on servers.

No structure is best at everything. Each one balances two kinds of work: finding data (grabbing an item, looking something up, checking whether it exists) and changing data (adding, removing, inserting into the middle). Gaining speed in one usually costs speed or memory somewhere else. So the real question is what your app does most. A contacts list is searched constantly but rarely changes. A chat feed gets new messages all the time.

Finding: access by position, lookup by key, existence checks
Changing: adding, removing, inserting in the middle
No free lunch: faster at one job usually means slower at another

Arrays vs linked lists: which should you use?

An array is like a row of numbered lockers, starting at zero, sitting side by side in memory. In a small array of songs, 'Intro' is slot zero and 'Drop' is slot two. Ask for slot two, and the computer does a quick calculation and jumps straight there. That takes one step whether the array holds three items or three million. This is why playlists, photo grids and leaderboards use arrays.

The weakness shows up when you insert in the middle. To add a new song at position one, every item after it has to slide one slot to the right before the new song fits. With a hundred thousand songs, that's a hundred thousand moves to add one thing. Deleting has the same problem in reverse.

A linked list fixes this. Its items can sit anywhere in memory, and each one carries a pointer to the next. To insert after 'Intro', you rewire two pointers and nothing else moves. The price is that you can't jump by index. To reach item 500, you follow the chain from the start. In practice, arrays are the everyday default. Most lists are read far more often than they're edited, and computers read memory that sits close together especially fast. Linked lists earn their place when the middle of the list changes constantly.

Array: instant access by position, compact memory, slow inserts in the middle
Linked list: cheap inserts and deletes, slow to reach a far item

# a row of numbered slots
let songs = ['Intro', 'Hook', 'Drop'];

# grab any spot instantly by index
songs[2];   # -> 'Drop'

Stacks and queues: last in first out vs first in first out

A stack works like a pile of cafeteria plates. You add to the top and take from the top. It has only two moves: push adds an item and pop removes the most recent one. Both are instant because you only ever touch the top. Undo is a stack, since each action is pushed and Undo pops the latest one. Your browser's Back button is a stack of pages, and programs use a stack to track function calls.

A queue is the coffee-shop line. New items join the back, which is called enqueue, and leave from the front, which is called dequeue. When three people hit Print at once, the jobs come out in the order they were sent. Chat messages, downloads and background tasks on servers wait their turn in queues the same way.

To tell them apart, ask one question: should the newest thing be handled first, or the oldest? Picking wrong creates strange bugs. Use a queue for Undo, and pressing it would reverse your very first edit from an hour ago instead of your latest typo.

Stack (LIFO): newest out first, like plates, Undo and Back
Queue (FIFO): oldest out first, like a line, printing and messaging

# every edit is pushed on top
undo.push('typed hello');
undo.push('made it bold');

# Undo pops the newest action
undo.pop();  # -> 'made it bold'

How do hash tables work?

Arrays let you jump by number. Hash tables let you jump by a name. They store key-value pairs, such as a word and its definition. When you look up 'banana', a hash function turns that word into a number, say seven, which tells the computer which bucket to check. There's no searching, just one jump.

This works because the hash function is consistent. 'Banana' always becomes the same number, so the value saved in bucket seven is found in bucket seven later. That's why dictionaries, usernames, settings and caches of recent results rely on hash tables.

There are limited buckets and endless possible keys, so sooner or later two keys collide. If 'banana' and 'cherry' both land in bucket seven, the bucket keeps a small list holding both. Good hash tables also grow when buckets get crowded and spread items out again. A poor hash function that dumps most keys into one bucket turns an instant lookup back into a slow scan.

Trees: organizing data in hierarchies

Lots of real data has levels, and trees handle that. A tree starts with one item at the top called the root. The root has children, those children have their own children, and items with no children are called leaves. Every item has exactly one parent. The folders on your computer are a tree: Documents at the root, School and Photos inside it, and your files inside those.

Trees also speed up search. In a sorted tree, smaller items go left and bigger ones go right. Each step down cuts the remaining options in half, like a higher-or-lower guessing game. Beyond folders, you'll find trees in web page layouts, company org charts and nested comment replies.

# your computer's folders are a tree
Documents/
  School/
    essay.docx
  Photos/
    beach.jpg

Graphs: modelling networks of connections

A graph removes the tree's one-parent rule. It's a set of points called nodes, joined by links called edges, with no root and no hierarchy. Any node can connect to as many others as it likes. In a small friend network, you know Maya and Leo, Maya knows Aisha, and Aisha knows Sam. A 'people you may know' feature follows edges two steps out to find suggestions.

Maps are graphs too. Intersections are nodes and roads are edges, often tagged with distance or traffic. Getting directions means searching that graph for the best path. Use a graph when the connections themselves are the information, and your question is 'how is this linked to that?'

One chat app, five data structures

Sending one message touches most of these structures. When you search for Maya, the app uses her name as a key in a hash table and jumps straight to her contact, so results appear as you type. Each edit you make is pushed onto a stack, so Undo reverses your latest typo.

When you hit Send, the message joins a queue, so three quick messages arrive in the right order. The conversation on screen is an ordered list, like an array, which keeps scrolling smooth. The 'people you may know' suggestion comes from a friends graph. Good apps mix structures and use the best fit for each job.

To choose for your own code, describe in one plain sentence what it does most with the data. Then match it: by position means an array, by name or ID means a hash table, newest first means a stack, and oldest first means a queue. Data with levels and parents fits a tree. Data where anything links to anything fits a graph.

Common mistakes that make code slow

The dangerous mistakes don't crash anything. The code runs, the answer is correct, and tests pass. The classic case is checking whether a name is in a big list, which means looking at every entry. Store the same names in a set, which works like a hash table, and the check becomes a single jump. The answer is the same, but the speed is very different.

Watch for these patterns: searching a plain list over and over, constantly adding to the front of a big array, and testing with only a handful of items. The cost of a bad structure isn't fixed. With a slow approach, doubling your data can double the work or worse. With a good structure, doubling it might barely matter. With ten items anything works, but with millions your choice is everything.

Repeated lookups in a list: switch to a hash table or set
Frequent inserts at the front of an array: rethink the structure
Tiny test data: test with realistic, large amounts early

# slow: checks every name one by one
bannedList.includes(name);

# fast: jumps straight to the key
bannedSet.has(name);

How to practice data structures as a beginner

Start with what your language already gives you. JavaScript and Python come with lists, sets and dictionaries built in. Build a small to-do app or a word counter and use each structure on purpose.

Next, use pen and paper. Draw an array as boxes, a linked list as boxes with arrows, and a tree as branches, then act out an insert to see what moves. Finally, write your own stack or queue from scratch. It takes only a few lines, and once you've built one, you won't forget how it works or when to use it.

Key takeaways

Arrays: grab any item instantly by its position.
Linked lists: insert anywhere without shifting other items.
Stacks put the newest item first, and queues put the oldest first.
Hash tables jump straight to data by key.
Trees model levels, and graphs model connections.
One rule ties them together: match the structure to the job.

Frequently asked questions

What is a data structure in simple terms?

It's a way to store and organize data so a program can use it quickly. Think of it like a library's shelving system, which lets you find a book in seconds instead of searching a pile.

What is the difference between a stack and a queue?

A stack is last in, first out, so the newest item is handled first, as with Undo. A queue is first in, first out, so the oldest item is handled first, as with a print queue.

When should I use a linked list instead of an array?

Use a linked list when you constantly add or remove items in the middle of a sequence. For most everyday lists, which are read far more than they're edited, an array is the better default.

Why are hash tables so fast?

A hash function turns each key into a number that points to a specific bucket, so the computer jumps straight there instead of searching. They stay fast as long as keys spread evenly across the buckets.

What's the difference between a tree and a graph?

In a tree, every item has exactly one parent under a single root, which makes trees good for hierarchies like folders. A graph has no root, and any node can connect to any other, which suits maps and social networks.

How do I choose the right data structure?

Ask how you'll mostly use the data: by position, by name, newest first, oldest first, in levels, or as connections. That answer usually narrows seven options down to one or two.

Watch the full video on YouTube →

Tag

Ad