Я бы посчитал, что СУБД относится к программному продукту в целом - PostgreSQL, Oracle, DB2 и т. Д.
Однако это большие и сложные продукты. Как обычно для сложного программного обеспечения, они делятся на компоненты, каждый со своей специфической функцией и с четко определенными интерфейсами между ними. Один компонент будет иметь дело с проверкой и анализом SQL; один будет заботиться о памяти; другой будет обрабатывать IO и так далее. Этот последний - IO - часто называют механизмом хранения, я полагаю, потому что он «выводит» данные на диск и с диска. Почему это называется механизмом, а не компонентом или подсистемой, можно только догадываться.
Для этих имен не существует стандарта ISO. Таким образом, любой поставщик, академик или блогер может свободно использовать, повторно использовать и определять термины по своему усмотрению.
Некоторые СУБД допускают множество компонентов ввода-вывода, каждый из которых реализует разные технологии. MySQL имеет InnoDB и MyISAM. MongoDB имеет WiredTiger и MMap. SQL Server имеет разные форматы на диске и закулисные алгоритмы, если данные находятся в «обычных» таблицах, таблицах в памяти или имеют индекс columnstore. Их можно рассматривать как разные механизмы хранения, если эти термины выберет автор.
Поскольку основной целью СУБД является хранение и извлечение данных, легко увидеть, как часть хранения может стать синонимом продукта в целом. С этой точки зрения другие компоненты рассматриваются как вспомогательные для хранения. Возможно, это было правдой однажды. В современных системах, которые поддерживают сложную аутентификацию, многомодельные API и хранилище только для памяти, я думаю, что это больше не будет оправданно.