A PostgreSQL abstraction layer for Go with GORM-like syntax, focusing on security and performance.
Igor is a Go library that serves as an abstraction layer for PostgreSQL, providing a GORM-like syntax for database operations. It enables developers to perform CRUD operations in a secure, fast, and intuitive manner, leveraging PostgreSQL's advanced features like JSONB support and prepared statements. The library focuses on simplifying data access while maintaining high performance and security standards.
Go developers working with PostgreSQL who need a lightweight, secure abstraction layer for database operations without the complexity of a full ORM. It is ideal for projects where performance and SQL injection prevention are critical.
Developers choose Igor for its balance of GORM compatibility and PostgreSQL-specific optimizations, offering prepared statements by default for security, native support for PostgreSQL types, and efficient CRUD operations without the overhead of associations or DDL management.
igor is an abstraction layer for PostgreSQL with a gorm like syntax.
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Uses prepared statements by default for all queries, preventing SQL injection and improving performance, as emphasized in the README's security focus.
Supports PostgreSQL-specific types like JSONB and arrays natively, and integrates LISTEN/NOTIFY for event-driven workflows, leveraging database optimizations.
Maintains syntax compatibility with GORM, easing migration for existing projects, though with noted differences in method order and model requirements.
Exploits PostgreSQL's RETURNING clause to automatically update model fields with database-generated values, ensuring data consistency after inserts and updates.
Lacks support for associations, callbacks, and soft delete, which are standard in full ORMs and necessary for complex data modeling, as admitted in the README.
Requires calling Model before Select, unlike GORM, which can cause errors if not followed and complicates code refactoring, as highlighted in the Differences section.
Some methods, such as Where without conditions or Delete with empty models, panic instead of returning errors, making error management less robust in production.
Designed exclusively for PostgreSQL, so it cannot be used with other databases, limiting flexibility for projects that might need multi-database support.