Agreed, as a consultant in software engineering (not games though), a lot of companies that used to outsource have come back for many reasons, mainly communication and code quality.
Why would you not test your code with the same RDBMS you will have in production? Especially if it’s something as easy to install as Postgres? It seems like begging for trouble...
If you're using an ORM, it can be an easy way to ensure that no vendor specific stuff sneaks in. Also, until recently it was difficult to run, e.g., SQL Server in Docker, so Postgres might be easier to test with. Agreed SQLite is a weird choice, but not all integration tests are robust enough to test characteristics of the underlying db, i.e. focus on business logic not performance.
I have several dozen tests that run in completely separate DBs. With SQLite, the test suite runs through in 1 second:
$ time go test github.com/sapcc/limes/... | grep -v 'no test files'
ok github.com/sapcc/limes 0.004s
ok github.com/sapcc/limes/pkg/api 0.515s
ok github.com/sapcc/limes/pkg/collector 0.449s
ok github.com/sapcc/limes/pkg/core 0.006s
I doubt that you can setup and tear down several dozen Postgreses in that time.
That is the scary part isn't it. I'm sure only ruby users exist and that's awesome, but I would wager that most ruby users in the web field are rails users, and many blur where one starts and the other begins.
