Angular Material's mat-table is a great primitive: composable, well-documented, and integrated tightly with the rest of Material's MDC components. The catch is that it's deliberately minimal. Sort, paginate, and basic filtering ship as MatSort / MatPaginator helpers, but virtualization, column pinning, row grouping with aggregations, and inline editing are all things you build yourself.
Simple Table for Angular is a complementary alternative. It's source-available (free for pre-revenue teams), ships virtualization, pinning, grouping, and editing as first-class features, and themes against Material design tokens via CSS variables—so you can keep your Material look-and-feel without writing a renderer pipeline.
If you've ever tried to wire mat-table + CDK virtual scroll + manual sticky columns + custom sort/group code together, this comparison will save you a lot of plumbing.
Quick comparison
| Feature | Angular Material mat-table | Simple Table for Angular |
|---|---|---|
| License | MIT | Community License |
| Standalone components | Yes | Yes |
| Out-of-the-box rendering | Composable primitive | Batteries-included grid |
| Row virtualization | Via CDK virtual scroll (manual) | Built-in |
| Column pinning (sticky columns) | Manual | Built-in |
| Row grouping with aggregations | Build yourself | Built-in |
| Inline cell editing | Build yourself | Built-in |
| Theme via Material tokens | Native Material | CSS variables (Material-compatible) |
| Bundle size (gzipped) | ~50 kB (excludes virtualization, sort, paginate helpers) | 84.6 kB (everything included) |
Stay with mat-table when…
- Your needs are basic: sort, paginate, custom cells. No grouping, no pinning, no virtualization.
- You want maximum DOM control with mat-table's directive composition.
- Your team is comfortable wiring CDK virtual scroll and sticky columns by hand.
- Material design system fidelity is non-negotiable.
Switch to Simple Table for Angular when…
- You want virtualization, pinning, grouping, and editing without writing them yourself.
- You've spent more than a sprint maintaining custom mat-table extensions.
- You want Material-compatible theming via CSS variables.
- You also build React / Vue / Svelte / Solid surfaces and want a shared engine.
- You want grouping with aggregations as a declarative prop, not custom Angular code.
Real-world scenarios
Basic admin tables, sort + paginate
Two screens, ~500 rows each, mat-table + MatSort works fine.
Stay with mat-table—you're using it well within its sweet spot.
Reporting view with grouping + aggregations
Need expanded/collapsed groups with sum and avg footers across thousands of rows.
Switch to Simple Table—grouping with aggregations is built-in.
Wide table with sticky columns + virtualization
30+ columns, 100k+ rows, frozen first 3 columns. Currently held together with CDK virtual scroll + manual sticky CSS.
Switch to Simple Table—pinning and virtualization are first-class.
Strict Material design fidelity
Every component has to feel native Material, including ripples and elevation.
Stay with mat-table for native Material fidelity—or use Simple Table with Material-tuned CSS variables.
Frequently asked questions
- Can Simple Table look like a Material table?
- Yes. Theming is via CSS variables (row height, header color, hover color, density). Map your Material design tokens onto Simple Table's variables for a Material-feeling grid.
- Will I lose mat-table's directive composition flexibility?
- You give up directive-level composition for declarative props. In return, virtualization / pinning / grouping / editing are built in.
- Does Simple Table integrate with MatPaginator?
- Simple Table has its own pagination component, but you can wire MatPaginator if you prefer—the table accepts external pagination state via props.
The verdict
mat-table is a great primitive when your needs match its scope: composable, Material-native, MIT. The moment you need virtualization + pinning + grouping + editing as a coherent package, you're better off swapping the table layer.
Simple Table for Angular gives you those features in one source-available package and still themes against Material via CSS variables. You keep your design system, you stop building data-grid plumbing.