[GH-ISSUE #202] Support MySQL #93

New issue

Open

opened 2026-03-13 15:45:12 +03:00 by kerem · 4 comments

kerem commented

2026-03-13 15:45:12 +03:00

Owner

Originally created by @Daniel15 on GitHub (Jan 6, 2020).
Original GitHub issue: https://github.com/acme-dns/acme-dns/issues/202

It would be nice to have MySQL support in addition to PostgreSQL and SQLite.

Originally created by @Daniel15 on GitHub (Jan 6, 2020). Original GitHub issue: https://github.com/acme-dns/acme-dns/issues/202 It would be nice to have MySQL support in addition to PostgreSQL and SQLite.

kerem added the

feature request

enhancement

labels

2026-03-13 15:45:12 +03:00

kerem commented

2026-03-13 15:45:23 +03:00

Author

Owner

@webprofusion-chrisc commented on GitHub (Jan 6, 2020):

While we're at it, MongoDB would be useful to (although perhaps more abstraction is required?), Or indeed other more key value store type things. I'm not sure what the most lightweight option would be that would still be robust.

@webprofusion-chrisc commented on GitHub (Jan 6, 2020): While we're at it, MongoDB would be useful to (although perhaps more abstraction is required?), Or indeed other more key value store type things. I'm not sure what the most lightweight option would be that would still be robust.

kerem commented

2026-03-13 15:45:28 +03:00

Author

Owner

@ah-quant commented on GitHub (Mar 13, 2020):

I may be an outlier here - sorry for hijacking the issue - but I'd prefer to have no database dependencies whatsoever. I vastly prefer a slim go.sum and a smaller, self-contained binary with fewer features to this kitchen-sink approach.

An alternative may be to support a local api and plugins - either REST or with plugins communicating over stdout / stdin like protobuf code generators. The plugins could live in a contrib folder with their own mod files there. Everything will be visible in the database, security surface of the core application stays small, main negative is a negligible overhead for local communication.

@ah-quant commented on GitHub (Mar 13, 2020): I may be an outlier here - sorry for hijacking the issue - but I'd prefer to have no database dependencies whatsoever. I vastly prefer a slim `go.sum` and a smaller, self-contained binary with fewer features to this kitchen-sink approach. An alternative may be to support a local api and plugins - either REST or with plugins communicating over stdout / stdin like protobuf code generators. The plugins could live in a contrib folder with their own mod files there. Everything will be visible in the database, security surface of the core application stays small, main negative is a negligible overhead for local communication.

kerem commented

2026-03-13 15:45:33 +03:00

Author

Owner

@webprofusion-chrisc commented on GitHub (Mar 14, 2020):

Well, while we're at it, how about the just file system as the data store?
Directory per account, file per TXT record. I think files could work for up to 10K domains per account, obviously not enough for some users but good for most. No real idea what the performance of lookups would be like.

[Edit] Actually thinking about it, SQLite pretty much serves the same purpose.

@webprofusion-chrisc commented on GitHub (Mar 14, 2020): Well, while we're at it, how about the just file system as the data store? Directory per account, file per TXT record. I think files could work for up to 10K domains per account, obviously not enough for some users but good for most. No real idea what the performance of lookups would be like. [Edit] Actually thinking about it, SQLite pretty much serves the same purpose.

kerem commented

2026-03-13 15:45:38 +03:00

Author

Owner

@grzchr15 commented on GitHub (Mar 8, 2021):

https://github.com/go-sql-driver/mysql would support mariadb and mysql.
https://mariadb.com/ja/resources/blog/using-go-with-mariadb/

@grzchr15 commented on GitHub (Mar 8, 2021): https://github.com/go-sql-driver/mysql would support mariadb and mysql. https://mariadb.com/ja/resources/blog/using-go-with-mariadb/