Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

What's the difference between a stream and a queue? They both have the concept of an ordered set of elements, but tend to have different implementations and a different vocabulary of 'insert'/'extract' (streams) vs. 'enqueue'/'dequeue' (queue). Are these interchangable? Do they suggest different concepts or patterns? If so, what are the differences?

share|improve this question
Apparently "stream" refers to different things in different contexts. There are differences in characteristics between a character stream vs. Windows IStream interface in COM vs. an event stream in architecture speak. Can you clarify? – rwong May 24 '13 at 6:47

A stream is not really a data structure as such (conceptually), but is a sequence of digitally encoded coherent signals (packets of data or data packets) used to transmit or receive information". So basically a sequence of data.

A queue is a simple FIFO mechanism allowing you to add items to the back of the queue or take from the front.

Streams always have a source, e.g. a file, network location, etc. A Queue does not inherently contain any data.

So essentially they are quite different in concept and as Mason pointed out, they are used differently.

share|improve this answer
There's actually a data structure called "stream", with (effectively) a list of data to consume, with a producer function at its tail, callable if you need more elements. – Vatine May 24 '13 at 10:05
The Unix 'yes' command looks like a stream but has no particular data source. – JBRWilkinson May 24 '13 at 10:18
@JBRWilkinson: Run without an argument, the data source for yes(1) is the embedded default string. Run with an argument, it's whatever provided the argument. – Blrfl May 24 '13 at 11:16
Yes, you're right - all data has to come from somewhere. Perhaps the actual point here is that a queue could be empty and a stream, by definition, is usually not? – JBRWilkinson May 25 '13 at 14:21
@JBRWilkinson: I suppose you could open a stream, send nothing through it and then close it. – Blrfl May 28 '13 at 12:35

In my experience, a stream is a sequence of bytes that are produced/consumed at rate often determined by data within the stream. For example, an MPEG data stream will have frame headers which describe what the next sequence of bytes does and how many need to be consumed. Binary serialisation of a document would be similar. It is not always self-describing : writing to STDOUT can be done in a stream-wise manner but it may be humanly-readable/non-parseable data.

Conversely, a queue is usually of a well-known type of object (or interface-supporting objects) that are consumed in their entirety. An example might be a queue of database jobs that are processed by a number of database workers.

share|improve this answer

The basic difference is in the way they're used. In a stream, you usually only use one side of the operation: you open a stream to read, or write, but not both. Whereas with a queue, you're putting items on and taking them off.

Also, queues are very strict about the order in which you put things on and take them off, while streams often (but not always) support a Seek operation, especially if you're reading from them.

share|improve this answer
FileStream can be opened in ReadWrite mode. – Robert Harvey May 23 '13 at 22:09
..and priority queues gives options about order – Petter Nordlander May 23 '13 at 22:27

A difference between a stream and a queue is the way data rate is controlled:

  • in a queue, the sender adapts to the speed of the reader. The sender decides what to do if the queue is full: wait for availability of queue or throw data away.

  • in a stream, the reader adapts to the speed of the sender, The reader decides what to do if new data arrives before old one has been consumed.

With that perspective, character streams such as Unix pipes would not qualify as streams but as queues.

share|improve this answer
In adaptive video streaming, the server will adjust to a lower fidelity stream because the client isn't keeping up. – JBRWilkinson May 24 '13 at 10:17
@JBRWilkinson - In adaptative video streaming, the server just sends multiple variants of a stream at different bit rates. This is still the responsibility of the client to choose among these streams. – mouviciel May 24 '13 at 11:20
Yeah, HTTP streaming does that. I meant video calling which is point-to-point and the data isn't pre-encoded. My bad - I should've been explicit. – JBRWilkinson May 25 '13 at 14:29
The intention of a character stream is that the data is consumed more-or-less as it is produced: it is a flow of data rather than a means of holding it. We know that this is not perfect in practice, but from a metaphorical standpoint it is expected to be true: the reader can process the stream as fast as it comes in. – user186205 Dec 1 '15 at 17:06

In functional programming languages (e.g. Scala), and maybe other languages as well, streams are really more like functional lists and they are queues. I should note, however, queues can actually be implemented using a pair of lists. In Scala and probably elsewhere, a Stream is just a lazy List - more specifically, the tail of the list is a lazy val.

Functional streams can share some similarity with queues, as opposed to, lists, in that you can use them in a way that you don't keep a reference to the head of the stream - but you have to be careful: This is somewhat analogous to a dequeue call to a queue (although in the case of a stream, you do so implicitly:

share|improve this answer

If we think more visually about how the words are commonly used, we can avoid the clutter of specific uses by particular languages and implementations, so that these terms can actually mean something:

  • A queue of people waits in line and are served one by one. More people join the queue at the tail. Everyone waits as service proceeds and the service time is expected to vary. You can speak of how many people are served in total.
  • A stream of people, for example leaving a building through a door, are not served one by one, they just pass the exit point at a more-or-less steady rate. Delays are not expected and not well tolerated. You can speak of a rate of people: one per second.

That is the intention of these terms. They are metaphors. (like everything else) (Shhh! you'll ruin the story!)

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.