Introduction¶
db-gen is a CLI tool that generates database-access code from PostgreSQL stored functions and procedures. You point it at a database, it reads the metadata of your routines, and it renders code — in your language, in your style — that calls them.
Is db-gen an ORM?¶
No. db-gen is not an ORM in the sense of Entity Framework, Ecto, or Doctrine. In our experience full ORMs are clumsy, generate inefficient SQL, and push developers toward dead ends.
A typical example of inefficient database use is multi-step processing of imported data. Instead of one bulk copy and a single call to process the data, an ORM makes you split the logic into many round-trips — slower, more work, and usually less safe.
db-gen takes the opposite stance: you write stored functions/procedures in PostgreSQL, and the tool generates the code that calls them and maps the results.
What problems it addresses¶
Design goals
- Consistency of generation over years
- In-house templates and configuration
- Customization based on your needs
- Offline use
Consistency over years¶
Tools and frameworks come and go. A binary that worked with yesterday's framework often won't work with tomorrow's — and enterprise applications routinely go untouched for years for budget reasons.
db-gen is a small, self-contained executable you commit alongside your code. It generates the same code today, tomorrow, and in five years, with nothing to re-download.
In-house templates and configuration¶
All configuration, including the templates used for code generation, lives in your repository. Nothing depends on an internet service or an installed tool.
Customization¶
Because everything is under your control, you can target any language, database driver, or logger — just edit the template. You can even swap templates per environment (for example, to strip dev-only logging in CI/CD).
Offline use¶
Air-gapped, security-sensitive, or simply disconnected environments are fully supported. Export your routine metadata to JSON once, then generate forever without a database connection. See Offline & Change Detection.
Who it's for¶
Teams that:
- prefer stored functions/procedures over ORM-generated SQL,
- need code generation that is stable and reproducible over long timeframes,
- want full control over the generated output's language and style, and
- value working without external dependencies.
Not just for the enterprise
Don't let "enterprise" discourage you — there's no reason not to use db-gen for a single-function database.
Next: Installation.