oliverrice

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?

(disclaimer: supabase employee)

OrioleDB continues to be a fully open source and liberally licensed. We're working with the OrioleDB team to provide an initial distribution channel so they can focus on the storage engine vs hosting + providing lots of user feedback/bug reports. Our shared goal is to advance OrioleDB until it becomes the go-to storage engine for Postgres, both on Supabase and everywhere else.

Happy to hear any concerns you have

yeah, fair shout `columnar index` for hybrid analytical workloads and `multi-master` roadmap items haven't been put in an order on the schedule yet so maybe multi-master makes sense to do first. Both align with webscale requirements though. Columnar would move into the AlloyDB space and multi-master would be more like PlanetScale (although not quite the same audience in the latter case)

what's your use-case for multi-master that would not be supported by something like regional routed for read-replicas with high availability? i.e. do you have a specific need for low global write latency, or is it motivated by something else?

In Studio you'd need to click on a query to get the recommendations but the most important queries to optimize are on several metrics like "Most time consuming", "Most frequent", "Slowest execution" are sorted worst-to-best in tab views.

But if you do want to scan all of your queries at once for possible indexes you can do it in SQL with

```sql

create extension index_advisor cascade schema extensions;

select ia., pss.query

from pg_stat_statements pss, lateral( select from extensions.index_advisor(pss.query)) ia

order by (total_cost_after::numeric - total_cost_before::numeric)

limit 100;

```

> I'm concerned about getting locked in

Supabase is one of the most portable platforms out there.

The whole stack is self-hostable and open source. All of the data are contained in Postgres. You're one pg_dump away from being able to switch to a different Postgres host. Or if you're switching to something else entirely, you can export the data to CSVs and take it anywhere. But we're confident you won't want to :)

disclaimer - Supabase employee