postgresql_cluster VS embedded-postgres

Creating a robust and reliable database cluster is often fraught with challenges.A manual deployment process can be fraught with risks, particularly for those who lack extensive experience. Even minor errors in configuration can drastically affect your database's performance and stability.

Recognizing this intricacy, many businesses choose to use cloud-based managed databases. These services offer convenience but not without limitations. These drawbacks can include being tied to a specific cloud provider and limited direct access to the database server for adjustments. These constraints can hinder your ability to tune your system and perform thorough performance analyses.

In response to these challenges, we've developed a project to make this process easier and more efficient. This project uses automation to streamline the deployment of High-Availability PostgreSQL Clusters. By doing so, it helps mitigate the risks involved with manual configuration and speeds up the deployment process.

Our solution caters to various deployment environments. It allows you to establish your cluster either in your own data center or in the cloud, providing a robust database solution similar to managed databases, but with you retaining full control.

Explore the project here: https://github.com/vitabaks/postgresql_cluster

FYI: postgresql_cluster

HA postgres

If not Kubernetes, check out this: https://github.com/vitabaks/postgresql_cluster – Postgres + patroni + pgBouncer + WAL-G or pgBackRest + Netdata + more, managed by Ansible.

If you do want to use Kubernetes, then check out StackGres.io and https://github.com/zalando/postgres-operator

Also check PostgreSQL High-Availability Cluster (based on "Patroni" and "DCS(etcd)"). Automating deployment with Ansible.

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.