SAP HANA Database is the in-memory, columnar database that powers SAP SuccessFactors Incentive Management. If you're writing reports against commission data, migrating from Callidus Commissions on Oracle, or investigating results — you're working with HANA. Understanding its architecture is the foundation for writing efficient queries and avoiding common Oracle-to-HANA migration pitfalls.
What Makes SAP HANA Different: Columnar Storage
Traditional databases like Oracle Database, SQL Server, and PostgreSQL use row-oriented storage. Data is stored by row: all columns of row 1, then all columns of row 2, and so on. When you query, the database fetches entire rows into memory.
SAP HANA uses columnar storage. Data is stored by column: all values of column 1, then all values of column 2. When you query, the database fetches only the columns you need.
Row vs Column Storage: A Concrete Example
Imagine a CSC_RESULTS table with 10 million rows and 50 columns. You want to calculate total commission earned across all results.
Row-oriented (Oracle): Must read all 50 columns of all 10 million rows to extract RESULT_AMOUNT. That's ~500 million cell reads. In-memory cache fills quickly. Query slows.
Columnar (HANA): Reads only the RESULT_AMOUNT column (10 million values). The column is pre-compressed in memory. Query runs in milliseconds. The advantage scales with the number of columns you don't need.
Why SAP Chose HANA for SuccessFactors IM
SAP SuccessFactors Incentive Management generates a lot of aggregation queries:
- Summing results by participant for attainment calculations
- Rolling up results across organizational hierarchies for manager dashboards
- Aggregating quota vs earned for performance analysis
- Period-over-period comparisons for trend reporting
These queries demand columnar storage. On row-oriented Oracle, a large SuccessFactors IM instance becomes I/O bound. Reports take minutes. On HANA, the same reports run in seconds. For a high-volume commission environment (thousands of participants, millions of results per period), HANA is not a luxury — it's a necessity.
Columnar Storage Implications for Your Queries
Understanding columnar storage changes how you design queries:
Do: Aggregate-Focused Queries
Columnar storage excels at queries like this:
SELECT p.DEPARTMENT, COUNT(r.ID) AS RESULT_COUNT, SUM(r.RESULT_AMOUNT) AS TOTAL_EARNED, ROUND(AVG(r.RESULT_AMOUNT), 2) AS AVG_RESULT FROM CSC_RESULTS r JOIN CSC_PARTICIPANT p ON p.ID = r.PARTICIPANT_ID WHERE r.PERIOD_ID = '2026-Q1' GROUP BY p.DEPARTMENT ORDER BY TOTAL_EARNED DESC;
This query reads only the columns it needs (DEPARTMENT, RESULT_AMOUNT, PARTICIPANT_ID, PERIOD_ID) and groups/aggregates. On HANA, this runs fast.
Don't: SELECT * or Unnecessary Columns
Never use SELECT * in production:
-- AVOID THIS SELECT * FROM CSC_RESULTS WHERE PERIOD_ID = '2026-Q1';
SELECT * defeats column-pruning. You're reading all 50 columns when you might need 5. On row-oriented databases this is a bad habit. On columnar, it's a cardinal sin. Always select explicit columns.
Do: Filter on Indexed Columns Early
Indexes on HANA work differently than Oracle, but filtering early is still critical:
-- Good: Filter on indexed columns (PARTICIPANT_ID, PERIOD_ID, PLAN_ID) SELECT RESULT_AMOUNT, RESULT_DATE FROM CSC_RESULTS WHERE PERIOD_ID = '2026-Q1' AND PARTICIPANT_ID = 12345;
PERIOD_ID and PARTICIPANT_ID are always indexed on CSC_ tables. Filtering on them first narrows the column scan range and improves performance dramatically.
SAP HANA Architecture: On-Premise vs Cloud (GCP)
SAP HANA can run on-premise or in the cloud. SAP SuccessFactors IM deployments are increasingly cloud-hosted on Google Cloud Platform (GCP), though Azure and AWS are also options.
In-Memory Computing Layer
HANA's core strength is in-memory storage. Data that would be on disk in Oracle is kept in RAM on HANA. This requires:
- Sufficient memory: A large SuccessFactors IM instance can require 256 GB, 512 GB, or more of RAM.
- Compression: Columnar data is compressed 5-10x vs row storage, making large datasets memory-efficient.
- Cloud scaling: On GCP, memory can be provisioned and scaled on-demand without physical hardware constraints.
Why SuccessFactors IM on GCP Works Well
Google Cloud Platform offers tight integration with SAP HANA:
- Committed Use Discounts: Lower costs for long-term HANA commitments.
- Vertical scaling: Machine types with up to 12 TB of memory for massive datasets.
- Regional redundancy: Multi-region replication for disaster recovery.
- SAP-optimized VMs: GCP provides machine shapes (e.g., m2-ultramem-416) tuned for HANA workloads.
CSC_ Tables: The SAP SuccessFactors IM Schema
All data in SAP SuccessFactors IM uses the CSC_ prefix. This distinguishes SuccessFactors tables from other SAP products. Common CSC_ tables:
| Table | Purpose | Key Columns |
|---|---|---|
| CSC_PARTICIPANT | Sales rep, manager, or admin records | ID, NAME, PARENT_ID, PLAN_ID, STATUS |
| CSC_COMP_PLAN | Compensation plan master data | ID, NAME, PERIOD_ID, CURRENCY, STATUS |
| CSC_PERIOD | Period definitions (Q1, Q2, Year, Month, etc.) | ID, PERIOD_TYPE, START_DATE, END_DATE |
| CSC_QUOTA | Target quotas per participant/period | PARTICIPANT_ID, PERIOD_ID, QUOTA_AMOUNT, PLAN_ID |
| CSC_RESULTS | Transaction results (orders, pipeline) | ID, PARTICIPANT_ID, RESULT_AMOUNT, PERIOD_ID, PLAN_ID |
| CSC_PAYMENT | Commission payouts | ID, PARTICIPANT_ID, PERIOD_ID, AMOUNT, STATUS |
Unlike Oracle-based Callidus, where tables used the CS_ prefix, SuccessFactors IM consistently uses CSC_. Migrations often require renaming tables and rewriting queries to account for this prefix change.
Connecting to SAP HANA Database: HANA Database Explorer
SAP provides a web-based query tool called SAP HANA Database Explorer. It's the primary interface for running ad-hoc queries without installing database clients.
Accessing HANA Database Explorer
- Log into your SAP SuccessFactors IM system or HANA instance.
- Navigate to the HANA Database Explorer URL (usually embedded in SuccessFactors or accessible via a cloud provider dashboard).
- Authenticate with your HANA credentials.
- You'll see a catalog browser on the left showing databases, schemas, and tables.
Running Your First Query
In HANA Database Explorer:
-- Check the current date on HANA (no FROM clause needed, no DUAL table) SELECT CURRENT_DATE AS TODAY;
When you run this, HANA returns today's date. Notice there's no FROM clause — HANA doesn't require a dummy table like Oracle's DUAL. This is one of many HANA SQL quirks you'll learn in Lesson 2.
Exploring Table Structure
In HANA Database Explorer, right-click any table (e.g., CSC_PARTICIPANT) and select "Analyze Table" or "Show Data Sample". This gives you:
- Column names, types, and constraints
- Row count and table size
- Sample data (first 100 rows)
- Index and partitioning info
Use this exploration before writing queries. Understand what columns exist, their data types, and sample values.
Case Sensitivity and Identifiers in HANA
HANA has unique identifier handling that trips up Oracle developers:
Unquoted Identifiers Are Uppercase
HANA converts unquoted identifiers (table names, column names) to uppercase automatically:
-- These are all equivalent on HANA SELECT NAME FROM CSC_PARTICIPANT; SELECT name FROM csc_participant; SELECT "NAME" FROM "CSC_PARTICIPANT";
All three queries select the NAME column from CSC_PARTICIPANT. Unquoted names are case-insensitive and converted to uppercase. Quoted names (in double quotes) are case-sensitive.
Best Practice: Use Uppercase for Standard Objects
Follow SAP's convention: use uppercase for table and column names, no quotes.
-- Good: uppercase, no quotes SELECT PARTICIPANT_ID, RESULT_AMOUNT FROM CSC_RESULTS WHERE PERIOD_ID = '2026-Q1';
Checking Your HANA Version
Different HANA versions support different features. Check your version with:
SELECT DATABASE_NAME, ACTIVE_STATUS FROM SYS.M_DATABASES;
Or use the system info command if available in your query tool. Most SuccessFactors IM instances run HANA 2.0 (SPS 04-07) or later. This learning path assumes HANA 2.0+, where recursive CTEs, table variables, and modern SQL Script features are fully supported.
Key Takeaways
- Columnar storage makes aggregation queries (SUM, COUNT, AVG) 100x faster than row-based databases.
- SAP chose HANA for SuccessFactors IM specifically because commission reporting requires heavy aggregations.
- Always select only needed columns. SELECT * defeats HANA's optimization.
- CSC_ is the SuccessFactors IM table prefix (unlike Callidus's CS_).
- HANA Database Explorer is your query tool — no need for local database clients.
- Unquoted identifiers in HANA are case-insensitive and uppercase. This differs from Oracle.