ORMs for various platforms

I noticed a post on a social media, where a user complained about the lack of an ORM standard in the Delphi world.

The ORM implementations are very different, and moving from one to another is more complex, than a simple replace library and recompile operation.

That is a correct observation. The ORMs are different and typically they also have a different focal area in relation to the tasks they want to solve for the developer.

The post came with an underlying (not explicitly written) understanding that it was better on other development platforms than Delphi.

I decided to check out what are the facts, and in the current age of AI, there are great tools to help one researching that. So I picked Google Gemini 2.5 Pro, but Grok 3 and others would have done a great job too.

In the following many different ORMs are shown for the platforms dotNet, Phyton, Java, Javascript/Node.js, C++ and Delphi.

The conclusion is that there is really no universal ORM standard nor de facto standard as an ORM typically targets a specific set of features and use cases.

Further I think competition is good. It enables the continued evolution of the various framework offerings.

dotNet

There are quite a few Object-Relational Mappers (ORMs) available for the .NET ecosystem, ranging from full-featured frameworks to lightweight “micro-ORMs”. Here’s a list of the most notable ones:

Major/Full-Featured ORMs:

1. Entity Framework Core (EF Core):
   • Description: Microsoft’s current flagship ORM. It’s open-source, cross-platform (works on .NET Core, .NET 5+, Windows, Linux, macOS), and actively developed. It’s modular, extensible, and generally easier to use and often more performant than its predecessor (EF6).
   • Key Features: Strong LINQ support, change tracking, migrations, connection resiliency, supports many database providers (SQL Server, PostgreSQL, MySQL, SQLite, Cosmos DB, etc.).
2. Entity Framework 6 (EF6):
   • Description: The mature, previous generation of Entity Framework from Microsoft. It’s stable and feature-rich but primarily targets the full .NET Framework (though there’s some limited .NET Core support via compatibility). Still widely used in legacy applications.
   • Key Features: Mature LINQ provider, Code First, Model First, Database First workflows, change tracking, migrations. Primarily targets SQL Server but has providers for others.
3. NHibernate:
   • Description: A mature, powerful, open-source ORM ported from the Java Hibernate project. It’s very flexible and feature-rich, often considered more powerful but potentially more complex to configure than Entity Framework.
   • Key Features: Extensive mapping options (XML, attributes, fluent code), lazy loading, caching, supports many databases, strong community support. Works on both .NET Framework and .NET Core/.NET 5+.
4. LLBLGen Pro:
   • Description: A commercial ORM solution known for its powerful designer and flexibility. It supports multiple data access patterns (not just ORM) and targets various databases.
   • Key Features: Visual designer, code generation, supports LINQ, low-level ADO.NET access, multiple database targets, excellent performance.
5. DevExpress XPO (eXpress Persistent Objects):
   • Description: A commercial ORM from DevExpress, often used within their broader component suite but usable standalone.
   • Key Features: Technology-agnostic data layer, supports multiple database systems, visual designer integration (within Visual Studio), Code First/Model First/Database First support.

Micro-ORMs / Lightweight ORMs:

These typically focus on performance and simplicity, often by providing minimal abstraction over SQL and focusing primarily on mapping query results to objects.

6. Dapper:
   • Description: Developed by Stack Overflow, Dapper is arguably the most popular micro-ORM. It’s extremely fast, lightweight, and focuses on mapping query results to objects with minimal overhead. It gives you more direct control over your SQL.
   • Key Features: High performance, extension methods for IDbConnection, minimal abstraction, easy POCO mapping, multi-mapping support.
7. ServiceStack.OrmLite:
   • Description: Part of the ServiceStack framework but can be used independently. It aims for a clean, code-first POCO approach with a simple API.
   • Key Features: Code-first, convention-based, high performance, supports multiple databases, LINQ support (though sometimes less comprehensive than full ORMs).
8. PetaPoco:
   • Description: Another popular micro-ORM, inspired by Dapper and OrmLite but adding a bit more functionality like helpers for Insert/Update/Delete operations on POCOs.
   • Key Features: Single file deployment option, POCO support, helpers for CRUD, paged queries, good performance.
9. RepoDb:
   • Description: A newer hybrid ORM aiming to bridge the gap between micro-ORMs (like Dapper) and full ORMs (like EF Core). It focuses on performance, efficiency, and flexibility.
   • Key Features: High performance (often benchmarked close to Dapper), fluent mapping, batch/bulk operations, caching, supports multiple databases.

Legacy / Less Common ORMs:

10. LINQ to SQL:
    • Description: An earlier ORM technology from Microsoft, tightly coupled to SQL Server. It maps SQL Server tables directly to .NET classes. Largely superseded by Entity Framework but still found in older .NET Framework applications.
    • Key Features: Simple mapping for SQL Server, LINQ query support, visual designer.
11. SubSonic:
    • Description: An older open-source ORM that used code generation based on database schema. Less actively developed now but was popular in its time.

Choosing an ORM depends on:

• Project Needs: Complexity, performance requirements.
• Platform: .NET Framework vs. .NET Core/.NET 5+.
• Team Experience: Familiarity with specific tools.
• Database: Which database(s) do you need to support?
• Control vs. Abstraction: How much control over SQL do you need vs. how much abstraction do you want?

For new projects on .NET Core/.NET 5+, EF Core and Dapper are the most common choices, sometimes even used together in the same project (EF Core for complex writes/business logic, Dapper for high-performance reads). NHibernate remains a solid choice for those familiar with it or needing its specific features.

JAVA

Let’s look at the landscape of ORMs and persistence frameworks in the Java ecosystem. It’s dominated by a standard API (JPA) and several popular implementations, along with other non-standard frameworks.

The Standard: Jakarta Persistence API (JPA)

• Description: Formerly the Java Persistence API, JPA is a specification, not an implementation itself. It defines a standard way for Java applications to interact with relational databases through object mapping. Many ORMs implement this specification. Using the JPA standard allows for potentially switching between underlying ORM implementations with less code change.
• Key Features (defined by the spec): Entity mapping via annotations or XML, Java Persistence Query Language (JPQL), Criteria API for type-safe queries, EntityManager for managing entity lifecycle, transaction management integration.

Major JPA Implementations:

1. Hibernate ORM:
   • Description: By far the most popular and widely used JPA implementation. It’s mature, feature-rich, and has a large community. It predates JPA and heavily influenced its design.
   • Key Features: Implements JPA fully, offers additional features beyond JPA (like Hibernate Query Language – HQL, extensive caching options, statistics, filters), strong community support, integrates well with frameworks like Spring (via Spring Data JPA).
2. EclipseLink:
   • Description: The official reference implementation for JPA. It originated from Oracle’s TopLink product and is now an Eclipse Foundation project. It’s a robust and compliant implementation.
   • Key Features: Full JPA compliance, advanced mapping options, caching, good performance, supports NoSQL databases in addition to relational ones.
3. Apache OpenJPA:
   • Description: Another open-source JPA implementation from the Apache Software Foundation. While perhaps less commonly used now than Hibernate or EclipseLink, it’s still a compliant and viable option.
   • Key Features: JPA compliance, focus on performance, bytecode enhancement features.

Other Popular Persistence Frameworks (Not strictly traditional ORMs or non-JPA):

4. MyBatis (formerly iBATIS):
   • Description: Often called a “SQL Mapper” rather than a full ORM. It focuses on decoupling SQL statements from the Java code, mapping SQL results to Java objects (POJOs), and mapping parameters into SQL statements. It gives you full control over your SQL.
   • Key Features: Direct SQL control (SQL stored typically in XML or annotations), simpler mapping compared to full ORMs, less “magic” than JPA implementations, often perceived as easier for developers strong in SQL, good performance.
5. jOOQ (Java Object Oriented Querying):
   • Description: Not a traditional ORM, but a library for building type-safe SQL queries in Java. It generates Java code from your database schema, allowing you to write SQL queries using a fluent Java API that gets checked at compile time. It can be used alongside or instead of a traditional ORM.
   • Key Features: Type-safe SQL queries, excellent support for various SQL dialects and database-specific features, code generation from database schema, often used for complex reporting or performance-critical queries.
6. Spring Data JDBC:
   • Description: Part of the larger Spring Data project. It aims to be a simpler persistence framework compared to Spring Data JPA. It uses basic ORM features (like mapping results to objects) but avoids many complex features like lazy loading, caching, or dirty tracking found in JPA, aiming for more explicitness. Relies heavily on Spring’s JdbcTemplate underneath.
   • Key Features: Simpler object mapping, less magic than JPA, closer to SQL, good integration with the Spring ecosystem.
7. Ebean ORM:
   • Description: An ORM designed to be simpler to use than JPA/Hibernate while still providing significant features. It uses bytecode enhancement for dirty checking and lazy loading.
   • Key Features: Session-less API (often seen as simpler), JPA annotations for mapping, SQL/DML generation, supports database migrations.

Legacy / Less Common:

8. Java Data Objects (JDO):
   • Description: Another persistence specification, similar in goal to JPA but different in approach. It aimed to be more generic, supporting not just relational databases but other types of datastores. Less commonly used for new projects today compared to JPA.

• TopLink:
  • Description: The original product from Oracle that EclipseLink was based on. Still exists as part of some Oracle product suites but EclipseLink is the open-source successor for general use.

Choosing an ORM/Framework in Java:

• JPA Standard: Do you want portability between implementations? Start with JPA (usually implemented by Hibernate or EclipseLink). Frameworks like Spring Data JPA make using JPA implementations very convenient.
• SQL Control: Need fine-grained control over SQL and find full ORMs too complex? MyBatis is a great choice.
• Type-Safe SQL: Want compile-time checks for your SQL and leverage database-specific features easily? jOOQ is excellent, especially for complex queries.
• Simplicity (within Spring): Want basic ORM features without the complexity of JPA (caching, session management)? Spring Data JDBC might fit.
• Simpler ORM Alternative: Looking for a full ORM perceived as simpler than JPA? Consider Ebean.

For most new enterprise Java applications, especially those using Spring, JPA with Hibernate (often via Spring Data JPA) is the most common starting point. MyBatis and jOOQ are popular alternatives when more direct SQL control or type safety is paramount.

Phyton

Python also has a rich ecosystem of ORMs and database interaction libraries. Here are some of the most prominent ones:

Major / Widely Used ORMs:

1. SQLAlchemy:
   • Description: This is arguably the most powerful, flexible, and widely used ORM toolkit in the Python world outside of specific web frameworks. It’s known for its high performance and robust feature set. It actually consists of two distinct components:
     • SQLAlchemy Core: Provides a SQL Expression Language, acting as a schema management toolkit and a way to programmatically build SQL queries that are database-agnostic. It’s closer to the database and gives more control.
     • SQLAlchemy ORM: Built on top of the Core, this provides the full Object-Relational Mapping experience, allowing you to map Python classes (models) to database tables and interact with them as objects.
   • Key Features: Mature, highly configurable, supports numerous database backends, excellent transaction management, connection pooling, powerful querying (both ORM-level and Core-level), migration support (typically via Alembic), async support (asyncio).
2. Django ORM:
   • Description: Built directly into the popular Django web framework. It’s designed to work seamlessly within Django applications and follows its “batteries-included” philosophy. While tightly integrated, it can be used standalone, though this is less common.
   • Key Features: Excellent integration with Django, built-in migration system (manage.py makemigration/migrate), expressive query API, admin interface integration, convention over configuration, relatively easy to learn within the Django context.
3. Peewee:
   • Description: A simpler, smaller, and more expressive ORM. It aims to be easy to learn and use, especially for smaller projects, while still being quite capable. Often seen as a lighter alternative to SQLAlchemy.
   • Key Features: Lightweight, simple API, supports SQLite, MySQL, PostgreSQL, CockroachDB, composable query builder, includes some utilities for migrations and admin interfaces, supports async via peewee-async.

Asynchronous ORMs (Built for asyncio):

4. Tortoise ORM:
   • Description: An async ORM inspired by the Django ORM’s API design but built from the ground up for asyncio. Popular choice for async frameworks like FastAPI, Starlette, Sanic, etc.
   • Key Features: Designed for asyncio, Django-like API, built-in migration generation and management (via Aerich), relationship handling, supports PostgreSQL, MySQL, SQLite.
5. SQLAlchemy (with Async Support):
   • Description: As mentioned above, recent versions of SQLAlchemy have excellent built-in support for asyncio, allowing you to use both the Core and ORM layers with async database drivers (like asyncpg, aiomysql, aiosqlite).
   • Key Features: Leverages the power and maturity of SQLAlchemy within an async context, works with Alembic for migrations.
6. Databases:
   • Description: This library provides a simple asyncio interface for interacting with various databases. It largely wraps SQLAlchemy Core (using its query builder) but doesn’t provide a full ORM layer itself (no identity map, session management, complex relationship loading like SQLAlchemy ORM). Often used when you want async database access without the full overhead or complexity of a traditional ORM layer.
   • Key Features: Simple async API, uses SQLAlchemy Core’s expression language, supports PostgreSQL, MySQL, SQLite.

Other Notable ORMs:

7. Pony ORM:
   • Description: Known for its unique approach to writing queries using Python generator expressions, which it translates into SQL. Aims for concise and readable query syntax.
   • Key Features: Unique generator-based query syntax, database schema generation from models, supports SQLite, PostgreSQL, MySQL, Oracle, CockroachDB, includes a graphical schema editor.
8. Orator ORM:
   • Description: An ORM heavily inspired by the Eloquent ORM from the PHP framework Laravel. It brings the Active Record pattern (where model objects encapsulate both data and database interaction logic) prominently to Python.
   • Key Features: Active Record implementation, fluent query builder, database migrations, seeding, supports SQLite, PostgreSQL, MySQL, SQL Server.

Choosing a Python ORM:

• Using Django? Start with the Django ORM. It’s the natural fit.
• Need flexibility, power, and wide database support (sync or async)? SQLAlchemy is the standard choice. Use its ORM layer for full mapping or the Core for more control. Requires Alembic for robust migrations.
• Want something simpler/lighter than SQLAlchemy? Peewee is a great option.
• Building an async application (FastAPI, Starlette, etc.) and like Django’s API? Tortoise ORM is purpose-built for this.
• Building an async application and prefer SQLAlchemy’s power/ecosystem? Use SQLAlchemy’s async support.
• Need simple async database access without a full ORM? The Databases library might suffice.
• Intrigued by unique query syntax? Look at Pony ORM.
• Prefer the Active Record pattern (like Laravel)? Check out Orator ORM.

SQLAlchemy and the Django ORM are the most dominant forces in the Python ORM landscape, but the others fill important niches, especially Peewee for simplicity and Tortoise for async applications.

Javascript / Node.js

The JavaScript/Node.js ecosystem has a vibrant selection of ORMs and related database tools, catering to both SQL and NoSQL databases. Here are some of the most prominent ones:

Major Relational ORMs (for SQL Databases like PostgreSQL, MySQL, SQLite, SQL Server, etc.):

1. Sequelize:
   • Description: One of the most established and widely used promise-based Node.js ORMs. It’s mature, feature-rich, and supports multiple SQL dialects.
   • Key Features: Solid transaction support, relations (one-to-one, one-to-many, many-to-many), eager and lazy loading, read replication, migrations (via Sequelize CLI), hooks, model validation. Supports PostgreSQL, MySQL, MariaDB, SQLite, and SQL Server.
2. Prisma:
   • Description: A newer generation ORM focused on developer experience, type safety (especially with TypeScript), and performance. It’s not just an ORM but a toolkit including Prisma Client (auto-generated, type-safe query builder), Prisma Migrate (declarative migration system), and Prisma Studio (GUI for database browsing).
   • Key Features: Schema-first approach (using Prisma Schema Language), excellent TypeScript integration, auto-generated and type-safe client, robust migration system, high performance (uses a query engine typically written in Rust). Supports PostgreSQL, MySQL, SQLite, SQL Server, MongoDB.
3. TypeORM:
   • Description: A very popular ORM that can run in Node.js, browser, mobile platforms, etc. It’s written in TypeScript and leverages modern JavaScript features. It supports both Active Record and Data Mapper patterns, offering flexibility.
   • Key Features: Strong TypeScript support (decorators, etc.), supports multiple databases (SQL and some NoSQL like MongoDB), Active Record and Data Mapper patterns, eager and lazy relations, connection pooling, migrations, subscriber/listener pattern. Often used with frameworks like NestJS.
4. MikroORM:
   • Description: Another powerful TypeScript-based ORM heavily inspired by Doctrine (PHP) and Hibernate (Java). It focuses strongly on the Data Mapper pattern, Unit of Work, and Identity Map for efficient database interaction.
   • Key Features: TypeScript-first, Data Mapper pattern, Unit of Work, Identity Map, supports transactions, cascades, migrations (via CLI), entity generator, supports PostgreSQL, MySQL, MariaDB, SQLite, MongoDB. Known for robust handling of complex object graphs.
5. Objection.js:
   • Description: Often described as a “relational query builder” or a minimal ORM built on top of Knex.js (a popular SQL query builder). It aims to leverage the power of SQL while providing helpful object-oriented features like models and relationships.
   • Key Features: Built on Knex.js, provides models and relationships, powerful relation expression syntax for eager loading, official TypeScript support, uses Knex for migrations and query execution.

Popular Query Builders (Often used directly or as a base for ORMs):

6. Knex.js:
   • Description: The most popular SQL query builder for Node.js. It’s not a full ORM (doesn’t handle object mapping lifecycle in the same way) but provides a fluent interface for building SQL queries programmatically. It also includes schema building, transaction support, connection pooling, and a migration system.
   • Key Features: Fluent SQL query builder, promise-based, multi-dialect support, stream interface, connection pooling, migrations, seeding. Foundation for ORMs like Objection.js.

Popular ODMs (Object Document Mappers – for NoSQL, especially MongoDB):

7. Mongoose:
   • Description: The de facto standard ODM for MongoDB in the Node.js ecosystem. It provides a straightforward, schema-based solution for modeling application data, including built-in type casting, validation, query building, and business logic hooks.
   • Key Features: MongoDB specific, schema definition and validation, middleware (pre/post hooks), query building, population (for references across collections), connection management, plugins.

Framework-Specific / Other:

8. Waterline:
   • Description: The ORM/ODM extracted from the Sails.js framework. It provides a consistent API across different database types (SQL, NoSQL).
   • Key Features: Adapter-based (supports many DBs), lifecycle callbacks, population. Less commonly used outside of Sails.js compared to others on this list.

Choosing a JavaScript/Node.js ORM/ODM:

• Working with MongoDB? Mongoose is almost always the go-to choice. Prisma and TypeORM/MikroORM also offer MongoDB support if you need multi-database capabilities or prefer their API.
• Need a Relational ORM (SQL)?
  • Prioritize Type Safety & DX? Prisma is a top contender, especially with TypeScript.
  • Need flexibility (Active Record/Data Mapper) & strong TypeScript? TypeORM is very popular, integrates well with NestJS. MikroORM is a powerful alternative focusing on Data Mapper.
  • Looking for maturity and wide adoption? Sequelize is a long-standing, solid choice.
  • Prefer building on a query builder / more direct SQL feel? Objection.js (on top of Knex.js).
  • Just need a query builder without full ORM features? Knex.js is excellent.

The landscape is quite dynamic, with Prisma gaining significant traction alongside the established players like Sequelize and TypeORM. Mongoose remains dominant for MongoDB. Your choice often depends on whether you’re using TypeScript, your preferred programming patterns (e.g., Active Record vs. Data Mapper), the specific database, and the desired level of abstraction vs. control.

Delphi

Here are the notable ORMs and frameworks with ORM capabilities available for Delphi (Object Pascal):

Major Dedicated Third-Party ORMs:

1. TMS Aurelius:
   • Description: A highly regarded, feature-rich, modern ORM specifically designed for Delphi. It’s a commercial product from TMS Software, known for its comprehensive feature set and ease of use.
   • Key Features: Plain Old Delphi Objects (PODO) mapping using attributes, multi-database support (via FireDAC, dbExpress, Zeos, IBX, FBLib, UniDAC, etc.), LINQ-like querying API (TCriteria), lazy loading, inheritance mapping, caching, transaction management, integrated validation, JSON marshalling. Cross-platform (VCL/FMX).
2. ORMBr:
   • Description: A popular open-source ORM framework for Delphi. It provides a solid set of ORM features and is actively developed by the community.
   • Key Features: Attribute-based mapping, supports multiple databases (via interfaces, common drivers like FireDAC are supported), CRUD operations, lazy loading, caching, LINQ-like query API, transaction control, logging.
3. Devart Entity Developer & Data Access Components (SDAC, ODAC, UniDAC etc.):
   • Description: Devart offers high-performance direct data access components (DACs). Their Entity Developer is a visual ORM designer tool that generates Delphi entity classes and data context code, leveraging their underlying DACs for database interaction.
   • Key Features: Visual model-first or database-first design, LINQ support (via specific components), code generation for entities and data context, supports complex types, inheritance, uses Devart’s high-performance DACs. Commercial.

Hybrid / Frameworks with ORM Capabilities:

4. kbmMW:
   • Description: A comprehensive, high-performance commercial middleware and application server framework for building scalable, n-tier, distributed applications (including microservices). While much broader than just an ORM, it includes robust ORM features and database connectivity as a core part of its offering.
   • Key Features: ORM with object mapping, high-performance data access, designed for n-tier/distributed systems, adapter-based database support, advanced caching, object pooling, messaging (SmartQueues), RPC, security features. Its ORM is integrated into its larger middleware architecture.
5. mORMot Framework:
   • Description: A powerful, high-performance open-source framework primarily focused on Client-Server and SOA architectures. It features a distinctive and very fast ORM component optimized for speed, often using direct access methods and supporting features typically found in NoSQL environments alongside SQL.
   • Key Features: High-performance object persistence (can bypass datasets), schema-less features, REST/JSON focus, advanced caching, security, ORM features include object validation, SQLite3 focus but supports others via ODBC/OleDB or specific drivers, interface-based services. A broad framework where ORM is one component.
6. Marshmallow (persistence part of DMVCFramework):
   • Description: An open-source library, often used within the Delphi MVC Framework (DMVC), providing object persistence capabilities focused on RESTful services. It excels at serializing objects to/from JSON and persisting them.
   • Key Features: Focus on JSON marshalling/unmarshalling, object persistence (CRUD), attribute-based mapping, works well with REST APIs, supports various databases via adapters (often using FireDAC).

Built-in Data Access Layers (Foundation, not full ORMs):

7. FireDAC:
   • Description: Embarcadero’s primary, built-in universal data access library. It’s the foundation for database access in modern Delphi. While not an ORM itself, it’s highly capable, and developers often build ORM-like patterns or manual object mapping on top of it. Many third-party ORMs use FireDAC as a provider.
   • Key Features: High speed, unified API for many databases, powerful TFDMemTable, Array DML, caching updates. ORM features require manual implementation or helper classes.
8. LiveBindings:
   • Description: A built-in technology for binding UI controls to data sources, or data sources (like TDataSet) to object properties. Offers basic visual mapping capabilities but isn’t a full ORM solution.
   • Key Features: Visual binding, reduces boilerplate for simple UI-to-data or data-to-object mapping.

Legacy / Less Common:

9. Bold for Delphi:
   • Description: An older, powerful Model-Driven Architecture (MDA) and ORM framework. Less common now.
10. InstantObjects:
    • Description: Another older ORM framework, less actively developed.

Choosing in Delphi:

• Need a modern, dedicated, commercially supported ORM? TMS Aurelius is a top choice.
• Prefer open-source and a dedicated ORM? ORMBr is a strong candidate.
• Building complex, scalable, n-tier applications and need a full middleware suite with ORM included? kbmMW is designed for this.
• Need extreme performance, building SOA/Client-Server, and don’t mind a more comprehensive framework? mORMot offers a high-speed persistence layer within its broader scope.
• Using Devart DACs or want a visual designer? Devart Entity Developer is the integrated solution.
• Focus on REST/JSON APIs and need simple persistence? Marshmallow (often with DMVC) fits well.
• Content with robust data access and manual/simple mapping? FireDAC (possibly with LiveBindings or custom helpers) is the standard built-in approach.

C++

Finding ORMs in C++ is a bit different than in languages like Java, C#, or Python. There isn’t one dominant standard or framework, and the line between a full ORM, a database access library, and a type-safe SQL query builder can sometimes be blurry. C++ developers often prioritize performance and control, which influences the design of these libraries.

Here are some notable ORM and ORM-like libraries for C++:

Dedicated C++ ORMs:

1. ODB (Object-Relational Mapping):
   • Description: A high-profile, open-source (GPL/commercial) ORM system for C++. It uses a dedicated C++ preprocessor to analyze C++ class definitions and automatically generate the database mapping code. Known for performance and a clean object-oriented interface.
   • Key Features: Code generation approach (via preprocessor), supports multiple databases (PostgreSQL, MySQL, SQLite, SQL Server, Oracle), high performance, object persistence, querying (including LINQ-like syntax with liblitesql), lazy loading, transaction management, schema evolution support.
2. QxOrm:
   • Description: An open-source (LGPL) ORM library for C++. It relies heavily on C++ macros and templates to define persistent classes and relationships. It aims for ease of use and integrates well with the Qt framework (but doesn’t require it).
   • Key Features: Macro-based mapping, supports various databases (via Qt SQL module or ODBC), serialization features (JSON, XML), relationship management (one-to-one, one-to-many, many-to-many), lazy loading, transaction support.
3. LiteSQL:
   • Description: An open-source (BSD license) ORM originally focused on SQLite but extended to support PostgreSQL and MySQL. It uses an XML description of the object model to generate C++ persistence code.
   • Key Features: Code generation from XML definition, supports SQLite, PostgreSQL, MySQL, relationship mapping, designed for simplicity.

Frameworks with ORM / Database Modules:

4. Qt SQL Module:
   • Description: Part of the comprehensive Qt framework. While not a full-fledged ORM in the same vein as ODB or QxOrm, it provides a robust abstraction layer over various SQL databases (QSqlDatabase, QSqlQuery). It also offers higher-level classes like QSqlTableModel and QSqlQueryModel that facilitate mapping database tables/queries to models usable within Qt’s model/view architecture, enabling ORM-like patterns.
   • Key Features: Excellent integration with Qt framework, database-agnostic API, connection management, query execution, model classes for easier UI binding. Requires manual mapping logic for complex object relationships.
5. Poco Data Library:
   • Description: Part of the POCO C++ Libraries, a collection of open-source C++ class libraries for network-centric applications. The Poco::Data module provides a unified abstraction layer for accessing different SQL databases (ODBC, MySQL, SQLite, Oracle). It supports binding C++ types to SQL statements and retrieving results, allowing for ORM patterns, although it might be considered more of a sophisticated database access layer than a full ORM with automatic relationship management.
   • Key Features: Database abstraction, session/connection management, statement preparation, type binding, transaction support. Part of a larger C++ application framework.

SQL Wrappers / Type-Safe Query Builders (Often used instead of or alongside ORMs):

These focus more on providing C++-idiomatic ways to interact with databases and build queries safely, sometimes with basic object mapping.

6. SOCI (The C++ Database Access Library):
   • Description: A popular open-source library that provides a more abstract, C++-friendly interface to various database backends than raw C APIs or ODBC. It focuses on simplifying data binding, query execution, and type conversions.
   • Key Features: C++ idiomatic interface, type conversions, support for numerous backends (ODBC, PostgreSQL, MySQL, Oracle, SQLite, etc.), connection pooling, transaction support. Less focused on complex object relationship mapping, more on direct database interaction.
7. sqlpp11:
   • Description: An open-source library focused entirely on providing a type-safe embedded Domain Specific Language (DSL) within C++ for writing SQL queries. It aims to make SQL syntax errors impossible at compile time and prevents SQL injection vulnerabilities by construction. It can map results to structs but isn’t a full ORM managing object state or relationships.
   • Key Features: Extreme type safety, compile-time query checking, SQL injection prevention, supports multiple databases (SQL compilers available for PostgreSQL, MySQL, SQLite), header-only options.

Choosing in C++:

• Need a full-featured ORM with code generation and performance focus? ODB is a strong contender.
• Prefer a macro-based approach, possibly integrating with Qt? QxOrm is a good option.
• Working with SQLite/PostgreSQL/MySQL and prefer XML-based code generation? LiteSQL might fit.
• Already using Qt and need database access? The Qt SQL module is the natural choice, though you’ll implement ORM patterns yourself.
• Using Poco libraries? The Poco Data library provides solid database access.
• Want a C++-idiomatic wrapper over DB APIs without full ORM complexity? SOCI is very popular.
• Prioritize compile-time query safety above all else? sqlpp11 is designed specifically for that.

The C++ ecosystem often favors libraries that give more direct control or use compile-time features (like sqlpp11) or code generation (like ODB, LiteSQL) rather than runtime reflection common in other languages. Your choice will depend heavily on your specific needs regarding performance, type safety, ease of use, database support, and integration with other frameworks.