Yes and no. The point of an actual ORM (object relational mapper) is to be able to the equivalent of lisp/smalltalk (runtime) image level perstiance: make objec

Yes and no. The point of an actual ORM (object relational mapper) is to be able to the equivalent of lisp/smalltalk (runtime) image level perstiance: make objects permanent between restarts and changes transactional. To really get there, you actually need a object db, like zoodb[z] for python (which incidentally can use pg as a storage back-end). If you're using a db abstraction layer, and a typical active record like surrogate keys - then for simple use cases you can indeed switch back-ends; many rails projects run tests on sqlite and production on postgresql. That's not a great idea, but it works for simple projects (first gotcha; most rdbms don't have a global namspace for indexes; sqlite does). But there's no standard AFAIK for full text indexes, geodata, json/bson, materialized views... So it depends a lot on how much of the db you're actually using. [z] http://www.zodb.org/en/latest/tutorial.html http://www.zodb.org/en/latest/tutorial.html Note that an object db does not free you from thinking about data structure migrations: http://www.zodb.org/en/latest/guide/writing-persistent-objects.html http://www.zodb.org/en/latest/guide/writing-persistent-objec... https://pypi.org/project/zope.generations/ https://pypi.org/project/zope.generations/