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 will ensure that Multigres has the Postgres DNA. We'll also avoid inheriting legacy features. Let us know your thoughts on this.
I'll try my best to answer any other questions you may have.
* Are you also considering going the Postgres extension route, like Citus? It is after all the best attempt at sharding Postgres so far.
* If you are willing to share, why not doing this from inside Planetscale? I assume it was at least considered over the years.
Excited to follow your progress :)
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.
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.
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.
- 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.
