[eximius]

That's fair.

What I'm unsure of is how well proto can be modeled in various existing relational databases and what the performance and management consequences might be.

If I have a message defining a table and it has a field which is another message, how well can Postgres Structs represent that submessage? What are the performance implications? I'm not terribly familiar with the query semantics for Poatgres structs. How do migrations and backfills work for struct fields and nested structs?

These considerations may or may not justify a new database.

[hakanito]

Yeah I’m sure there are all sorts of considerations. Also not saying it’s straightforward, just easier than writing a new db. You can for example write proto message extensions to support custom field behaviours.

But like a sibling comment said here, if you want the database implementation to dictate your models you can probably generate protos from something like EdgeDB. But then the db implementation is in charge, which seem a bit backwards.

If you’ve used graphql you’re presented with a similar challenge but on the other end of the spectrum - the graphql schema that needs to map to application models.

So one of the main considerations is to figure out how and where you want to define your source models. Is it the view layer, the model layer or the database layer.

Tldr; yes you’re right, it depends!