Ask HN: Scaling an ORM-Gated DB to Support Multiple Accessing Languages

As some background: we've invested heavily in SQLAlchemy, as our ORM connecting Python to Postgres, at my current employer, to the point that we do all of our CRUD operations through SQLAlchemy models.

While we love the productivity gains, especially in terms of testing, we are beginning to feel some growing pains.

In particular, our dependence discourages us from playing with other languages. For example, we would like our SQL statements in Go and Python to come from the same source of truth. Leaning on SQLAlchemy prevents this (there's no Go bindings, and it wouldn't make sense for there to be).

This makes us reluctant to write any db-touching code in another language, because it would mean that changes to our db schema would require N times the number of code changes, where N is the number of languages our db-downstream services are written in.

We've considered creating a thin wrapper service around our database (in SQLAlchemy), and making all of our services (python or otherwise) downstream to this, but that feels extremely overkill, and not obviously worth the upside.

Have any of you encountered this growing pain and overcome it? If so, how did you do it?