Array or object — which one to pick for your data

There's a one-sentence rule, and it settles almost every case. Say out loud how you look your record up.

Said "the third one in the list" — you want an array. Said "the one with id 7" — you want an object.

Sounds minor, and the price difference is enormous: across ten thousand records an object finds the right one roughly a thousand times faster. Below: why, and when that stops being theory.

How they differ

An array is values in order, numbered from zero. Access by number:

const cart = ["tea", "honey", "lemon"]
cart[1]   // "honey"

An object is values under names. No order, but it has keys:

const user = { name: "Anya", city: "Almaty", plan: "pro" }
user.city   // "Almaty"

Two ways to hold a lot of things. An array answers "which ones exist and in what order". An object answers "what do we know about this one thing".

The breakdown by criteria

Order. An array has it and it matters: a feed, a message history, the steps of a recipe. An object has no order — you can't rely on it, keys don't stand in a queue.

How you fetch. From an array, by number — but you usually don't know the number. From an object, by key name — and you always know the name: user.email reads without a hint.

Duplicates. An array can hold the same value three times. Object keys are unique: write plan twice and the second one silently overwrites the first.

Search speed. This is the big one. To find the record with a given id in an array, you walk the items one by one until something matches. Ten thousand records, up to ten thousand comparisons. An object works differently: it computes the key and jumps straight to the value in one step, no matter the size.

How many things. An array is about many of the same kind. An object is about one thing with different fields.

Who should pick what

No fence-sitting.

• A list of anything you'll show on screen — array. Products, tasks, messages, search results. Order matters, looping is easy, and map turns the list into cards.
• One entity with properties — object. A user profile, app settings, a single order. The fields differ and have human names.
• A lookup table you hit by key — object. Exchange rates, interface translations, settings by name. This is exactly where search speed decides it.
• Anything going through an API — usually an array of objects. It's the standard response shape: [ { id: 1, ... }, { id: 2, ... } ]. Open any JSON and you'll see it.

That last point settles half the arguments: in practice it isn't either-or. An array of objects is the most common structure in AI-written code, and it honestly combines both.

The trick that saves you an evening

If you look things up in an array by id a lot, stop scanning — turn the list into an object once:

const byId = {}
for (const item of items) {
  byId[item.id] = item
}
byId[7]   // instant

The scan happened once, while building. Every lookup after that is a single step. It's a classic list optimisation and worth knowing before you need it.

One caveat: at a hundred items you won't notice any difference. It starts to matter where you search many times inside a loop — that's when "a scan inside a scan" turns a hundred records into ten thousand comparisons.

And an honest boundary: if there's genuinely a lot of data and it needs to outlive the page, that's a job for a database, not an in-memory structure. Arrays and objects live only while the page is open.

Isn't an array also an object?

In JavaScript, technically yes: typeof [] returns "object". But they behave differently and in practice they're kept apart. Check with Array.isArray(value) — it's the only reliable way.

Which is faster to add to?

Appending to an array and writing a key on an object are equally cheap. The difference shows up in searching, and in inserting at the front of an array, where every item has to shift over.