---
title: "Row-oriented storage"
description: "Row-oriented storage is a data layout that stores each record's fields contiguously on disk, so a whole row can be read or written in a single operation."
canonical: "https://motherduck.com/glossary/row-oriented-storage/"
related:
  - title: "DuckLake Architecture Deep Dive"
    url: "https://motherduck.com/blog/ducklake-architecture-deep-dive/"
  - title: "Database Concepts | MotherDuck Docs"
    url: "https://motherduck.com/docs/concepts/database-concepts/"
  - title: "Why Use DuckDB for Analytics?"
    url: "https://motherduck.com/blog/six-reasons-duckdb-slaps/"
gated_asset:
  title: "DuckLake on MotherDuck"
  url: "https://motherduck.com/product/ducklake/"
---

# Row-oriented storage

> Row-oriented storage is a data layout that stores each record's fields contiguously on disk, so a whole row can be read or written in a single operation.

## Overview

In a row-oriented (or "row store") layout, all the fields belonging to one row are physically stored next to each other. Reading or writing a full record — say, one customer's name, address, and account balance — touches one contiguous block of data. This is the layout used by classic transactional databases like PostgreSQL and MySQL in their default heap storage.

<glossary-callout guide="duckdb-book-brief" />

## Row vs. Column Layout

Row storage shines for workloads that fetch or modify individual records: an application looking up "customer 4821" and updating one field wants exactly the pattern row storage provides — a single, localized read or write. The trade-off shows up in analytical queries: computing an aggregate over one column across millions of rows means reading every row's full width from disk even though only one field is used, wasting I/O on data the query never needed.

## When Row Storage Wins

Row-oriented storage generally wins for OLTP (online transaction processing) workloads: high-volume, small reads and writes touching most or all columns of a few rows at a time — placing an order, updating a user's profile, appending an event. It's a poor fit for wide-scan, few-column analytical queries, which is why data warehouses and analytical engines favor columnar storage instead.

## DuckDB's Perspective

DuckDB is not a row-oriented database — it's built as a columnar, vectorized engine specifically for OLAP-style analytical workloads. If your workload is dominated by single-row lookups and frequent small updates, a row-oriented database is typically the better fit; DuckDB is designed to complement, not replace, that kind of system by handling the analytical queries run over the same data.