pg_idkit
readyset
pg_idkit | readyset | |
---|---|---|
8 | 24 | |
307 | 3,883 | |
5.2% | 1.8% | |
8.6 | 9.8 | |
2 months ago | 6 days ago | |
Rust | Rust | |
Apache License 2.0 | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
pg_idkit
-
Shrink UUIDs with PostgreSQL or Ruby
Unfortunately, as of PostgreSQL 16, UUIDv7 are not yet supported out of the box. For the time being, use an extension such as pg_uuidv7 or pg_idkit to generate UUIDv7 e.g. as default primary key when you CREATE new records.
-
UUIDv7 is coming in PostgreSQL 17
If you like this (I do very much), you might also like pg_idkit[0] which is a little extension with a bunch of other kinds of IDs that you can generate inside PG, thanks to the seriously awesome pgrx[1] and Rust.
[0]: https://github.com/VADOSWARE/pg_idkit
[1]: https://github.com/pgcentralfoundation/pgrx
- Pg_idkit: A Postgres extension for generating popular UUIDs
-
Bye Sequence, Hello UUIDv7
Yup this is one of the reasons I put together a light extension for this:
https://github.com/VADOSWARE/pg_idkit
There are a lot of options for UUID extensions (lots of great pure SQL ones!), but I wanted to get as many ID generation strategies in one place
Also note that native UUID v7 is slated to land in pg17:
https://commitfest.postgresql.org/44/4388/
- Pg_idkit: Postgres Extension for Generating UUIDs
-
ULIDs and Primary Keys
https://github.com/ulid/spec/issues
I went through this exploration a while back for a new project and decided on uuidv7s, which are binary compatible with ULIDs but will likely find more support as they get added to the original UUID RFC.
Either UUIDv7 or XIDs seem like better choices than ULIDs for new projects.
* Supabase on different primary key considerations: https://supabase.com/blog/choosing-a-postgres-primary-key
* Postgres extension for generating various kinds of IDs: https://github.com/VADOSWARE/pg_idkit
-
Introducing pg_idkit: A Postgres extension for generating UUIDs
I also made an issue in the repo so eventually I should get to expanding the benchmark set as well.
readyset
-
Ask HN: How Can I Make My Front End React to Database Changes in Real-Time?
- Some platforms like Supabase Realtime [3] and Firebase offer subscription models to database changes, but these solutions fall short when dealing with complex queries involving joins or group-bys.
My vision is that the modern frontend to behave like a series of materialized views that dynamically update as the underlying data changes. Current state management libraries handle state trees well but don't seamlessly integrate with relational or graph-like database structures.
The only thing I can think of is to implement it by myself, which sounds like a big PITA.
Anything goes, Brainstorm with me. Is it causing you headaches as well? Are you familiar with an efficient solution? how are you all tackling it?
[1] https://readyset.io/
-
FLaNK Stack 26 February 2024
Postgresql + MySQL Cache https://github.com/readysettech/readyset
-
Readyset: A MySQL and Postgres wire-compatible caching layer
I just wanted to give a high five for having Jepsen tests for this: https://github.com/readysettech/readyset/tree/stable-240117/...
-
Fine-grained caching strategies of dynamic queries
This example is a great use case for partial incremental view maintenance systems like ReadySet: you automatically get something like the “prepopulating the cache” section (toward the end of the blog) while only caching the data the application is using, and avoiding the need to manually implement any sort of invalidation logic.
(Disclaimer: I used to work for them, but don’t anymore. It’s all available for free on GitHub though for anyone interested: https://github.com/readysettech/readyset)
-
Squeeze the hell out of the system you have
There are systems that will do that for you like https://readyset.io/.
-
Production grade databases in Rust
ReadySet
-
Dozer: A scalable Real-Time Data APIs backend written in Rust
readyset.io is the company that jonhoo was associated with for work on noria
-
I'm building Memories, a FOSS alternative to Google Photos with a focus on UX and performance
Might be interesting to try out https://readyset.io for this use case.
- Materialized View: SQL Queries on Steroids
-
Tips on scaling a monolithic Rust web server?
On the caching topic, I found the ReadySet(né Noria) approach to be extremely interesting.
What are some alternatives?
cuid2 - Next generation guids. Secure, collision-resistant ids optimized for horizontal scaling and performance.
materialize - The data warehouse for operational workloads.
postgresql-uuid-generate-v7
noria - Fast web applications through dynamic, partially-stateful dataflow
diesel - A safe, extensible ORM and Query Builder for Rust
singleflight - Rust port of Go's singleflight package
cube.js - 📊 Cube — The Semantic Layer for Building Data Applications
chiselstrike - ChiselStrike abstracts common backends components like databases and message queues, and let you drive them from a convenient TypeScript business logic layer
ksuid - K-Sortable Globally Unique IDs
googleapis - Public interface definitions of Google APIs.
pgx - Build Postgres Extensions with Rust! [Moved to: https://github.com/tcdi/pgrx]
genSQL - A SQL generator tool to create random rows for test schemas