HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
cornucopia-rs
cornucopia
Rust2023–2024
cornucopia-rs / cornucopia

cornucopia

Generate type-checked Rust from your PostgreSQL.

5Distinct people
6Mentions
0Explicit recommenders
1.2KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Generate type-checked Rust from your PostgreSQL.

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by month6 dated mentions

Observed mentions: 2023-01-06 22:21:40 UTC to 2024-09-24 08:59:36 UTC.

0122023-01-01 00:00:00 UTC to 2023-02-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsJan 20232023-02-01 00:00:00 UTC to 2023-03-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2023-03-01 00:00:00 UTC to 2023-04-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-04-01 00:00:00 UTC to 2023-05-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-05-01 00:00:00 UTC to 2023-06-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-06-01 00:00:00 UTC to 2023-07-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2023-07-01 00:00:00 UTC to 2023-08-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-08-01 00:00:00 UTC to 2023-09-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-09-01 00:00:00 UTC to 2023-10-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-10-01 00:00:00 UTC to 2023-11-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-11-01 00:00:00 UTC to 2023-12-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 commentsNov 20232023-12-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-01 00:00:00 UTC to 2024-02-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-02-01 00:00:00 UTC to 2024-03-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024-03-01 00:00:00 UTC to 2024-04-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-04-01 00:00:00 UTC to 2024-05-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-05-01 00:00:00 UTC to 2024-06-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-06-01 00:00:00 UTC to 2024-07-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-07-01 00:00:00 UTC to 2024-08-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-08-01 00:00:00 UTC to 2024-09-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-09-01 00:00:00 UTC to 2024-10-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 commentsSep 2024

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
Jan 20232023-01-01 00:00:00 UTC2023-02-01 00:00:00 UTC101
Feb 20232023-02-01 00:00:00 UTC2023-03-01 00:00:00 UTC101
Mar 20232023-03-01 00:00:00 UTC2023-04-01 00:00:00 UTC000
Apr 20232023-04-01 00:00:00 UTC2023-05-01 00:00:00 UTC000
May 20232023-05-01 00:00:00 UTC2023-06-01 00:00:00 UTC000
Jun 20232023-06-01 00:00:00 UTC2023-07-01 00:00:00 UTC101
Jul 20232023-07-01 00:00:00 UTC2023-08-01 00:00:00 UTC000
Aug 20232023-08-01 00:00:00 UTC2023-09-01 00:00:00 UTC000
Sep 20232023-09-01 00:00:00 UTC2023-10-01 00:00:00 UTC000
Oct 20232023-10-01 00:00:00 UTC2023-11-01 00:00:00 UTC000
Nov 20232023-11-01 00:00:00 UTC2023-12-01 00:00:00 UTC000
Dec 20232023-12-01 00:00:00 UTC2024-01-01 00:00:00 UTC000
Jan 20242024-01-01 00:00:00 UTC2024-02-01 00:00:00 UTC000
Feb 20242024-02-01 00:00:00 UTC2024-03-01 00:00:00 UTC101
Mar 20242024-03-01 00:00:00 UTC2024-04-01 00:00:00 UTC000
Apr 20242024-04-01 00:00:00 UTC2024-05-01 00:00:00 UTC000
May 20242024-05-01 00:00:00 UTC2024-06-01 00:00:00 UTC000
Jun 20242024-06-01 00:00:00 UTC2024-07-01 00:00:00 UTC000
Jul 20242024-07-01 00:00:00 UTC2024-08-01 00:00:00 UTC000
Aug 20242024-08-01 00:00:00 UTC2024-09-01 00:00:00 UTC000
Sep 20242024-09-01 00:00:00 UTC2024-10-01 00:00:00 UTC202

What Hacker News says

6 sources
I make no assumption about your level of knowledge, I simply stated that sqlx is a dependency just for completeness. I also did not imply anything about whether having such a dependency makes for faster or slower compile times than without. Anyway, my comparison was with regards to SeaORM (and/or sqlx) versus Diesel. SeaORM explicitly say they are not fully typesafe. From the docs [0]: > Using a completely static query builder can eliminate this entire class of errors. However, it requires that every parameter be defined statically and available compile-time. This is a harsh requirement, as there is always something you could not know until your program starts (environment variables) and runs (runtime configuration change). This is especially awkward if you come from a scripting language background where the type system has always been dy
Read the rest
namic. > As such, SeaORM does not attempt to check things at compile-time. We intend to (still in development) provide runtime linting on the dynamically generated queries against the mentioned problems that you can enable in unit tests but disable in production. That is simply a deal breaker for me. I use an ORM specifically to be fully compile-time safe, so having this sort of "escape hatch" in a language that is already typesafe and sound is just going backwards. In contrast, Diesel is fully typesafe and fixes all of the issues from [0], even for dynamic queries [1]. This all being said, I have also found Prisma Client Rust [2] and Cornucopia [3] to be viable alternatives to the "big 3 (SeaORM, sqlx, Diesel)" so to speak. PCR uses Prisma to generate an ORM but is generally slower due to the overhead of running the Prisma engine, but it's ergonomic if you already use Prisma in the TypeScript world, and it's a pretty good ORM itself. I have not used Cornucopia as much but it is less of an ORM and more of a way to generate types in Rust from your SQL. There is some discussion about them on reddit, for comparison [4]. [0] https://www.sea-ql.org/SeaORM/docs/write-test/testing/#1-typ... [1] https://old.reddit.com/r/rust/comments/w54ydi/diesel_200_rc1... [2] https://github.com/Brendonovich/Prisma-Client-Rust [3] https://github.com/cornucopia-rs/cornucopia [4] https://old.reddit.com/r/rust/comments/wdos9x/cornucopia_v08...
In One Year of Rust in Production
Does it support multiple queries per sql file? My use case is to use this to autocomplete queries made with Cornucopia [0] Cornucopia queries look like this (here is a something.sql file) --! authors SELECT first_name, last_name, country FROM Authors; --! insert_author INSERT INTO Authors(first_name, last_name, country) VALUES (:first_name, :last_name, :country); There are multiple queries each separated by ; and on top of each query, there's a comment giving a name to the query (it's more like a header) I think the only thing that might require specific support in postgres_lsp is using the :parameter_name syntax for prepared statements [1] (in vanilla Postgres would be something like $1 or $2, but in Cornucopia it is named to aid readability). But, if postgres_lsp is forgiging enough to not choke on that, then it s
Read the rest
In We built our customer data warehouse all on Postgres
While we're on the subject of ORM's I really like the https://github.com/cornucopia-rs/cornucopia way of doing things. Basically write SQL in a file and code generate a function that runs the SQL for you and puts it into a struct (this one is for rust) I think there's a library to do the same thing with typescript. For me, the best way to talk to the database is with SQL and I don't have to learn an ORMs way of doing it.
In Oops, You Wrote a Database
The best solution I've ever seen is this Rust library https://github.com/cornucopia-rs/cornucopia You write plain SQL for you schema (just a schema.sql is enough) and plain SQL functions for your queries. Then it generates Rust types and Rust functions from from that. If you don't use Rust, maybe there's a library like that for your favorite language. Optionally, pair it with https://github.com/bikeshedder/tusker or https://github.com/blainehansen/postgres_migrator (both are based off https://github.com/djrobstep/migra) to generate migrations by diffing your schema.sql files, and https://github.com/rust-db/refinery to perform those migrations. Now, if you have simple crud needs, you should probably use https://postgrest.org/en/stable/ and not an ORM. There are packages like https://www.npmjs.com/package/@supabase/postgrest-js (for JS / ty
Read the rest
pescript) and probably for other languages too. If you insist on an ORM, the best of the bunch is prisma https://www.prisma.io/ - outside of the typescript/javascript ecosystem it has ports for some other languages (with varying degrees of completion), the one I know about is the Rust one https://prisma.brendonovich.dev/introduction
In Ask HN: ORM or Native SQL?

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.