Yugabyte likes to point out that we're 56% compatible as compared to their 92% compatible with Postgres according to the Postgres Compatibility index.

It's sad that they need to use outdated information to get people's attention.

In the JSON describing our capabilities, you can clearly see the places where they've frozen our feature-set in time about two years ago. A sampling:

  1. "Vector": "no" <– Read more
  2. "Stored Procedures": "no" <– This feature is GA
  3. "Functions": "partial" <– This feature is GA
  4. "Triggers": "partial" <– This feature is GA
  5. "Row-Level Security": "partial" <– Read more

Our product architecture is also different; we've rewritten the database from scratch - it's harder work, but the results are generally better (defined as more scalable and more performant). So something like the whole "extensions" section, doesn't really make sense.

Reasonable questions to ask instead of trying to measure compatibility:

  • How long did it take Yugabyte to update to Postgres 15? What are the plans to get current with v18?
  • How many of the 200+ Postgres extensions do Yugabyte support? The PCI has a simple binary "extensions support" JSON element, but that doesn't give the flavor to the actual problem, nor does it allow for alternative approaches. CockroachDB doesn't support extensions, rather we build the functionality (where appropriate) into CockroachDB. Take pgVector as an example. Do we support the pgVector extension? No. Do we support pgVector functionality, with a familiar Postgres interface? Absolutely.

The only thing more questionable is that to beat us in performance, they couldn't go back only two years, they had to go back in time four years (!!!) and benchmark against v21.2. Our current release is 25.4, with 26.1 coming soon in February '26.