A computed field has a value worked out by a computation. There is a further choice: whether that value is stored. This piece is about stored versus non-stored computed fields in Odoo.
The choice: stored or not
When a developer defines a computed field, there is a choice: the computed field can be stored or non-stored. A stored computed field has its computed value kept, stored in the database, and recomputed and re-stored when its dependencies change. A non-stored computed field does not keep its value; the value is computed when it is needed, on the fly. Both are computed fields, the value worked out by the computation; the difference is whether the result is kept or recomputed each time it is needed.
The trade-off
The choice between stored and non-stored is a genuine trade-off. A stored computed field has its value readily available, kept in the database, which is faster to access when needed, and, importantly, it can be used in ways that a value not in the database cannot, such as being searched or grouped on. The cost of stored is that the value is kept and has to be recomputed and re-stored as dependencies change, which is work and uses storage. A non-stored computed field does not keep the value, so there is no storage and no re-storing, but the value has to be computed each time it is needed, and it cannot be used in the ways that need the value to be in the database. So stored trades some computation-and-storage cost for the value being readily available and usable in more ways; non-stored trades those abilities away to avoid keeping the value.
When to choose stored
A developer should choose a stored computed field when the value genuinely needs to be readily available or used in the ways that need it in the database. In particular, if the computed field needs to be searched on, or grouped on, or otherwise used in a way that requires the value to be in the database, it must be stored, since a non-stored value is not in the database to be used that way. And if the value is accessed often, storing it, so it is readily available rather than recomputed every time, may be the better trade.
When non-stored is fine
A non-stored computed field is fine, and the simpler choice, when the value does not need to be searched or grouped on or otherwise used in the database, and is not accessed so much that recomputing it each time is a real cost. For a computed field that is simply displayed when a record is looked at, and does not need to be searched on, non-stored is often perfectly appropriate, the value is computed when the record is shown, and there is no need to keep it.
Choose deliberately
An honest note. Whether a computed field is stored or non-stored is a deliberate choice a developer should make consciously, based on how the field will genuinely be used, does it need to be searched or grouped on, how often is it accessed, not made carelessly. Stored where the value genuinely needs to be in the database or is heavily used; non-stored where it does not and is not. Choosing deliberately means the computed field is stored or not for a genuine reason.
The takeaway
Stored versus non-stored computed fields in Odoo is the choice of whether a computed field's value is kept in the database. A stored computed field has its value readily available and usable in ways that need it in the database, such as being searched or grouped on, at the cost of keeping and re-storing it. A non-stored computed field recomputes the value when needed, avoiding keeping it but losing those abilities. Choose stored where the value genuinely needs to be in the database or is heavily used, non-stored where it does not, and choose deliberately. For how we approach Odoo, see our ERP practice.