WeSQL replaces the MySQL disk layer with objects in S3
WeSQL is an innovative MySQL distribution that adopts a compute-storage separation architecture, with storage backed by S3 (and S3-compatible systems). It can run on any cloud, ensuring no vendor lock-in.
At a glance
- What is it?
- WeSQL is a MySQL distribution that separates compute from storage: every piece of MySQL state, from binlogs and schemas to the write ahead log and the data files themselves, is stored as an object in S3 or an S3-compatible system. It is aimed at serverless and bring-your-own-cloud deployments, it is GPLv2 without the or-later clause, and it is a fork of the MySQL tree rather than an extension.
- Who is it for?
- Adopt WeSQL when you are deploying MySQL onto a cloud with object storage available and you want the data layer to be elastic and portable across clouds, and when you can accept a storage engine that puts the S3 API in the path of every write.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 45 days ago.
- What is it written in?
- Mainly C++, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 25, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A MySQL distribution, not a MySQL plugin
WeSQL is described as an innovative MySQL distribution that adopts a compute-storage separation architecture, with storage backed by S3 and S3-compatible systems, and it can run on any cloud, ensuring no vendor lock-in.
The word distribution is the important one. This is not a plugin you load into a stock server, and it is not a proxy that translates a SQL dialect. It is a MySQL that has been modified at the storage layer, and the repository layout shows it: sql for the server, storage for the storage engine work, mysys for the system layer, include for headers, cmake for the build, patches for the modifications to the upstream tree, scripts and packaging for distribution, and mysql-test and test for the test suites. There is also build.sh and an update_aws_sdk_cpp.sh script, which tells you the AWS SDK for C++ is part of the build.
The default branch is 8.0, so the base is the MySQL 8.0 series, and the last push to it was on 2026-09-12. The repository has no tagged releases, and the project is developed by ApeCloud, with parts of the copyright held by ApeCloud Inc Holding Limited.
The audience is stated plainly: users who need an easy-to-manage, cost-effective and developer-friendly MySQL database solution, especially those who need support for both Serverless and BYOC, bring your own cloud. The README invites people to start trying it in development and testing environments, which is the honest framing for a project at this stage.
Everything is an object, not a file on a volume
The claim the README makes is unusually strong, and the emphasis is deliberate. WeSQL has completely replaced MySQL's traditional disk storage with S3. All MySQL data, binlogs, schemas, storage engine metadata, WAL and data files, are entirely, and the README inserts not partially, stored as objects in S3.
Read that list as an inventory of what a normal MySQL installation writes to disk. The binary logs that feed replication and point-in-time recovery are objects. The schemas that describe your tables are objects. The storage engine metadata, which for InnoDB means the redo log files and the tablespace mapping, is objects. The write ahead log is objects. The data files themselves are objects.
That is the whole design, and it explains the two claims that follow from it. The first is durability: the eleven nines of durability provided by S3 significantly enhances data reliability, and this is the argument for the approach, since a single object store with that durability profile is doing work that a replicated block device would otherwise do for you.
The second is portability. Because the state lives in an object store rather than in a volume attached to a particular machine, the compute tier can be started anywhere, and the storage tier is not tied to a cloud provider as long as the target speaks the S3 API. That is the no vendor lock-in claim, and it is the reason the project is interested in S3-compatible systems rather than one specific service.
Cold start: empty instance, S3 bucket, serving traffic
The operation that distinguishes a storage-separated database from a normal one is starting up, and the README describes it directly: WeSQL can start from a clean, empty instance, connect to S3, load the data, and begin serving immediately with no additional setup required.
That is a different operational model. A conventional MySQL instance has state in a volume, so starting a replacement means attaching that volume, or restoring a dump onto a fresh disk, or failing over to a replica and hoping it is caught up. In a compute-storage separated design, the instance is disposable. It is the data that has identity, and the data lives in the bucket. Any instance that can reach the bucket can serve the database.
That property is what makes the Serverless and BYOC use cases credible rather than aspirational. In a serverless model, a function is spun up, pointed at the bucket, and given a connection, and there is no volume to provision, no replica to fail over to, and no warm standby to keep paying for. In a bring-your-own-cloud model, the same instance image runs in a different cloud against the same bucket.
The cost of that model is equally clear from the architecture. Every read and every write now travels through the object storage API rather than a local block device, and the README is direct that the eleven nines of durability come from that layer rather than from the database. A workload that depends on the latency characteristics of local disk is not the workload this was built for.
Building it: a MySQL tree with patches and an AWS SDK
The README does not carry a build recipe. It points at a compile guide on the project site, wesql.io/docs/tutorial/binary/install, alongside the architecture document and the tutorial section, with the introduction page at wesql.io/docs/introduction for everything else.
That is an honest sign of the project's shape. This is a database distribution, and a database distribution is built by compiling a large source tree, and the instructions live in the documentation site rather than in the repository README.
The repository itself shows what the build involves. The patches directory holds the modifications to the upstream MySQL source, the storage directory holds the storage engine work that replaces the traditional disk layer, and mysys is the system layer that MySQL builds use. The cmake directory drives the build, build.sh is the entry point, and update_aws_sdk_cpp.sh points at the AWS SDK for C++ being part of the dependency set, which is the clearest signal of where the new storage layer reaches out to.
The packaging directory is for producing distributable builds, the scripts directory holds operational scripts, and mysql-test is the upstream MySQL test framework, which is what a storage layer change has to keep passing, alongside the test directory for the project's own tests.
For the developer side, the community is a Discord channel linked from the README, and the docs directory in the repository holds documentation sources.
Licence, and the question the architecture raises
The licence is specific and it has an unusual detail. Portions of the work are copyright 2024 ApeCloud Inc Holding Limited, and WeSQL is specifically available only under version 2 of the GNU General Public License, GPLv2, with the README spelling out that this means without the any later version clause, and that it is inherited from MySQL. The README points at the MySQL distribution README for more information.
The distinction matters in practice. GPLv2 without the or-later clause is a one-way grant: you may use, modify and redistribute the code under version 2, and you cannot relicense your derivative under a later GPL or any other licence, and the notice obligations travel with the code. Anyone combining WeSQL with components under different terms, or distributing it inside a product, needs to read that rather than assume the more permissive variant of the GPL.
The architectural question is a different one, and it is the one that decides adoption. The alternative is the conventional deployment: MySQL on a managed block volume, with the durability and replication story handled by the database and the platform.
The difference in approach is where the data lives and what that implies. A volume is fast, familiar, and it is what every MySQL operator, tool, backup procedure and performance practice is built around. Object storage is durable, elastic and portable, and it puts a network API between your database and its pages, which changes the performance profile of the engine in ways that only measurement on your own workload will tell you.
So the decision is not about MySQL compatibility, which WeSQL preserves by construction, since it is a MySQL distribution. It is about whether the operational and cost advantages of storing state in an object store outweigh a storage engine that no longer behaves like the one everybody knows.
Editorial conclusion
Adopt WeSQL when you are deploying MySQL onto a cloud with object storage available and you want the data layer to be elastic and portable across clouds, and when you can accept a storage engine that puts the S3 API in the path of every write. Do not adopt it for a conventional database with a managed volume, where the standard engine is simpler and better understood, and do not adopt it casually, because the licence is GPLv2 without the or-later clause and the project has no tagged releases. Before you commit, read the architecture documentation on wesql.io, confirm your S3-compatible system behaves as the project expects, and test the cold start path, since starting from an empty instance and loading from S3 is the workflow the project is designed around.
Frequently asked questions
What is WeSQL?
WeSQL is a MySQL distribution that adopts a compute-storage separation architecture, with storage backed by S3 and S3-compatible systems, so that it can run on any cloud. The documentation and a live demo are on the project site at wesql.io, and the community runs on Discord.
What does WeSQL keep in S3?
All MySQL data, including binlogs, schemas, storage engine metadata, the write ahead log and the data files themselves, and the README stresses that this is entirely rather than partially in object storage. The durability argument rests on the eleven nines that S3 provides.
How do I build WeSQL?
The README links a compile guide on the project site rather than giving the commands inline. The repository is a MySQL source tree with a patches directory, the storage and mysys layers, a cmake directory, a build.sh script and an update_aws_sdk_cpp.sh script for the AWS SDK for C++.
What licence applies to WeSQL?
Only version 2 of the GNU General Public License, without the any later version clause, inherited from MySQL, with portions copyright 2024 ApeCloud Inc Holding Limited. Because it lacks the or-later clause, a derivative cannot be relicensed under a later version of the GPL.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/wesql-wesql)Was this useful?