#sql #orm #postgres

bin+lib sql_db_mapper

Maps a SQL database to rust structs and functions

3 releases

✓ Uses Rust 2018 edition

0.0.3 Jan 14, 2020
0.0.2 Jan 13, 2020
0.0.1 Jan 4, 2020

#148 in Database interfaces


1.5K SLoC


A command line utility for generating rust mappings to databases.

Connects to a PostgreSQL database and creates a rust module representing all the schemas complete with mappings for stored functions/procedures

Defaults to creating an async wrapping using tokio-postgres but has a flag to make synchronous functions with postgres instead


Once generated the generated code does not contain additional checks that the database schema hasn't changed. While some type conversions will fail on the call care should be taken to update the generated code at the same time as the database

All functions generated take the client used to connect to the database as the first argument

SQL procedures/functons which are overloaded (two with the same name and different arguments) are mapped in this crate to functions which take a single tuple i,e, my_func((client, id, "hello")) and my_func((client, id)) this means overloading a previously not overloaded SQL procedure would be a breaking change with regards to the generated code


sql_db_mapper 0.0.2
Generate a rust wrapper for a PostgreSQL database

    sql_db_mapper [FLAGS] <conn-string> [output]

    -d, --debug      Activate debug mode
    -h, --help       Prints help information
    -s, --sync       Generate synchronous mapping
    -u, --ugly       Skip running output through rustfmt
    -V, --version    Prints version information

    <conn-string>    String to connect to database, see tokio_postgres::Config for details
    <output>         Output file, stdout if not present


Contains reexports and helper types which the generated code pulls in


Features a derive macro from TryFromRow (defined in sql_db_mapper_core) which provides conversions from postgres' Row struct

Future Work

  • more options relating to how the code is generated
    • derives that may be wanted (serde comes to mind)
    • add option for all generated functions to take a tuple to avoid client breaking changes noted above
    • a derive or other proc_macro version of the code. It may not be recommended for compile time reasons but perhaps somebody would appreciate it
    • generate a whole (properly-structured) crate wrapping the database rather than one file and printing the dependencies to the console
    • increasing performance
    • use heck to allow names to be mapped to appropriate rust equivalents
  • consider adding support for other popular databases as well
    • either through connecting to the database as is being currently done or possibly by parsing SQL itself


Licensed under either of

at your option.


Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.


~150K SLoC