AWS Is Buying DuckLabs. The Licence Is Only Half the Portability Story
DuckDB stays MIT-licensed under foundation stewardship. That protects the code, not your exit path. Here is where switching costs actually hide.
Amazon Web Services is bringing DuckLabs, the company behind DuckDB, into AWS. For teams that have quietly made DuckDB part of their analytics stack, the useful response is neither celebration nor panic. It is a dependency review.
DuckLabs announced that the deal should become effective in early September. Its team will stay together in Amsterdam and keep working on DuckDB, DuckLake, Quack, and the surrounding community. The company also says the open-source parts of the Duck Stack will remain free under the MIT licence.
That promise has substance. The nonprofit DuckDB Foundation will continue to hold the intellectual property for the open-source project and steward it. DuckLabs also plans to add a technical advisory board to the foundation and open the extension stack so extensions signed by other developers and organisations can run in DuckDB.
Why this is not a niche acquisition
Those safeguards matter because DuckDB is no longer a developer curiosity. DuckLabs reports more than one million downloads per day. Teams use it to query local files, analyse cloud storage, teach database concepts, power product features, and run real workloads without maintaining a traditional database server. It has become quiet infrastructure, which is exactly the category that never gets reviewed until it breaks.
AWS can give that ecosystem more engineering capacity, distribution, and support. It can also change the incentives around what gets built first and how the surrounding services develop. Both things can be true at once, and neither one is a scandal.
A licence is not a continuity plan
The mistake is treating an open-source licence as a complete continuity plan. A licence protects access to code. It does not guarantee that every hosted service, extension marketplace, identity integration, support contract, or cloud-specific feature stays interchangeable.
Think of the stack as separate layers. The DuckDB core may remain portable under MIT. Your production setup might still depend on a proprietary storage feature, a signed extension, a managed control plane, or operating knowledge that lives inside one vendor’s documentation. The core can be fully open while the complete workflow becomes expensive to move.
This is the pattern we see repeatedly at IndieStudio: the open component is fine, and the glue around it is what locks you in.
Four checks worth running this month
1. Find every place it is used
That includes local analytics scripts, embedded product features, scheduled pipelines, notebooks, and services that hide DuckDB behind another interface. Shadow usage is normal with embedded engines, because nobody has to request a server to start using one.
2. Preserve the recipe
Pin versions, save configuration, record extensions, and keep representative test data with expected outputs. If you cannot rebuild a working environment from your own artifacts, the right to use the code is worth less than it looks.
3. Separate core from convenience
Document which parts rely on AWS storage, identity, monitoring, extension distribution, or managed services. Core engine dependencies and convenience dependencies fail differently and cost differently. Mixing them in one mental bucket is how teams misprice their own switching costs.
4. Test one exit path before you need it
Run a critical workload in another environment, verify the output, and measure what breaks. A small portability drill costs a day. Discovering hidden coupling during a pricing change, a policy change, or a service deprecation costs considerably more.
What to monitor from here
Governance is the signal, not press releases. Watch foundation governance and the composition of the new technical advisory board, release signing practices, how third-party extension distribution actually works in practice, and whether new AWS-specific features start arriving before their portable equivalents. The DuckDB 2.0 governance notes are a reasonable baseline to compare against in six months.
Treat all of this as company statements until corroborated. Transaction timing and future commitments are intentions, not guarantees, and that is true of any acquirer.
The operator takeaway
None of this assumes AWS will close DuckDB or weaken the project. The AWS announcement says the opposite, and the foundation structure offers real continuity. Good governance is not a prediction of failure. It is how a promising partnership avoids becoming an unexamined dependency.
Open source gives operators options. Those options stay real only when your team keeps its builds, data interfaces, tests, and operational knowledge portable. The licence gives you an exit door. Portability work is what keeps it unlocked.