HikariCP VS Flyway

> are they using a connection pooler

We use Hikari [1] an in-process connection pooler. We didn't opt for pgbouncer at al, because we didn't want to add the extra infra yet.

> since what they did in code can be natively done with PgBouncer, PgCat, et al.

Can you point me to a reference I could look at, about doing a major version upgrade with PgBouncer et al? My understanding that we would still need to write a script to switch masters, similar to what we wrote.

> all the active connections

The active connections we were referring too were websocket connections, we haven't had problems with PG connections.

Right now the algorithm we use to find affected queries and notify websockets starts to falter when the number of active websocket connections get too high. We're working on improving it in the coming weeks. I'll update the essay to clarify.

> I did feel for them here:

Thank you! That part was definitely the most frustrating.

[1] https://github.com/brettwooldridge/HikariCP

// Create a DataSource object, for example using [HikariCP](https://github.com/brettwooldridge/HikariCP) // Kapper is un-opinionated about which pooler, if any you use. val dataSource = HikariDataSource().apply { jdbcUrl = "jdbc:PostgreSQL://localhost:5432/mydatabase" username = "username" password = "password" } // The Kapper API is exposed as an extension of the java.sql.Connection interface: dataSource.connection.use { connection -> // Do database stuff }

No contexto específico estava sendo falado sobre o Hikari Connection Pool. Mas, se o Hikari é um Connection Pool, o que seria um "Pool"?

Looks like HikariCP is also awaiting fixes for this https://github.com/brettwooldridge/HikariCP/pull/2055

I have used hikari and exposed to do this in the past with postgres, although other dialects are supported.

I found one suggestion from the author of HikariCP on how to address this, which I implemented and it worked. However, there are additional classes involved, and it feels a little clunky and hard to follow.

Not really, you can change some things in spring boot but doing so will typically trigger a refresh which is less reliable than restarting but still causes a large performance hit. You could probably do it with hikari if you really needed to but it's inadvisable to build your application around this mechanic.

Flyway is a Java-based migration tool that’s widely used in enterprise settings. While not Go-native, you can integrate it into Go projects using its CLI or by calling its Java library. Flyway is great for teams needing robust versioning and audit-ready migration history.

Usually there is a need to run SQL database updates: update table columns, add new rows, create a new schema etc. Often developer teams are using Flyway It is an open-source database SQL deployment tool. In Flyway, all DDL and DML changes to the database are called migrations. Migrations can be versioned or repeatable.

Our client's engineering team recommended Flyway and successfully used it to manage their migrations. We chose to adopt Flyway due to its simplicity, speed, reliability, and successful implementation by our client's engineering team. Their existing codebase and experiences allowed us to transition smoothly to Flyway.

Flyway

The session logs show that the application loads configurations and establishes a connection with a PostgreSQL database. This involves initializing a HikariCP connection pool and Flyway for database migrations. The logs confirm that the database schema validation and migration checks were successful. The startup of the Jetty HTTP server follows, and the server becomes operational and ready to accept requests on the specified port.

Also RedGate, but Flyway has some reasons to recommend it over RedGate Deploy depending on your DBAs/workflows: https://flywaydb.org/

(Though I don't think it is "complete" or "perfect", either.)

EF Migrations are in a really good place now if you like/don't mind C# as a language (and you can easily embed SQL inside the C#, too, but there are benefits to being able to also run high level C# code). With today's tooling you can package your migration "runner application" as a single deployable executable for most platforms. You can build the executable once and run it in all your environments. (The same tool that updates your QA and Staging updates your Prod, testably running the same migrations.) Given the single executable deployable I might even consider using it for projects not themselves written in C#.

There is a bit of tooling needed but is already around. For Java for example I had very good experience with a combination of flyway [1] for migrations, testcontainers [2] for making integration tests as easy as unit tests and querydsl [3] for a query and mapping layer.

[1] https://github.com/flyway/flyway

[2] https://java.testcontainers.org/modules/databases/postgres/

[3] https://github.com/querydsl/querydsl

When software starts using a database, it's advisable to have version control, just as we have Github to control our source code. This is all to be sure about what was executed for that specific version. For Java and Spring boot, we have the Flyway framework that aims to resolve this situation, free of charge.

If you're looking for tools, like https://www.liquibase.com/ or https://flywaydb.org/, which are database-state-based schema migration toolkits - it might be relatively straightforward to build similar ones using Databricks SQL drivers.