goc VS embedded-postgres

A few years ago, I used goc to collect coverage from multiple services at the same time when they were used in E2E tests. I was very happy with it. Check it out!

https://github.com/qiniu/goc

So what can you do insted? For testing databases, setup a docker instance for tests (e.g. like in https://github.com/ardanlabs/service), or start an embedded-postgres daemon (see https://github.com/fergusstrange/embedded-postgres). For communication with external APIs, just pass the http.Client (either in context.Context or as a field on the struct). Then in tests, you can override the http.Client.Transport func.

This is down to nuance, but all databases are "file based" as they all write to files. But most of them require a separate process with lock coordination to get away from writer lock delays and ensure ACID, which includes Postgresql. Calling any version of pgl "embedded" is confusing because I see that being used to describe pgl databases which are run in a localhost mode with a single reader/writer client. Regardless, those still require a postgres process and access it over IP. For simplicity, if one uses a database by touching its files directly from the process accessing the database, then it's "embedded"; but then again I guess that semantic ship has sailed: https://github.com/fergusstrange/embedded-postgres so the point may be moot.

depending on the language you have chosen for your side project you might also be able to run postgresql in embedded mode here is the one for golang https://github.com/fergusstrange/embedded-postgres . There is similar solution for java as well.