go-mysql-server
go-mysql-server is a MySQL-compatible SQL engine written in Go that lets you query arbitrary data sources using standard SQL. It includes an in-memory database suitable for testing and provides interfaces to implement custom storage backends.
Key facts
Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.
| Field | Value |
|---|---|
| Repository | dolthub/go-mysql-server |
| Owner | dolthub |
| Primary language | Go |
| License | Apache-2.0 — OSI-approved |
| Stars | 2.6k |
| Forks | 265 |
| Open issues | 60 |
| Latest release | v0.20.0 (2025-05-13) |
| Last updated | 2026-07-07 |
| Source | https://github.com/dolthub/go-mysql-server |
What go-mysql-server is
A storage-agnostic SQL query engine implementing MySQL dialect and wire protocol in Go. Features pluggable backend interfaces, built-in memory database for testing, and is used as the foundation for Dolt (a versioned SQL database). Requires C/C++ toolchain and ICU4C for full regex compatibility; pure-Go fallback available with caveats.
Get the go-mysql-server source
Clone the repository and explore it locally.
git clone https://github.com/dolthub/go-mysql-server.gitcd go-mysql-server# follow the project's README for install & configurationNeed it deployed, integrated, or customized instead? DEV.co ships production installs.
Best use cases
Implementation considerations
- C/C++ toolchain and libicu-dev required for ICU regex support; compile with `-tags=gms_pure_go` for pure-Go fallback (note: not all tests pass, MySQL compatibility reduced).
- Custom backend requires implementing core interfaces (Database, Table, Index, etc.) per provided examples. Review Dolt codebase for production-grade reference.
- In-memory backend suitable only for tests or single-threaded embedded use; confine DDL/DML to one goroutine to avoid data race.
- Wire protocol compatibility with MySQL clients is strong; test client library against specific MySQL feature set needed (functions, types, edge cases).
- No native clustering, replication, or high-availability features; rely on custom backend or Dolt for distributed deployments.
When to avoid it — and what to weigh
- Need production-grade multi-threaded reliability — In-memory database is documented as non-thread-safe; DDL/DML must be confined to single goroutine. Risk of data corruption under concurrent load.
- Require ACID transactions — No transaction support. START TRANSACTION, COMMIT, and ROLLBACK are no-ops. In-memory backend unsuitable for workloads needing atomicity guarantees.
- Expecting high-performance indexes — Index implementation performs full table scans rather than optimized lookups. Not suitable for large datasets or join-heavy queries without custom backend.
- Building production database from scratch — Engine is feature-complete but backend implementations require significant engineering. Use Dolt or managed MySQL for production unless custom backend aligns with architecture.
License & commercial use
Apache License 2.0 (Apache-2.0). Permissive OSI-approved license permitting commercial use, modification, and distribution with liability/warranty disclaimers and license/change notice requirements.
Apache-2.0 explicitly permits commercial use. However, any production deployment should review: (1) liability disclaimers in LICENSE file, (2) compliance with derivative work attribution, (3) obligations if distributing modified versions. For risk-critical systems, legal review recommended. Dolt is the reference production implementation; consider whether to use go-mysql-server directly or via Dolt.
DEV.co evaluation signals
Editorial assessment — not user reviews. Directional, with an explicit confidence level.
| Signal | Assessment |
|---|---|
| Maintenance | Active |
| Documentation | Adequate |
| License clarity | Clear |
| Deployment complexity | Moderate |
| DEV.co fit | Strong |
| Assessment confidence | High |
Inherited security posture depends on backend implementation. In-memory backend has no persistent data protection. Wire protocol follows MySQL conventions; standard SQL injection, auth, and credential management practices apply. No built-in encryption at rest or in transit; implement TLS at network layer if needed. Non-thread-safe in-memory implementation creates data race risk if misused. Audit custom backend implementations for auth/access control.
Alternatives to consider
TestContainers / Docker MySQL
Full MySQL container for tests avoids custom integration but requires Docker/container runtime and slower startup. Better MySQL fidelity; worse developer experience than in-memory.
Dolt
Built on go-mysql-server; adds versioning, branching, and merging. Use if Git-like data versioning is a requirement; otherwise go-mysql-server alone is lighter.
SQLite (with go-sqlite3)
Simpler embedded SQL engine with fewer dependencies; no need for C/C++ toolchain or ICU. Lacks MySQL compatibility and pluggable backend design; use if MySQL dialect not required.
Build on go-mysql-server with DEV.co software developers
Evaluate go-mysql-server for test environments or custom backends. Need production versioning? Explore Dolt. Let's architect the right database layer for your needs.
Talk to DEV.coRelated on DEV.co
Explore the category and the services that help you build with it.
go-mysql-server FAQ
Can I use go-mysql-server in production?
Do I need ICU4C installed?
Can I query multiple backends simultaneously?
Is it thread-safe?
Custom software development services
DEV.co is a software development agency delivering custom software development services to companies building on open source. Our software developers and web developers design, integrate, and ship production systems — spanning web development, APIs, AI, data, and cloud. If go-mysql-server is part of your open-source databases roadmap, our team can implement, customize, migrate, and maintain it.
Ready to add SQL to your Go application?
Evaluate go-mysql-server for test environments or custom backends. Need production versioning? Explore Dolt. Let's architect the right database layer for your needs.