So, I've just started using polylith myself, and what I've opted for is abstracting database access into its own component

That is: I have a mysql component, with some exposed functions that wrap some generic queries, and then lets say I have some family of things that access the Widget table: I then make a widget component, and expose functions that query that table behind the scenes (through the mysql component).

Example functions would just be stuff like

(defn db [] (mysql/get-datasource-by-name :widget-db))
(defn find-by-id [id]
  (mysql/query! (db) 
    {:select [:*] :from [:widgets] :where [:= :id id]}))

;; Note that my mysql/query! function expects a honey-map, I have raw versions exposed as well

And you would then access that in another component via (widget/find-by-id 42)

Thanks for this, I can see how this pattern would insulate code from db changes a bit better. I do still wonder how people have handled deployments of multiple services that depend on a component that has breaking changes, and how migrations are handled

How to handle DDL changes to your database(s) and deploy your running application(s) can be tricky, whether you use Polylith or not. I think you need to execute the database upgrade script(s) before or after you deploy your affected project artefacts, depending on the options you have (whether the database change is breaking or not).

thanks, ye we've been thinking a long those lines