MySQL Integration #64

New Issue

OVERLORD · 2026-02-04T16:57:39+03:00

OVERLORD commented

2026-02-04 16:57:39 +03:00

Originally created by @drOnygames on GitHub (Jan 21, 2021).

Hi there, I was just wondering if it is possible to connect to an mysql server which is password protected as I didn't find anything in the docs.

Thanks in advance! :D

Originally created by @drOnygames on GitHub (Jan 21, 2021). Hi there, I was just wondering if it is possible to connect to an mysql server which is password protected as I didn't find anything in the docs. Thanks in advance! :D

OVERLORD commented

2026-02-04 16:57:48 +03:00

@meltyshev commented on GitHub (Feb 8, 2021):

Hi! MySQL server is not supported yet, only PostgreSQL. This feature already in the roadmap.

@meltyshev commented on GitHub (Feb 8, 2021): Hi! MySQL server is not supported yet, only PostgreSQL. This feature already in the roadmap.

OVERLORD commented

2026-02-04 16:57:55 +03:00

@nickbe commented on GitHub (Feb 8, 2021):

although to be hones PostgreSQL is rather better in my opinion.

@nickbe commented on GitHub (Feb 8, 2021): although to be hones PostgreSQL is rather better in my opinion.

OVERLORD commented

2026-02-04 16:58:01 +03:00

@newhinton commented on GitHub (Mar 3, 2021):

@meltyshev @nickbe I am trying to switch knex to use the query builder, so that planka gets dbms-agnostic, but before i can do anything serious, how should i treat the existing migrations? I need to do something with them, im just not sure what

Edit: As far as i looked into it, the main issue is the next_id() function. Is there a reason table.increments() is not used for that? Also there are two raw statements regarding uinque constrains and emails which need to change. Irregardless of the implementation, i assume those changes can cause problems on existing databases. (Changing migrations isn't really a great thing to do, but something needs to change when more than postgresql should be supported

@newhinton commented on GitHub (Mar 3, 2021): @meltyshev @nickbe I am trying to switch knex to use the query builder, so that planka gets dbms-agnostic, but before i can do anything serious, how should i treat the existing migrations? I need to do something with them, im just not sure what Edit: As far as i looked into it, the main issue is the `next_id()` function. Is there a reason `table.increments()` is not used for that? Also there are two raw statements regarding uinque constrains and emails which need to change. Irregardless of the implementation, i assume those changes can cause problems on existing databases. (Changing migrations isn't really a great thing to do, but something needs to change when more than postgresql should be supported

OVERLORD commented

2026-02-04 16:58:05 +03:00

@timdonovanuk commented on GitHub (Apr 15, 2021):

A lot of projects these days are using mariadb, and I would bet money that people self hosting are already running a mariadb instance, serving multiple applications. Would this be possible? Thank you :)

@timdonovanuk commented on GitHub (Apr 15, 2021): A lot of projects these days are using mariadb, and I would bet money that people self hosting are already running a mariadb instance, serving multiple applications. Would this be possible? Thank you :)

OVERLORD commented

2026-02-04 16:58:09 +03:00

@nickbe commented on GitHub (Apr 18, 2021):

Coming from Oracle and MSSQLServer I don't favor either MariaDB nor MySQL due to several dataloss scenarious in the past. Both are the typical web playground. But PostgreSQL is highly fault-tolerant and extremely well programmed in depth.

Also to be honest I'm completely against the typical "everything has to run on multiple databases" nonsense nowadays. Rather the specific advantages of one engine should be used over the others. With multiple database engines come multiple problems - more support - more time consuming.

We want to rely on the strength of PostreSQL. The internal mechanisms of Postgres are extremely well designed. Also its scalabilty is excellent. Having said this the current database was definetely a very wise choice and it should be kept this way.

@nickbe commented on GitHub (Apr 18, 2021): Coming from Oracle and MSSQLServer I don't favor either MariaDB nor MySQL due to several dataloss scenarious in the past. Both are the typical web playground. But PostgreSQL is highly fault-tolerant and extremely well programmed in depth. Also to be honest I'm completely against the typical "everything has to run on multiple databases" nonsense nowadays. Rather the specific advantages of one engine should be used over the others. With multiple database engines come multiple problems - more support - more time consuming. We want to rely on the strength of PostreSQL. The internal mechanisms of Postgres are extremely well designed. Also its scalabilty is excellent. Having said this the current database was definetely a very wise choice and it should be kept this way.

OVERLORD commented

2026-02-04 16:58:15 +03:00

@timdonovanuk commented on GitHub (Jul 10, 2021):

With multiple database engines come multiple problems - more support - more time consuming. so the solution to that is people already running msql/mariadb now have to spin up and maintain multiple databases? :D

I'm being cheeky - its absolutely fair enough as an app developer to only want to support a single well known configuration against one database.

Just frustrating that I'm running 27 containers, out of that, 7 need a database, and 7 of them support mariadb. Now I'm now running 29 containers (planka + postgres) ;) I'll go ask the other 7 projects to see if they'd be interested in supporting postgres I guess!

Edit: well I'll eat my hat, because the majority do support postgres! Guess I'm looking at mariadb -> postgres exporters this weekend.

Cheers!

@timdonovanuk commented on GitHub (Jul 10, 2021): `With multiple database engines come multiple problems - more support - more time consuming.` so the solution to that is people already running msql/mariadb now have to spin up and maintain multiple databases? :D I'm being cheeky - its absolutely fair enough as an app developer to only want to support a single well known configuration against one database. Just frustrating that I'm running 27 containers, out of that, 7 need a database, and 7 of them support mariadb. Now I'm now running 29 containers (planka + postgres) ;) I'll go ask the other 7 projects to see if they'd be interested in supporting postgres I guess! Edit: well I'll eat my hat, because the majority do support postgres! Guess I'm looking at mariadb -> postgres exporters this weekend. Cheers!

OVERLORD commented

2026-02-04 16:58:18 +03:00

@nickbe commented on GitHub (Jul 11, 2021):

Let me put this another way. PostgreSQL wasn't chosen randomly - but because some people prefer it over mySQL (call it Maria of you like - it's still all the same to me - still loosing data when it crashes - had that - been there - don't like it)

All that multiple database and abstraction layour nonsense would practically make most databases and features obsolete because you will never have benefits of the exclusive features of one over another. So everyone just uses Maria/mySQL and everyone's happy.... I don't think so.

So let's just use Postgres for now and we'll see about anything else when the version has been finished.

@nickbe commented on GitHub (Jul 11, 2021): Let me put this another way. PostgreSQL wasn't chosen randomly - but because some people prefer it over mySQL (call it Maria of you like - it's still all the same to me - still loosing data when it crashes - had that - been there - don't like it) All that multiple database and abstraction layour nonsense would practically make most databases and features obsolete because you will never have benefits of the exclusive features of one over another. So everyone just uses Maria/mySQL and everyone's happy.... I don't think so. So let's just use Postgres for now and we'll see about anything else when the version has been finished.

OVERLORD commented

2026-02-04 16:58:27 +03:00

@timdonovanuk commented on GitHub (Jul 12, 2021):