You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the past we sometimes had issues that unit tests and the "real" application would behave differently because one is running with sqlite, the other with a real Postgres DB.
We basically have two use cases for sqlite/embedded Postgres:
Unit tests of our services that need persistence. Not all of the unit tests need that, so we probably would need some kind of util function to "enable" it for a particular test file. I would imagine that embedded Postgres is a little bit slower than sqlite
The "demo" mode. In this mode we are currently using an in-memory sqlite database, just to demonstrate things, such as showing the UI, etc. This could easily be done with an embedded Postgres
Con:
Not sure about the file size?
Speed?
Pro:
We probably could get rid of a few dependencies, since our non-CGO sqlite dependencies includes a lot of transitive dependencies that basically include the whole C standard library transcoded into Go, such as modernc.org/libc
The text was updated successfully, but these errors were encountered:
Instead of having basically two database systems sqlite and Postgres, we could possibly get rid of sqlite with https://github.com/fergusstrange/embedded-postgres.
In the past we sometimes had issues that unit tests and the "real" application would behave differently because one is running with sqlite, the other with a real Postgres DB.
We basically have two use cases for sqlite/embedded Postgres:
Con:
Pro:
The text was updated successfully, but these errors were encountered: