EF Core vs redb Pro: 54 tables and 31 Includes vs one class
The redb.core team compares loading the same business object — an Employee with addresses, contacts and dictionaries — as 54 tables and 31 Include chains in EF Core versus a single class in their own ORM. On a 100k-object data set EF Core reads one employee with 62 SQL queries in almost two seconds, while redb Pro finishes in 131 ms with nine queries. The write-up argues the gap comes from how many tables a graph spans, not raw engine speed.
Key points
- The same business object becomes 54 tables, 59 foreign keys and 31 Include chains in EF Core
- Without AsSplitQuery, joins over independent collections multiply rows (cartesian explosion)
- redb 4.3.0's "streams" form joins fields with LEFT JOIN instead of collapsing them via GROUP BY
- The structure-value-object index order added in 4.4.0 pays off for selective filters and sorted pages
- On SQL Server, passing IN lists as separate parameters instead of STRING_SPLIT alone gave a 2-5x speedup
- The numbers come from the vendor's own library, so validate them on your schema before deciding
The post shows the same normalized model turning into 54 tables and 59 foreign keys on the EF Core side. Reading the whole graph needs 31 Include calls plus AsSplitQuery, because joining independent collections otherwise multiplies rows. redb instead keeps objects in two tables with one row per field, so query count follows the depth of references rather than the number of fields and collections.
The "streams" query form added in 4.3.0 joins fields with LEFT JOINs instead of collapsing them through GROUP BY, and the new structure/value/object index order in 4.4.0 speeds up selective filters and sorted pages. The vendor reports 2-8x gains on PostgreSQL and 4-25x on SQL Server, while SQLite results depend heavily on a memory-mapped database file. Because this is a vendor comparison, treat the numbers as a starting point and measure against your own schema.
Real-world use
- CRM-style apps that show a customer or employee record with addresses, contacts and dictionary collections on one screen
- Reporting and search screens that read deep object graphs and need to cut EF Core Include overhead
- Filtered, paged lists over large tables in a multi-tenant SaaS where response time matters
- Benchmarking EF Core queries on your own data set before choosing index and query shapes
Why it matters
In EF Core the cost of reading a graph grows with the number of tables and collections, so the article is a reminder to measure Include counts and index order rather than switch ORMs on benchmark numbers alone.