11–19 of 19 posts
Probably the best thing would be to wait until there's some kind of v0 and then post https://github.com/multigres/multigres. It's certainly on topic, there just needs to be some meat on the bones, or some bones.
- Postgres has transactional DDL vs auto-commit. Can that property be retained?
- Postgres leans into extensions much more that Mysql. Will types/indexes/etc introduced by e.g. pg_vector or postgis, have a path for support?
anything similar that will be a challenge?
I don’t know if this is a question for you or for the Supabase leadership team. But, what is the primary reason for building something “new” instead of using the tools already existing in the Postgres ecosystem like Citus or pgdog? What are the gaps in those which you expect to solve with Vitess for Postgres?
The cool features that I can think of: A formal sharding scheme based on relational foundations, a fairly advanced query analyzer and routing engine capable of cross-shard functionality, HA and durability, abilities to reshard safely, seamless migrations, etc.
It's a pretty big list of capabilities.
how are you thinking the differences between mysql and postgres will impact multigres vs vitess? The ones the jump to mind are - Postgres has transactional DDL vs auto-commit. Can that property be retained? - Postgres leans into extensions much more that Mysql. Will types/indexes/etc introduced by e.g. pg_vector or postgis, have a path for support? anything similar that will be a challenge?
I also see such a clean 2PC API. This was another huge mess on the MySQL side.
One peice of tooling I've wanted for Vitess is for it to make recommendations about sharding keys based on the statistics it collects + query patterns. Seems like it's in the perfect location to collect the data for that and remove the mental overhead associated w sharding. If much of the implementation has to be rebuilt, is there a path for that in this implementation?
how are you thinking the differences between mysql and postgres will impact multigres vs vitess? The ones the jump to mind are - Postgres has transactional DDL vs auto-commit. Can that property be retained? - Postgres leans into extensions much more that Mysql. Will types/indexes/etc introduced by e.g. pg_vector or postgis, have a path for support? anything similar that will be a challenge?
Hello HN, co-creator of Vitess here. The goal of Multigres is to build an open source adaptation of Vitess for Postgres. In terms of project plan, we're still deciding. One option is to fork and retrofit. This will give us immedate results, but we'll be inherting quite a bit of legacy that we'll have to overcome later. The other option is to start with a clean slate and move pieces from the original Vitess code. This…
Excited to follow your progress :)
I am a little sad Plantscale didn't get this. But hopefully this will push Postgres ecosystem forward. In many ways both Postgres and MySQL is still so far behind Oracle and MSSQL.