SAP HANA Row Store vs Column Store: Which Tables to Check

Use column store for almost every table on SAP HANA. Row store is for narrow tables that your application reads one record at a time, and for a few cases SAP requires, such as global temporary tables. After an AnyDB-to-HANA move, the practical job is to list the row-store tables your system actually has, separate the deliberate exceptions from the accidents, convert only the accidents, and prove the change with regression and performance evidence.

What changed from AnyDB

On AnyDB you never chose a storage engine per table. On HANA you do, and the choice follows the table type. You do not have to specify which table store to use by selecting the keywords ROW or COLUMN. The COLUMN store is the default as of SAP HANA 2.0 SPS03, and is the recommended form of table to use in the vast majority of cases. Before that release, a CREATE TABLE statement without an explicit type produced a row table, and that caused real performance problems for analytic workloads. When tables are created as row types and used as Analytic workload, it had noticeable performance degradation compared to column store.

Several other AnyDB habits break on HANA, and they matter more than the storage type for most migrations. SAP HANA runs only on Unicode. Database hints are no longer executed on the new platform when you migrate to another database, and an exact check is always required for database-dependent SQL because errors may occur here unless you intervene. Native SQL that talks to a non-SAP database through DBLINK has to be rewritten, because there is no DBLINK in SAP HANA. Your ABAP custom code review (ATC with the performance and migration variants) is where these show up. See our guide on how to run remote ATC checks for S/4HANA custom code for the mechanics.

Row store vs column store: the working rules

The distinction is about how the engine lays out data. Column store keeps each column's values together, which helps aggregations, scans over a few fields and compression. Row store keeps each record together, which suits reading or writing a whole record. The table below is a working summary of what the SAP sources support.

Question	Column store (default)	Row store (exception)
Typical use	Master and transaction data, anything aggregated or scanned	Frequent single-record reads and writes, small configuration tables
Compression	High, because similar values sit together	Little; distinct values compress poorly
Memory at startup	Loaded on demand, column by column	Kept in memory from startup, whether used or not
Partitioning	Supported	Not supported
Global temporary tables	Not used	The only option

The ABAP side has its own rule. The ABAP keyword documentation says the row store setting should only be used in SAP HANA databases if the database table is used mainly for frequent single row accesses. It also notes that the fixed storage type is set when pooled tables and cluster tables are transformed to transparent tables. For pooled and cluster tables, column store is usually the recommended type here. A community answer adds a useful warning for the other direction: a table that should have been column store but which was defined as row store is more damaging to performance than a table that should have been row store but which was defined as column store.

Step 1: Find the row-store tables in your system

Start with the HANA system views, not with SE11. The two monitoring views are M_RS_TABLES, which lists row-store tables, and M_CS_TABLES, which lists column-store tables. If you want to check Row store information, please check table M_RS_TABLES, it contains all row store tables. Besides, if you want to check column store information, please check M_CS_TABLES, it contains all column store tables. Filter on your ABAP schema so you do not chase tables from other schemas or from BW and other add-on content.

Then compare with the ABAP dictionary. The table DD09L holds the technical settings of each table, and the field ROWORCOLST shows whether it is row or column. Also to see to what store type a particular table is set; see table DD09L (DD: Technical settings of tables) and its field (ROWORCOLST - For distinction between Row or Column Store) in particular. Any table that is row in both views is a deliberate or inherited choice to review. Any table that is row in the database but column in DD09L, or the reverse, is a drift you need to explain before go-live.

SAP's own report for this job is RSDU_MOVE_TO_COLUMN. A 2017 blog describes its check-only mode, where a list of biggest row store tables is provided. The report was written for the BW and NetWeaver migration path, so confirm its current behavior and the relevant SAP Note for your release before you rely on it in a sign-off pack.

Step 2: Classify every exception

Do not convert tables in bulk. Sort the row-store list into three groups.

• Keep as row: global temporary tables (the engine allows only row for these), and small configuration or queue-style tables that your application reads one record at a time.
• Convert to column: large master or transaction tables, and any table your reports aggregate or scan on a few fields.
• Investigate: tables with conflicting settings between M_RS_TABLES and DD09L, and any table referenced by a view, a BW extractor or a custom report with aggregation.

Views are a common trap. A community answer reports that if you have row-store table in HANA, you cannot create any views on top of those tables. That answer is old, so check the behavior on your release before you assume it. Either way, record the reason for each exception in your change log.

1. InventoryPull M_RS_TABLES and M_CS_TABLES for the ABAP schema
2. ReconcileCompare each table with its DD09L ROWORCOLST setting
3. ClassifyKeep, convert or investigate, with a written reason
4. Convert in non-productionChange type using the approved method and log the result
5. ProveRun regression, batch and performance tests, then compare memory and startup

Step 3: Convert only what you classified

The SQL form is short. To convert a row store table to HANA friendly column store tables, use ALTER TABLE with ALTER TYPE COLUMN. The reverse uses ALTER TYPE ROW, which a community answer confirms works in both directions. SAP's knowledge base article 2384500 covers converting in each direction and is the starting point for the procedure. It describes converting row store to column store and column store to row store.

For ABAP dictionary tables, I would not change the storage type with ad hoc SQL alone. The change should go through the ABAP dictionary and your approved change process, so DD09L, the database object and your transport history all agree. Treat the SQL route as a diagnostic or a documented exception, and confirm the approach with SAP Support for your release.

Expect two kinds of impact. Column tables load on demand, while row tables stay in memory from startup, so a conversion can change both startup time and memory use. Row store tables are always kept in-memory all the time and are loaded into HANA's memory during start up and remain there irrespective of the fact whether they are used or not unlike column store. Query plans can also change, so a table that a batch job reads row by row may run differently afterward.

Step 4: Test what the change touches

Storage type is invisible to users, so it is easy to skip testing. Do not skip it. Pick the tests by table, not by module. Run the reports and batch jobs that read each converted table, the interfaces that write to it, and the period-end jobs that aggregate it. Our guide to what to automate first in S/4HANA regression shows how to rank those flows.

Measure before and after. Record response times for the top database-heavy transactions, the memory use reported for the instance, and the startup time after a planned restart. A change that speeds up one report but adds memory at startup is a trade-off, and the sign-off note should say which one you accepted.

Step 5: Keep the AnyDB habits out of the target system

Row-store checks are only part of a HANA readiness review. The main mandatory ABAP changes for a HANA database migration include native SQL statements, database hints, searches in pool and cluster tables, use of the ADBC interface, and statements without ORDER BY. The ORDER BY point catches many teams. Some current custom code works only because the current database returns records in a particular sorted way, while HANA may return the same records in a different order or in random order. Add explicit sorting where the program depends on it, and make the test data big enough to show the difference.

For the migration path itself, the source database stays as a fallback during a SUM with DMO run, and application tables are not modified on the source database. That fallback is what makes the row-store review reversible during a conversion. For the full sequence, see our end-to-end ECC to S/4HANA migration guide.

Common mistakes

• Assuming every table is column store because the default changed. Tables created or migrated earlier keep their type unless someone changes them.
• Converting based on the table name or size alone. Check the access pattern and any view or report that depends on the table.
• Forgetting that temporary tables stay row store by design. Their presence in M_RS_TABLES is not a defect.
• Reading old forum answers as current rules. Many row-store threads predate SPS03 and the S/4HANA release cycle.

Frequently asked questions

Are all SAP HANA tables column store by default?

For tables created with a plain CREATE TABLE statement, the default is column store from SAP HANA 2.0 SPS03 onward. Tables that came in through an earlier migration or an older release can still be row store. Check M_RS_TABLES and DD09L to see what your system actually has.

How do I find row-store tables in SAP HANA?

Query M_RS_TABLES and filter by your ABAP schema. Then compare the result with the ROWORCOLST field in DD09L for the same tables. Any mismatch needs an explanation before you change anything.

Should I convert every row-store table to column store?

No. Global temporary tables must stay row store, and small tables read one record at a time often belong there. Convert the tables that are large or aggregated, and record the reason for every exception.

Does this change in S/4HANA 2025 or SAP Cloud ERP?

The storage engine is the same HANA database, but the release and deployment model decide who can run these changes. I could not confirm 2025-specific changes to the dictionary settings from the sources I reviewed. Check the release documentation, the relevant SAP Notes and your RISE or on-premise operating model before you run a change in a managed system.

To go deeper, the free course SAP HANA Database Essentials for Platform Teams covers the database concepts behind this. For the migration mechanics, the free course Database Migration Option (DMO) and Downtime Optimization is the next step.

Sources

1. 2384500 - How to Convert Row Store to Column Store and Vice Versa, SAP Support Knowledge Base, date not shown
2. Column store is now the default table type for SAP HANA, SAP Community blog, date not shown
3. Creating and Modifying Tables, SAP Learning, date not shown
4. CREATE TABLE Statement (Data Definition), SAP Help Portal, SAP HANA Cloud SQL reference, date not shown
5. Storage Type of Database Tables, ABAP Keyword Documentation 7.51, SAP Help Portal, date not shown
6. Database Migration Option: Target Database SAP HANA, SAP Help Portal, SUM 1.1 SP05 documentation, date not shown
7. 3 Things to Know When Coding ABAP on SAP HANA, SAP PRESS blog, date not shown
8. ABAP custom code adaptation for SAP HANA DB migration, SAP Community, date not shown
9. Custom code adjustments for HANA database migration, SAP Technical Guru, date not shown
10. BW: Conversion of DB tables to/from Row Store to Column Store, Martin Maruskin blog, January 2017
11. Converting a row store table in HANA to a column store table, SAP Community blog, September 2020
12. HANA Tables: store types, where is this information stored?, SAP Community Q&A, date not shown
13. Switch between Row Store and Column Store, SAP Community Q&A, date not shown
14. Changes to technical properties row/column store, SAP Community blog, date not shown
15. Row Store Vs Column Store, SAP Community Q&A, date not shown