-
embedded-postgres
Run a real Postgres database locally on Linux, OSX or Windows as part of another Go application or test
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
bytebase
The GitLab/GitHub for database DevOps. World's most advanced database DevOps and CI/CD for Developer, DBA and Platform Engineering teams.
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
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.
Another option could be also Genji - https://github.com/genjidb/genji
And with litestream.io/ you can have semi-non-blocking backups.
You could try https://github.com/objectbox/objectbox-go. I have not used the go version, but a coworker is using it for dart and it made a good impression. I like that its type safe
Bytebase embedds postgresql per platform. If it helps. https://github.com/bytebase/bytebase/tree/main/resources/postgres
This is indeed a concern, but not one I've needed to care about (or the ordering of columns on disk in general). Using an intermediate table might be OK if you use it as part of automatic DB migrations. I use golang-migrate, YMMV.
Just know that dgraph (which you also mentioned) appears to be in its death throws. The original developer has left, forked it and is working on starting a new company around it. I'm rooting for him because it's a great database.