I'm glad that DuckDB has a foundation in place and hope it is resilient enough to push the DB forward when the time comes.
Out of all the big orgs, Amazon is probably the one that has the least regard for keeping technically interesting projects alive, and the certainly will bulldoze it for some dumb reason when the next re-org comes.
I think 'least regard' belongs to Oracle. For some reason I thought DuckDB was one of Gabe's ideas over at DuckDuckGo :-).
That said, the acquisition by Amazon is interesting in that it seems to overlap with their existing DB offerings? Which makes me wonder what exactly it is that they are getting out of this.
AFAIK Google is much better at not tearing well-working teams apart in reorgs, and letting people go they have acquihired a few quarters earlier.
Of the few examples I have I my head, I'd even say that the fate of a product that has been acquired by Google is probably even better than those of Google's internally developed products. e.g. Waze is still alive and kicking 13 years after acquisition under its own brand and hasn't been completely swallowed by Google Maps. The Nest brand also stuck around for quite some time.
Google has such a much better reputation when it comes to contributing to and understanding open source. It’s unfair to Google to put Amazon above them.
Heck AWS is the sole reason all these projects needed to go through these license changes to prevent AWS from completely destroying their business models.
> Out of all the big orgs, Amazon is probably the one that has the least regard for keeping technically interesting projects alive
I'm curious what you mean by this. I would have said the exact opposite - AWS tends to keep projects around for a very long time. They haven't acquired very many open-source projects, but the few that they have are all still running as far as I know.
Fig, was one of them but was only partially opens source IIRC. CLI autocomplete and script team sync. Turned into/integrated into Amazon Q, which turned into Kiro CLI, which AFAIK doesn't share any functionality with the original product nowadays.
What good is a foundation when it's core member is owned by a public corporation? Like we know what happens, the pattern isn't unique or rare. Corporate interests will always take priority over community interests, corporations care about profit not community. If Amazon cares about the community as they care about their own workforce, that does not bode well.
Either way that news is awful. Europeans selling out to US corporations and then wondering why Europe is not competitive in software engineering anymore. Funniest thing is Draghi keeps on saying that; well, recently we also heard that the USA has full access to all national police databases in the EU now. It seems as if Washington remote-proxy-controls the EU. Quite amazing to see, too. The amount of bribe money flowing must be legendary.
The title is misleading. AWS acquired DuckLabs, NOT DuckDB. The DuckDB source code is still owned by the nonprofit DuckDB Foundation.
Quote from the article:
"As the CWI representative on the DuckDB Foundation... When DuckLabs spun out of CWI, we created this foundation, which holds all IP of open-source DuckDB, and will continue to do so." - Peter Boncz
AWS did not acquire the DuckDB technology itself, which is MIT-licensed open source and governed by the DuckDB Foundation which holds most of the related IP [1].
What they did acquire is DuckLabs, the Amsterdam-based services and development company behind the technology which is owned by and employs the creators and major contributors.
And MotherDuck is a US-based venture-funded commercial company, whose cloud-based data platform is centered around DuckDB but has been significantly expanded recently, including Python pipelines, an agentic context layer, and a visualisation layer.
Interesting to see how they will update their About page.
Currently it says “Today, DuckLabs remains independent and fully owned by the original creators. We've deliberately chosen not to take venture capital, so we can focus on sustainable engineering, correctness, and keeping DuckDB open and MIT-licensed for everyone. “
This is an important distinction, I hope the title can be changed.
I was really surprised when I first came across DuckDB at how good at it is for its target use cases. It is a game changer for me for the "local analytics" space, and its ability to scale up to a large degree helps a lot.
It is simply awesome to be able to point DuckDB at a mess of CSV and other files and have an instant database on top of it that I can run regular SQL over, and it is fast and just works.
It’s faster than trino and spark for 99% of your use cases. Only once the datasets reach the 100GiB to TiB range is trino/spark faster. Compute is scaling vertically faster than Data Eng/Analytics dataset growth, over time DuckDB will be the better choice.
you raised a good point but (et al) didn't touch on the meaningful questions: where does the "core team" of developers of DuckDB now reside? are they now "captured/cashing-in/getting paid" at AWS, or will meaningful MIT-licensed development of DuckDB continue in a robust way outside of commercial enterprises with proprietary needs that are not aligned with where the project was going?
Congrats to the founders but honestly feel bad for the team. Hearing so many not good things coming from inside AWS these days. Place sounds like a total mess. Seems like a constant stream of top talent fleeing on my LinkedIn this past year.
I hope they just let the team carry on and don’t contaminate it with all the other craziness going on.
They built something amazing and now have a nice exit. The code remains open under a non profit foundation. I don't think it is that bad. If working conditions are too bad people will just quit and work for the foundation.
An exit can be a nice payout, but only retirement level payouts for a very few. Most will need to find a new job and the market is pretty shit right now and I doubt the foundation has the funds to hire the entire team back.
What does AWS get out of this? Couldn't they build their own offering on top of DuckDB, just like MotherDuck has been doing?
Buying the team and having them all quit is such a bad outcome for AWS, especially they would not keep any of the IP, which is owned by the DuckDB Foundation. I don't think they would be that short-sighted.
You make it sound like every worker agreed with this. Is this actually true or is it more about the founders exploiting their workers by selling out to one of the most devious anti-worker tech corporations?
Is profit sharing, like what you're implying, actually happening? If so, in what quantity?
Does LinkedIn activity paint an accurate picture of wherever you work?
I can’t say that’s true for me and my company. It’s not all lies or anything, it’s a fragmented view that emphasizes conflict and the most visible 10% of what the company actually does.
Honestly, there's just a huge amount of thrash across the cloud & SaaS industries as a whole. It's not a lot better at Google (way behind OAI & Anthropic on coding & local AI harnesses), Microsoft (no meaningful frontier model R&D to speak of, and a constantly eroding Windows business), the neoclouds (impossible to source adequate infrastructure and are existentially threatened by the hyperscalers (especially Google) if they can't keep up with demand, chipmakers (NVIDIA vs AMD vs Qualcomm vs Apple vs the long tail of specialty shops like Cerebras), data center pure plays (legislative & community pushback, natural resources, infrastructure availability), and the SaaS folks ("let's see if AI can do it").
It's both a great time to be gold mining in tech, and also a terrible time to be a bit employee.
I started using DuckDB last year and I loved it. Small, focused, crackling with competence, no bullshit. I think what I liked about it had a lot to do with it being made by a small group of technical people who weren't interested in "maximizing share holder value" (that is, maximizing executive promotions and bonuses).
Maybe this will be the rare case where founders survive corporate shenanigans and keep on doing their thing. But I'm bummed, as I've heard that optimism many more times than I've seen it happen.
Seems like a good time to recommend Apache Datafusion. It's designed to be a library, but works pretty well standalone as well. There's a CLI version, but also Python and Java bindings, as well as a Rust library, of course.
From my own experience I can say it integrates far better into your Rust app than DuckDB does.
No, it's a competing ecosystem, even though both are built on Apache Arrow, and their dataframe APIs might look similar on the surface.
DataFusion is being used as a building block for a growing number of databases and data processing engines in Rust, as it offers the necessary primitives.
Very much doubt it’s generational wealth. I’m not sure how much people think open source companies are worth, but the path to VC-scale profitability is incredibly rare.
My guess is that Amazon wants official hosted versions and doesn’t want to go through something like the Redis fiasco with licensing. In that case, they ended up having to support their own development anyway (with Valkey), so they might as well just buy the team.
DuckDB team probably gets a nice package and pay bump, but it’s really unlikely they’re getting hundreds of millions from this.
How much do you really need for generational wealth? In my opinion, if you're more than 10 years away from retirement and received a surprise $1 million, you're setup for the rest of your life and your children as well assuming they don't immediately blow it all when you die (that's what a good trust should be for).
Assuming historical returns, your money doubles roughly every 7 years, so within the rest of your lifetime, that 1 million should turn into at least 8. That's an extremely comfortable upper-middle-class lifestyle on the interest payments alone. If your children don't spend it all, your grandchildren would easily have private jet money by the time their parents retire.
> I’m not sure how much people think open source companies are worth, but the path to VC-scale profitability is incredibly rare.
MotherDuck, a semi-competitor of theirs has raised $100mil in funding. DuckLabs has reportedly taken no external funding (so all ownership is with the founders) and was profitable with 30+ employees.
On the sidelines, other companies behind beloved open source products, like Astral, Astro, Bun are getting bought left and right.
With that as a backdrop, I think they should have been able to get quite a good payout.
My attempt at an answer: no, databases are not solved.
Specifically, different databases are better or worse for different use-cases.
For example, Postgres is a great "all around database" - you can use it for a lot of different things. As a "relational" database, it's really good if you have a table full of users, a table full of order, and you want to see all orders made by a user with ID=123. You need to answer questions like that a lot (eg every time someone on a website loads a page) and you need the answer fast (hundreds of miliseconds at most)
However, say your use-case is more like... you've got 100 billion rows of billing data ("joe was charged $123.45 on 2026-03-07 for a shirt, blue, size 11, brand foobar") in one table. You don't care much about joe, but you want to be able to find out how much was billed, total, in 2026-03 for blue shirts (or all year for brand foobar, or all time, for size 11). Postgres would struggle with data of that volume - you'd need a really big expensive database. A "columnar" database like duckdb (or clickhouse) might be able to answer those questions better.
Anyway, different databases are better/worse for:
- Large piles of data that you need to query in seconds
- Huge (petabytes) of data that you need to query in minutes, but can query in parallel
- Many related piles (like a standard relational database)
- Cases where you're mostly getting or retrieving single items (key-value stores)
- Huge piles of data that represent a long stream of events in time (time-series datbases)
- Piles of data that look and act more like files (object stores)
- When you need strict transactions
- When your need is very write-heavy
- When your need is very read-heavy
- and probably many others - I'm not even a huge data guy :)
So it all depends on your use-case. There are still cases that are not served well by any existing database - eg "filtering billions of rows, in milliseconds, by an arbitrary portion of several dozen very-high-cardinality columns" (to use an example that came up recently for me IRL) :)
Just to add to this good explanation, a sufficiently large enough company (and even small successful companies) will eventually have a need for different DBs.
It's all about tradeoffs. Same reason there are so many kinds of wheeled transport and so many kinds of bridges.
There's no single set of requirements and desired properties that people have for databases.
What queries does it accept? How does it persist data? How does it manage replication and partitioning across multiple servers? Are questions with many answers and the right one varies by application.
> What queries does it accept? How does it persist data? How does it manage replication and partitioning across multiple servers? Are questions with many answers and the right one varies by application.
nothing prevents to build single database which would cover all such answers. Its engineering, funding and distribution problems: no-one built it yet.
Every tool is a trade off between effort to create vs power of the solution.
Effort is generally expensive so most things settle on some general purpose local maximum. If you had infinite effort available, you could build bespoke hardware and software from the ground up to solve every problem. It would be faster and more power efficient than any solution available today.
CPUs win out over integrated circuits because the same CPU can be used for ~every software problem, so by using a CPU you benefit from everyone pooling their efforts to improve the general purpose CPU rather than their own specific niche. But when you reach a certain scale/requirements it makes sense to do something more specific. This is one reason why we have standardized GPUs. Still general purpose but more specialized than a CPU. Or think about how Bitcoin mining moved to ASICs, because they need to do one specific thing as fast and as power efficiently as possible.
So for databases, when you get to specific scale and requirements the same kind of specialization starts to make sense. DuckDB or Clickhouse for analytical loads, TigerBeetle for high scale transactional stuff, etc. And that scale is aggregated across ~all software users, i.e. scale of analytical workloads being big enough to support analytical DBs.
Also as time goes on and industries develop the cost to develop specific solutions can go down.
DuckDB is really great. It's definitely the best tool for working with any type of tabular laptop-sized analytical data. You can do some of what DuckDB does with SQLite, but DuckDB is much more versatile and performant.
This is an enormously wide question but the quickest way to give you an idea would be rephrasing as:
"Are cars not a solved problem? Why are there lots of different cars? Why is one faster than the other? What's different between them?"
I think the best way to approach the subject in an easy to grasp way is to ask Gemini or another frontier AI to teach you the basics, they will do a surprisingly good job and they'll be able to react to your questions with INFINITE patience.
There’s trade offs for performance, access patterns, throughput, latency, concurrency, workloads, rigor, type systems, extensibility… really every characteristic you could imagine.
It’s not a solved problem because each iteration of technology doesn’t just fix the mistakes of the past, it’s an evolution to solve the problems of the present.
What do you mean by solved problem? I don't own DuckDB (sqlite, postgresql, etc). If I think I can create something as good or better than DuckDB, should I give up doing so (and get filthy rich with an acquisition) because someone thinks databases are solved? Solved databases aren't mine.
This is a real shame. I love DuckDB, and we've adopted/extended it and ducklake very heavily at Krea for our research.
I know the projects will remain open, and ostensibly still contributed to in the same direction, but surely AWS thinks of this as another piece of a product suite to compete with Databricks.
Nontheless, I think the open embedded query engine approach DuckDB is spearheading is larger than one project, and I remain excited about the broader ecosystem (especially datafusion).
I was a real fan from the very beginning, but now DuckDB 2.0 "as a server" and 5. asynchronous I/O [1] looks aimed at something very different from what I thought first.
agree - I was really uneasy with the lede in their v2.0 preview:
"DuckDB has been an in-process database since day one. But people have asked us – very persistently – for a client/server mode, and we have finally caved"
This was already satisfied by numerous projects and products, and feels like a "me too" attempt to capture AI-based workflows. DuckDB always felt like "SQLite for Analytic Data" but I fear these changes and now acquiring the org leading technical direction is where they deviate for good. AWS is so unnecessary for what DuckDB can (and should, IMO) be; MongoDB jumps to mind as a cautionary tale.
I didn't even necessarily mean diverting from the mission, just that optimising for network storage now reads like a feature maybe prioritised in anticipation of a stronger cloud user base
Surprised that there isn't more discussion of DuckDB source distributions.
Why do we need a source distribution for a well regarded MIT licensed project? Because it's not easy to contribute code to DuckDB if you don't work at DuckLabs. The CI used to take 5 hours for a simple bug fix last I looked (may have improved since I flagged it on social media).
Pygmy-Goose is focused on making agentic workflows faster by splitting the repo, making git worktrees cheap and 5 minute cached CI on 3 major platforms.
Several "Graph on DuckDB" efforts started on DuckDB and ended up reinventing a basic columnar codebase to innovate on because of these reasons. Even though people didn't document why, lack of outside contributor friendly flows is likely one of the reasons.
But circa 2023 decided to write their own. Work continues as LadybugDB. One of my long term goals is to find an integration point with DuckDB's table implementation as the "node table". Conversely at some point DuckDB could implement all the join algorithms and LadybugDB's REL table in their code base.
For now, any talk of Graph on DuckDB is limited to DuckPGQ and the more recent entrant DuckGQL (both of which don't touch the storage layer which is the main reason why LadybugDB exists).
That seems unlikely because AWS needs to build proprietary features within their services to lock in paying (enterprise) users. The problem now is that labs will inevitably focus on this work, which I view as opposed to local, in-process when your paycheque comes from selling hosted services.
Hey, MotherDucker here!
We've been working closely with the DuckLabs team since day one, and the collaboration will continue!
You can read more here: https://motherduck.com/blog/duckdb-amazon/
TL;DR AWS will either acquire MD next/soon, or (more likely) keep them around for the optics that they are totally not going to starve the community of anything other than DuckDB as a hosted AWS service.
From the MD "about page":
The idea for MotherDuck came after Jordan Tigani, MotherDuck co-founder and chief duck-herder, saw DuckDB in action and thought, “Wow, this is amazing! someone should really build a serverless version.”
...
Hannes and Mark, who founded DuckLabs to focus on the core technology and build the world’s best analytics database, were looking for partners who would build a commercial cloud offering.
1 month later: "Re-writing DuckDB in Rust with Claude Ultra". There is a curios phenomenon, big tech uses great open source projects as a guinea pig for experimenting agent-based development approaches, see Bun, AstroJS.
Wow congratulations for the original authors, but I hope it doesn't impact the users. I can imagine that it is very useful for AWS because they don't exactly have something similar.
I use DuckDB extensively for local dev as well as a parquet viewer.
Any indication yet as to whether Quack, DuckLake, real-time materialized views dev will continue full-steam ahead? B/c myself and i know of many others very interested in seeing these efforts completed... :crossed-fingers:
AWS rarely acquired startups, though leveraging someone else's tech is a typical pattern. It did license ParAccel and sold it as Redshift. It also runs Athena, which is based on Trino (a Presto fork).
Now, with Snowflake and Databricks earning big bucks in the intelligence era, time to gain market share by having DuckLabs under its ownership?
I wasn't expecting this, and I am pleasantly surprised. I think AWS has been a bad player in the data space and very much behind all the other warehouse providers for many years now. This could lead into interesting integrations of DuckDB on top of all the data that lives in S3 and provide a leaner, faster and a more modern alternative to Athena.
Feel like AWS got a lot of the concepts right with S3 Tables* ("serverless" Iceberg catalog on top of S3) ... would love, love to see a version of S3 Tables that lets you choose between Ducklake or Iceberg as the catalog.
* Cloudflare also seems to have gotten the same idea right with R2 Data Catalog
I made a prediction that motherduck will be acquired by GCP. But I could not imagine duckdb labs will be acquired by AWS. I do not think of AWS as a serious contender in the data space. So, we have now Pola.rs and motherduck in the market. Who will acquire them? I believe Microsoft has brought in a fair few industry talent to build their Azure Fabric product. Then you also have AI companies that are buying devtool/utility companies left and right.
AWS is a great home for DuckLabs. They just want people to use more compute and storage, so they have a degree of technology-neutrality. This is the key to allowing DuckDB to continue to grow in whatever directions are natural, rather than being warped by some kind of walled garden data platform strategy.
Fair point, but no one is clearly articulating what AWS gets out of this. They don't get the DuckDB IP, that's owned by the foundation. All the work that the team at DuckLabs is putting in growing DuckDB and DuckLake are already in principle converting into compute/storage demand in AWS. So what does AWS actually want and how will it change DuckDB to accomplish it?
> "The DuckDB project is governed by the non-profit DuckDB Foundation . The Foundation and DuckLabs are not funded by external investors (e.g., venture capital)."
But "(Last updated: Aug 2026)" and I was not able to find this text anymore.
I wonder if they took vc money after all. I guess not, but still, it seem like to be difficult to live as an independent open source company. Getting a big co as a parent/sponsor is probably the next best thing.
Probably removed because DuckLabs is owned by Amazon now so it’s kind of confusing. Maybe Amazon said, “just take it down, our lawyers will approve some language.”
I've been eyeballing DuckDB and LanceDB as part of AI agent memories.
This gives me a vibe that AWS will use DuckDB somehow in their ai agents sometime in the near future after seeing the potential.
Yes. AWS has OpenSearch for cloud-first vector searches (disregarding cloud-hosted postgres with extensions etc). It's ridiculously expensive and not as fast.
DuckDB to the rescue.
Also embed the crap outta DuckDB locally in local agents running on VPS, etc
Devs gotta eat. Yeah the code is out there but the code is a result of a lot of thinking, prioritization, research into what is needed from the actual product. So now AWS owns that mindshare and talent and will (probably heavily) influence its decisions. I just hope DuckDB doesn't stray from its goal of being the SQLite (e.g. embedded) OLAP.
Back in 2018, I took Hannes’ database course as part of my CS degree, which was one of the better ones I took. Over the years, I’ve seen DuckDB celebrated here (and other places), and now this. Congrats to both him and the Ducklabs team.
I am a big fan of the Duck team since before their v1.0 and I am happy for them personally for the big payoff, both in monetary terms but also in terms of scale and longer-term viability of their baby. I am also happy to see the arrangement will keep the core OSS. Let's see what the future holds now!
"We also worried that scaling DuckLabs into a much larger sales, support, and operations organization would pull our attention away from the technical work and open-source community that made DuckDB successful in the first place."
Given AWS's services arm seems like a good play for a team. Congrats!
I am happy for the team's success but I am sad and anxious for what may become of the DuckDB. It is my favorite tool. Like other comments mentioned, DuckDB is open source and MIT license so I hope it will survive and evolve further the way it did.
What if AWS eventually steer away duckdb team's bandwidth towards their AWS products or influence their work, since they are technically AWS employees.
We have seen that how many times now? Terraform, docker, elasticsearch, influxdb.
Nono, we are still the good guys, believe us. Nothing will change. Yea, thats gonna get forked and rewritten in rust.
This doesn't even make sense. Postgres is and has been open source since the 90s and AWS has had an existing Postgres offering since approximately always.
And there is no single company developing. Its a healthy mix of engineers from many companies. A perfect model to prevent this issue here of being aquihired.
I guess this will be a good test of the open source model DuckDB has opted into.
As I understand it, DuckDB is MIT-licensed and governance is provided by a separate, non-profit DuckDB foundation. This was done explicitly to prevent BSL-ification.
I'm very curious to see whether that approach holds the line. I wouldn't bet on it, but one can hope?
I'm glad I stuck with SQLite. Governance is an important part of any open source project. SQLite has kept things narrow and focused, while DuckDB's philosophy is to do more and more, making it a general-purpose data science tool. I am old-fashioned in that I believe in the philosophy that software should "do one thing and do it well"
I'm glad that DuckDB has a foundation in place and hope it is resilient enough to push the DB forward when the time comes.
Out of all the big orgs, Amazon is probably the one that has the least regard for keeping technically interesting projects alive, and the certainly will bulldoze it for some dumb reason when the next re-org comes.
I think 'least regard' belongs to Oracle. For some reason I thought DuckDB was one of Gabe's ideas over at DuckDuckGo :-).
That said, the acquisition by Amazon is interesting in that it seems to overlap with their existing DB offerings? Which makes me wonder what exactly it is that they are getting out of this.
Potential competitor removed from play
1 reply →
I thought MySQL wasn't led badly? Compared to its forks
they did fairly well with Java
4 replies →
Surely they are better than Google in this regard.
AFAIK Google is much better at not tearing well-working teams apart in reorgs, and letting people go they have acquihired a few quarters earlier.
Of the few examples I have I my head, I'd even say that the fate of a product that has been acquired by Google is probably even better than those of Google's internally developed products. e.g. Waze is still alive and kicking 13 years after acquisition under its own brand and hasn't been completely swallowed by Google Maps. The Nest brand also stuck around for quite some time.
15 replies →
Google has such a much better reputation when it comes to contributing to and understanding open source. It’s unfair to Google to put Amazon above them.
Heck AWS is the sole reason all these projects needed to go through these license changes to prevent AWS from completely destroying their business models.
17 replies →
I feel like google do the most innovative projects of all the big companies.
Golang is alive and kicking still :shrug:
1 reply →
golang is great?
Yup, they are very serious about DynamoDB and it is a very good product. Wish they released more information about it, though.
Man I admire AWS marketing team for convincing people DynamoDB is a very good product.
100 items max per Transaction BatchGet 100 items, 16 MB max low write limits on same key Item size 400 KB max etc.
9 replies →
They have published 2 academic papers about it. What more do you want, operational details?
1 reply →
https://www.amazon.science/publications/dynamo-amazons-highl...
5 replies →
[dead]
> Out of all the big orgs, Amazon is probably the one that has the least regard for keeping technically interesting projects alive
I'm curious what you mean by this. I would have said the exact opposite - AWS tends to keep projects around for a very long time. They haven't acquired very many open-source projects, but the few that they have are all still running as far as I know.
Fig, was one of them but was only partially opens source IIRC. CLI autocomplete and script team sync. Turned into/integrated into Amazon Q, which turned into Kiro CLI, which AFAIK doesn't share any functionality with the original product nowadays.
I'm still salty about them demolishing Cloud9
What good is a foundation when it's core member is owned by a public corporation? Like we know what happens, the pattern isn't unique or rare. Corporate interests will always take priority over community interests, corporations care about profit not community. If Amazon cares about the community as they care about their own workforce, that does not bode well.
who currently has the most regard for keeping technically interesting projects alive?
<crickets>
> Amazon is probably the one that has the least regard for keeping technically interesting projects alive
Well ...
https://killedbygoogle.com/
Either way that news is awful. Europeans selling out to US corporations and then wondering why Europe is not competitive in software engineering anymore. Funniest thing is Draghi keeps on saying that; well, recently we also heard that the USA has full access to all national police databases in the EU now. It seems as if Washington remote-proxy-controls the EU. Quite amazing to see, too. The amount of bribe money flowing must be legendary.
The title is misleading. AWS acquired DuckLabs, NOT DuckDB. The DuckDB source code is still owned by the nonprofit DuckDB Foundation.
Quote from the article:
"As the CWI representative on the DuckDB Foundation... When DuckLabs spun out of CWI, we created this foundation, which holds all IP of open-source DuckDB, and will continue to do so." - Peter Boncz
You are right.
AWS did not acquire the DuckDB technology itself, which is MIT-licensed open source and governed by the DuckDB Foundation which holds most of the related IP [1].
What they did acquire is DuckLabs, the Amsterdam-based services and development company behind the technology which is owned by and employs the creators and major contributors.
And MotherDuck is a US-based venture-funded commercial company, whose cloud-based data platform is centered around DuckDB but has been significantly expanded recently, including Python pipelines, an agentic context layer, and a visualisation layer.
[1]: https://duckdb.foundation/
[2] https://ducklabs.com/
[3] https://motherduck.com/
Interesting to see how they will update their About page.
Currently it says “Today, DuckLabs remains independent and fully owned by the original creators. We've deliberately chosen not to take venture capital, so we can focus on sustainable engineering, correctness, and keeping DuckDB open and MIT-licensed for everyone. “
Future will tell if that ends up being true.
11 replies →
smells like redhat
This is an important distinction, I hope the title can be changed.
I was really surprised when I first came across DuckDB at how good at it is for its target use cases. It is a game changer for me for the "local analytics" space, and its ability to scale up to a large degree helps a lot.
It is simply awesome to be able to point DuckDB at a mess of CSV and other files and have an instant database on top of it that I can run regular SQL over, and it is fast and just works.
It’s faster than trino and spark for 99% of your use cases. Only once the datasets reach the 100GiB to TiB range is trino/spark faster. Compute is scaling vertically faster than Data Eng/Analytics dataset growth, over time DuckDB will be the better choice.
1 reply →
Not sure why the submitter changed the title from the page: "DuckLabs to Join AWS, Projects to Remain Open Source"
For clicks
Fixed above. Thanks!
What about motherduck?
you raised a good point but (et al) didn't touch on the meaningful questions: where does the "core team" of developers of DuckDB now reside? are they now "captured/cashing-in/getting paid" at AWS, or will meaningful MIT-licensed development of DuckDB continue in a robust way outside of commercial enterprises with proprietary needs that are not aligned with where the project was going?
It is not misleading at all. For all these softwares, the team that behind is the most important part rather than the software itself.
Congrats to the founders but honestly feel bad for the team. Hearing so many not good things coming from inside AWS these days. Place sounds like a total mess. Seems like a constant stream of top talent fleeing on my LinkedIn this past year.
I hope they just let the team carry on and don’t contaminate it with all the other craziness going on.
They built something amazing and now have a nice exit. The code remains open under a non profit foundation. I don't think it is that bad. If working conditions are too bad people will just quit and work for the foundation.
An exit can be a nice payout, but only retirement level payouts for a very few. Most will need to find a new job and the market is pretty shit right now and I doubt the foundation has the funds to hire the entire team back.
What does AWS get out of this? Couldn't they build their own offering on top of DuckDB, just like MotherDuck has been doing?
Buying the team and having them all quit is such a bad outcome for AWS, especially they would not keep any of the IP, which is owned by the DuckDB Foundation. I don't think they would be that short-sighted.
You make it sound like every worker agreed with this. Is this actually true or is it more about the founders exploiting their workers by selling out to one of the most devious anti-worker tech corporations?
Is profit sharing, like what you're implying, actually happening? If so, in what quantity?
There is no guarantee of a nice exit.
Does LinkedIn activity paint an accurate picture of wherever you work?
I can’t say that’s true for me and my company. It’s not all lies or anything, it’s a fragmented view that emphasizes conflict and the most visible 10% of what the company actually does.
Honestly, there's just a huge amount of thrash across the cloud & SaaS industries as a whole. It's not a lot better at Google (way behind OAI & Anthropic on coding & local AI harnesses), Microsoft (no meaningful frontier model R&D to speak of, and a constantly eroding Windows business), the neoclouds (impossible to source adequate infrastructure and are existentially threatened by the hyperscalers (especially Google) if they can't keep up with demand, chipmakers (NVIDIA vs AMD vs Qualcomm vs Apple vs the long tail of specialty shops like Cerebras), data center pure plays (legislative & community pushback, natural resources, infrastructure availability), and the SaaS folks ("let's see if AI can do it").
It's both a great time to be gold mining in tech, and also a terrible time to be a bit employee.
> Place sounds like a total mess.
What big corp is not a total mess?
AWS in large pockets was not a mess 10 years ago.
The things I hear from recent AWS departures are very concerning.
1 reply →
I started using DuckDB last year and I loved it. Small, focused, crackling with competence, no bullshit. I think what I liked about it had a lot to do with it being made by a small group of technical people who weren't interested in "maximizing share holder value" (that is, maximizing executive promotions and bonuses).
Maybe this will be the rare case where founders survive corporate shenanigans and keep on doing their thing. But I'm bummed, as I've heard that optimism many more times than I've seen it happen.
Seems like a good time to recommend Apache Datafusion. It's designed to be a library, but works pretty well standalone as well. There's a CLI version, but also Python and Java bindings, as well as a Rust library, of course.
From my own experience I can say it integrates far better into your Rust app than DuckDB does.
Well over 100 monthly contributors, too.
Datafusion has all of the individual pieces, especially if you just want to data analysis, but is far from an embedded database.
Indexes, transactions, a first-class storage format are all things that come included with DuckDB, that you won't have with Datafusion.
indexes are very weak in duckdb, need to fit memory.
2 replies →
It's juts not as user friendly as DuckDB.
You can even use DuckLake with Datafusion: https://github.com/tobilg/datafusion-ducklake-provider
https://github.com/datafusion-contrib/datafusion-ducklake is more established, and linked to directly from the ducklake docs
Is Datafusion related to Polars at all? I ask because you mentioned Rust integration.
No, it's a competing ecosystem, even though both are built on Apache Arrow, and their dataframe APIs might look similar on the surface.
DataFusion is being used as a building block for a growing number of databases and data processing engines in Rust, as it offers the necessary primitives.
1 reply →
Came here to post the same thing. DataFusion is fantastic.
Congrats to the founders on their new generational wealth, but also what a shame.
If there's no price tag mentioned, it's likely not generational wealth.
There is no way the price tag is less than tens of millions right?
At Google's size, they're not required to disclose acquisition prices well into the hundreds of millions
1 reply →
Also European so almost certainly underpriced themselves.
Very much doubt it’s generational wealth. I’m not sure how much people think open source companies are worth, but the path to VC-scale profitability is incredibly rare.
My guess is that Amazon wants official hosted versions and doesn’t want to go through something like the Redis fiasco with licensing. In that case, they ended up having to support their own development anyway (with Valkey), so they might as well just buy the team.
DuckDB team probably gets a nice package and pay bump, but it’s really unlikely they’re getting hundreds of millions from this.
How much do you really need for generational wealth? In my opinion, if you're more than 10 years away from retirement and received a surprise $1 million, you're setup for the rest of your life and your children as well assuming they don't immediately blow it all when you die (that's what a good trust should be for).
Assuming historical returns, your money doubles roughly every 7 years, so within the rest of your lifetime, that 1 million should turn into at least 8. That's an extremely comfortable upper-middle-class lifestyle on the interest payments alone. If your children don't spend it all, your grandchildren would easily have private jet money by the time their parents retire.
29 replies →
> I’m not sure how much people think open source companies are worth, but the path to VC-scale profitability is incredibly rare.
MotherDuck, a semi-competitor of theirs has raised $100mil in funding. DuckLabs has reportedly taken no external funding (so all ownership is with the founders) and was profitable with 30+ employees.
On the sidelines, other companies behind beloved open source products, like Astral, Astro, Bun are getting bought left and right.
With that as a backdrop, I think they should have been able to get quite a good payout.
1 reply →
I'm an idiot, and a lot of Hacker News goes over my head, but I still read it. Would anyone mind answering this question?
Are databases not a solved problem? Why are there lots of different databases? Why is one faster than the other? What's different between them?
It's a fair question!
My attempt at an answer: no, databases are not solved.
Specifically, different databases are better or worse for different use-cases.
For example, Postgres is a great "all around database" - you can use it for a lot of different things. As a "relational" database, it's really good if you have a table full of users, a table full of order, and you want to see all orders made by a user with ID=123. You need to answer questions like that a lot (eg every time someone on a website loads a page) and you need the answer fast (hundreds of miliseconds at most)
However, say your use-case is more like... you've got 100 billion rows of billing data ("joe was charged $123.45 on 2026-03-07 for a shirt, blue, size 11, brand foobar") in one table. You don't care much about joe, but you want to be able to find out how much was billed, total, in 2026-03 for blue shirts (or all year for brand foobar, or all time, for size 11). Postgres would struggle with data of that volume - you'd need a really big expensive database. A "columnar" database like duckdb (or clickhouse) might be able to answer those questions better.
Anyway, different databases are better/worse for:
- Large piles of data that you need to query in seconds
- Huge (petabytes) of data that you need to query in minutes, but can query in parallel
- Many related piles (like a standard relational database)
- Cases where you're mostly getting or retrieving single items (key-value stores)
- Huge piles of data that represent a long stream of events in time (time-series datbases)
- Piles of data that look and act more like files (object stores)
- When you need strict transactions
- When your need is very write-heavy
- When your need is very read-heavy
- and probably many others - I'm not even a huge data guy :)
So it all depends on your use-case. There are still cases that are not served well by any existing database - eg "filtering billions of rows, in milliseconds, by an arbitrary portion of several dozen very-high-cardinality columns" (to use an example that came up recently for me IRL) :)
This is a good summary. It's amazing that new database projects/products (whether it's open source or not) still spring up all the time.
Check this curated list of databases from Carnegie Mellon University: https://dbdb.io/
Just to add to this good explanation, a sufficiently large enough company (and even small successful companies) will eventually have a need for different DBs.
It's all about tradeoffs. Same reason there are so many kinds of wheeled transport and so many kinds of bridges.
There's no single set of requirements and desired properties that people have for databases.
What queries does it accept? How does it persist data? How does it manage replication and partitioning across multiple servers? Are questions with many answers and the right one varies by application.
> What queries does it accept? How does it persist data? How does it manage replication and partitioning across multiple servers? Are questions with many answers and the right one varies by application.
nothing prevents to build single database which would cover all such answers. Its engineering, funding and distribution problems: no-one built it yet.
3 replies →
My very high level take:
Every tool is a trade off between effort to create vs power of the solution.
Effort is generally expensive so most things settle on some general purpose local maximum. If you had infinite effort available, you could build bespoke hardware and software from the ground up to solve every problem. It would be faster and more power efficient than any solution available today.
CPUs win out over integrated circuits because the same CPU can be used for ~every software problem, so by using a CPU you benefit from everyone pooling their efforts to improve the general purpose CPU rather than their own specific niche. But when you reach a certain scale/requirements it makes sense to do something more specific. This is one reason why we have standardized GPUs. Still general purpose but more specialized than a CPU. Or think about how Bitcoin mining moved to ASICs, because they need to do one specific thing as fast and as power efficiently as possible.
So for databases, when you get to specific scale and requirements the same kind of specialization starts to make sense. DuckDB or Clickhouse for analytical loads, TigerBeetle for high scale transactional stuff, etc. And that scale is aggregated across ~all software users, i.e. scale of analytical workloads being big enough to support analytical DBs.
Also as time goes on and industries develop the cost to develop specific solutions can go down.
DuckDB is really great. It's definitely the best tool for working with any type of tabular laptop-sized analytical data. You can do some of what DuckDB does with SQLite, but DuckDB is much more versatile and performant.
This is an enormously wide question but the quickest way to give you an idea would be rephrasing as:
"Are cars not a solved problem? Why are there lots of different cars? Why is one faster than the other? What's different between them?"
I think the best way to approach the subject in an easy to grasp way is to ask Gemini or another frontier AI to teach you the basics, they will do a surprisingly good job and they'll be able to react to your questions with INFINITE patience.
There’s trade offs for performance, access patterns, throughput, latency, concurrency, workloads, rigor, type systems, extensibility… really every characteristic you could imagine.
It’s not a solved problem because each iteration of technology doesn’t just fix the mistakes of the past, it’s an evolution to solve the problems of the present.
> Are databases not a solved problem?
What do you mean by solved problem? I don't own DuckDB (sqlite, postgresql, etc). If I think I can create something as good or better than DuckDB, should I give up doing so (and get filthy rich with an acquisition) because someone thinks databases are solved? Solved databases aren't mine.
This is a real shame. I love DuckDB, and we've adopted/extended it and ducklake very heavily at Krea for our research.
I know the projects will remain open, and ostensibly still contributed to in the same direction, but surely AWS thinks of this as another piece of a product suite to compete with Databricks.
Nontheless, I think the open embedded query engine approach DuckDB is spearheading is larger than one project, and I remain excited about the broader ecosystem (especially datafusion).
I was a real fan from the very beginning, but now DuckDB 2.0 "as a server" and 5. asynchronous I/O [1] looks aimed at something very different from what I thought first.
1) https://duckdb.org/2026/08/17/duckdb-20-highlights
agree - I was really uneasy with the lede in their v2.0 preview:
"DuckDB has been an in-process database since day one. But people have asked us – very persistently – for a client/server mode, and we have finally caved"
This was already satisfied by numerous projects and products, and feels like a "me too" attempt to capture AI-based workflows. DuckDB always felt like "SQLite for Analytic Data" but I fear these changes and now acquiring the org leading technical direction is where they deviate for good. AWS is so unnecessary for what DuckDB can (and should, IMO) be; MongoDB jumps to mind as a cautionary tale.
Agreed that DuckDB as a server feels far from their initial mission, but how does async IO divert from it?
I didn't even necessarily mean diverting from the mission, just that optimising for network storage now reads like a feature maybe prioritised in anticipation of a stronger cloud user base
If you are into geo spatial, worth to check on the same class project - SedonaDB https://github.com/apache/sedona-db
"SedonaDB is an open-source single-node analytical database engine with geospatial as a first-class citizen"
Apache License 2.0 https://github.com/apache/sedona-db/blob/main/LICENSE
MIT License https://github.com/duckdb/duckdb/blob/main/LICENSE
https://duckdb.org/docs/current/core_extensions/spatial/func...
Title is "DuckLabs to Join AWS, Projects to Remain Open Source"
This gave me a shot of panic when I read the headline - thanks for correcting the record.
Surprised that there isn't more discussion of DuckDB source distributions.
Why do we need a source distribution for a well regarded MIT licensed project? Because it's not easy to contribute code to DuckDB if you don't work at DuckLabs. The CI used to take 5 hours for a simple bug fix last I looked (may have improved since I flagged it on social media).
There are two that I'm aware of:
Pygmy-Goose is focused on making agentic workflows faster by splitting the repo, making git worktrees cheap and 5 minute cached CI on 3 major platforms.
Several "Graph on DuckDB" efforts started on DuckDB and ended up reinventing a basic columnar codebase to innovate on because of these reasons. Even though people didn't document why, lack of outside contributor friendly flows is likely one of the reasons.
KuzuDB folks worked on something called GRainDB in 2022: https://vldb.org/cidrdb/2022/graindb-a-relational-core-graph...
But circa 2023 decided to write their own. Work continues as LadybugDB. One of my long term goals is to find an integration point with DuckDB's table implementation as the "node table". Conversely at some point DuckDB could implement all the join algorithms and LadybugDB's REL table in their code base.
For now, any talk of Graph on DuckDB is limited to DuckPGQ and the more recent entrant DuckGQL (both of which don't touch the storage layer which is the main reason why LadybugDB exists).
Maybe they learned AWS were planning on releasing a managed clone without their involvement?
That seems unlikely because AWS needs to build proprietary features within their services to lock in paying (enterprise) users. The problem now is that labs will inevitably focus on this work, which I view as opposed to local, in-process when your paycheque comes from selling hosted services.
And forced AWS to acquire them instead? Nice trick.
What's the relationship between MotherDuck (https://motherduck.com) and DuckLabs?
Hey, MotherDucker here! We've been working closely with the DuckLabs team since day one, and the collaboration will continue! You can read more here: https://motherduck.com/blog/duckdb-amazon/
My understanding is that MotherDuck provides hosting for DuckDB.
And DuckLabs is the engineering behind DuckDB.
If I'm correct, this seems like a signal that AWS is coming after the segment of customers wanting to host DuckDB (MotherDucks customers).
Correct me if I'm wrong though, please.
You're right - MotherDuck just got Jeffed.
TL;DR AWS will either acquire MD next/soon, or (more likely) keep them around for the optics that they are totally not going to starve the community of anything other than DuckDB as a hosted AWS service.
From the MD "about page":
The idea for MotherDuck came after Jordan Tigani, MotherDuck co-founder and chief duck-herder, saw DuckDB in action and thought, “Wow, this is amazing! someone should really build a serverless version.”
...
Hannes and Mark, who founded DuckLabs to focus on the core technology and build the world’s best analytics database, were looking for partners who would build a commercial cloud offering.
1 month later: "Re-writing DuckDB in Rust with Claude Ultra". There is a curios phenomenon, big tech uses great open source projects as a guinea pig for experimenting agent-based development approaches, see Bun, AstroJS.
Wouldn't be the worst thing, when I last used it, I got some c++ specific errors.
Wow congratulations for the original authors, but I hope it doesn't impact the users. I can imagine that it is very useful for AWS because they don't exactly have something similar.
I use DuckDB extensively for local dev as well as a parquet viewer.
Any indication yet as to whether Quack, DuckLake, real-time materialized views dev will continue full-steam ahead? B/c myself and i know of many others very interested in seeing these efforts completed... :crossed-fingers:
More details on the acquisition here: https://www.allthingsdistributed.com/2026/08/duckdb-and-the-...
DuckLabs will be an AWS subsidiary, not subsumed into AWS itself.
AWS rarely acquired startups, though leveraging someone else's tech is a typical pattern. It did license ParAccel and sold it as Redshift. It also runs Athena, which is based on Trino (a Presto fork).
Now, with Snowflake and Databricks earning big bucks in the intelligence era, time to gain market share by having DuckLabs under its ownership?
Also repackaged Blazegraph as Neptune (the original project was shut down after acquisition).
I wasn't expecting this, and I am pleasantly surprised. I think AWS has been a bad player in the data space and very much behind all the other warehouse providers for many years now. This could lead into interesting integrations of DuckDB on top of all the data that lives in S3 and provide a leaner, faster and a more modern alternative to Athena.
Feel like AWS got a lot of the concepts right with S3 Tables* ("serverless" Iceberg catalog on top of S3) ... would love, love to see a version of S3 Tables that lets you choose between Ducklake or Iceberg as the catalog.
* Cloudflare also seems to have gotten the same idea right with R2 Data Catalog
Athena already has Trino and Spark engines, it could totally have DuckDB one too.
This would be my bet and hope as well.
I made a prediction that motherduck will be acquired by GCP. But I could not imagine duckdb labs will be acquired by AWS. I do not think of AWS as a serious contender in the data space. So, we have now Pola.rs and motherduck in the market. Who will acquire them? I believe Microsoft has brought in a fair few industry talent to build their Azure Fabric product. Then you also have AI companies that are buying devtool/utility companies left and right.
Waiting for QuackDB the OSS spin off any second now
I've already created Haybarn which is Query.Farm's distribution of DuckDB:
learn about it here: https://query.farm/haybarn/
If my extension shows as "build failed" on https://query.farm/haybarn/status/v1.5.5/ how do I go about fixing it?
Presumably the issue is Haybarn-specific?
4 replies →
DuckDB is still OSS btw. It didn't go proprietary like Redis or ElasticSearch.
For now..
MallarDB
I've been super impressed by DuckDB ever since first trying it out about 3 three years ago. Congrats to the founders!
This is easily one of the most disappointing pieces of tech news I've read in a long time. RIP indie duck-things.
AWS name is really negative.
I trust the person leading DuckDB, nevertheless.
AWS is a great home for DuckLabs. They just want people to use more compute and storage, so they have a degree of technology-neutrality. This is the key to allowing DuckDB to continue to grow in whatever directions are natural, rather than being warped by some kind of walled garden data platform strategy.
Fair point, but no one is clearly articulating what AWS gets out of this. They don't get the DuckDB IP, that's owned by the foundation. All the work that the team at DuckLabs is putting in growing DuckDB and DuckLake are already in principle converting into compute/storage demand in AWS. So what does AWS actually want and how will it change DuckDB to accomplish it?
Maybe an OLAP db that scales down for serverless?
https://duckdb.org/roadmap
Current Google cache of this page states:
> "The DuckDB project is governed by the non-profit DuckDB Foundation . The Foundation and DuckLabs are not funded by external investors (e.g., venture capital)."
But "(Last updated: Aug 2026)" and I was not able to find this text anymore.
I wonder if they took vc money after all. I guess not, but still, it seem like to be difficult to live as an independent open source company. Getting a big co as a parent/sponsor is probably the next best thing.
Probably removed because DuckLabs is owned by Amazon now so it’s kind of confusing. Maybe Amazon said, “just take it down, our lawyers will approve some language.”
Congrats to the DuckDB team.
I've been eyeballing DuckDB and LanceDB as part of AI agent memories. This gives me a vibe that AWS will use DuckDB somehow in their ai agents sometime in the near future after seeing the potential.
like vector search ?
Yes. AWS has OpenSearch for cloud-first vector searches (disregarding cloud-hosted postgres with extensions etc). It's ridiculously expensive and not as fast.
DuckDB to the rescue.
Also embed the crap outta DuckDB locally in local agents running on VPS, etc
1 reply →
super curious what exactly does it mean to acquire an open source product.
Devs gotta eat. Yeah the code is out there but the code is a result of a lot of thinking, prioritization, research into what is needed from the actual product. So now AWS owns that mindshare and talent and will (probably heavily) influence its decisions. I just hope DuckDB doesn't stray from its goal of being the SQLite (e.g. embedded) OLAP.
When will folks finally learn that if they like having a salary, devs that produce tools actually would like to have one as well?
1 reply →
It can go different ways. Redis, Elastic Search, MySQL, and Java all have different stories with some common threads.
Complete control over what gets merged and worked on by the core team.
it was already like that, and merging 3rd party changes to the core was troublesome, so maybe aws just bought them cause of this reason :D
Back in 2018, I took Hannes’ database course as part of my CS degree, which was one of the better ones I took. Over the years, I’ve seen DuckDB celebrated here (and other places), and now this. Congrats to both him and the Ducklabs team.
Yeah the foundation is doing the heavy lifting here. Amazon's track record with technically interesting projects after a reorg is not great.
Remember when big co used to just donate to open source projects to help them out instead of acquiring/dominating them?
I am a big fan of the Duck team since before their v1.0 and I am happy for them personally for the big payoff, both in monetary terms but also in terms of scale and longer-term viability of their baby. I am also happy to see the arrangement will keep the core OSS. Let's see what the future holds now!
DuckLabs does services and support around DuckDB.
"We also worried that scaling DuckLabs into a much larger sales, support, and operations organization would pull our attention away from the technical work and open-source community that made DuckDB successful in the first place."
Given AWS's services arm seems like a good play for a team. Congrats!
I am happy for the team's success but I am sad and anxious for what may become of the DuckDB. It is my favorite tool. Like other comments mentioned, DuckDB is open source and MIT license so I hope it will survive and evolve further the way it did.
Extend, embrace, quack.-
What if AWS eventually steer away duckdb team's bandwidth towards their AWS products or influence their work, since they are technically AWS employees.
What does the financial counterpart of such a deal look like if the IP (main asset) is not part of the deal?
Purely acqui-hiring?
People using DuckDB, what's your use case? I use sqlite for a lot of my personal projects. What's a good use case for using DuckDB?
DuckDB is for analytics, so OLAP instead of OLTP. If you're using the DB for normal transactions, stick with sqlite
Thanks, I gathered that much. I am curious what kind of stuff people are using it for, especially in their personal projects.
What is the go to alternative from DuckDB?
did not expect that
I hope the future for DuckDB is still bright
Also did not expect this. I did expect MotherDuck to acquire them at some point (in fact, I kinda thought they already did!)
I'm hoping this means we get an rds + s3 implementation of ducklake from AWS: https://ducklake.select/
I am glad for them. Does anyone know the amount of the operation?
AWS acquiring DuckLabs is massive. nice move.
one feature I can't wait from the DuckDb team are real-time materialized views.
I hope AWS doesn’t dilute the DuckDB brand by calling their managed DuckDB offering SageMaker<something>…
Goobye DuckDB.
Great move for AWS, does it mean AWS wants to build competitor to clickhouse ?
Shameless plug for DuckDB Harbor - DuckDB server over HTTP (UDS or TCP/IP). Includes a new harbor based DuckDB CLI called pilot:
https://github.com/shreeve/duckdb-harbor
How do you suppose AWS can monetize it?
Avoid antitrust scrutiny with this one weird trick.
Goodbye DuckDB and hello surprise enterprise DuckDB that has special features that you can't live without that only work with Enterprise DuckDB.
LDAP support :)
AI, you forgot AI
Who needs SQL when you can just ask the DB for the records you want?
1 reply →
We have seen that how many times now? Terraform, docker, elasticsearch, influxdb. Nono, we are still the good guys, believe us. Nothing will change. Yea, thats gonna get forked and rewritten in rust.
Prediction: this is start of an aquisition spree by AWS.
AWS is always hungry. Watch out PostgreSQL
This doesn't even make sense. Postgres is and has been open source since the 90s and AWS has had an existing Postgres offering since approximately always.
And there is no single company developing. Its a healthy mix of engineers from many companies. A perfect model to prevent this issue here of being aquihired.
Wow, that sucks balls.
Can we stop consolidating everything under a handful of massive companies?
This will get a lot worse before it will get better. All the hyperscalers will inevitably drift towards total vertical integration.
Let's hope they never reach the "owning a private military" stage.
That's horrible news.
I guess this will be a good test of the open source model DuckDB has opted into.
As I understand it, DuckDB is MIT-licensed and governance is provided by a separate, non-profit DuckDB foundation. This was done explicitly to prevent BSL-ification.
I'm very curious to see whether that approach holds the line. I wouldn't bet on it, but one can hope?
This will be the engine for redshift now. They’ll make it read write and it’ll be magic.
Man. DuckDB is one of my favorite tools in the past decade. It basically replaced pandas/Polars for me and I hope aws leaves it alone.
Otoh, I am glad those guys got paid.
Please edit the title it’s wrong
Congrats!
Insane!!!!
I see a site like https://ducklabs.com/ and it's clear I'm waaaay over thinking my website.
Please No No No why.....
History repeats itself; the same thing will happen as with MySQL—when it was acquired by Oracle, it stagnated.
This is awful news.
I said "Oh shit !" out loud in a meeting.
Ditto, I had a conversation last week about Duck and Kagi being the two things I hoped never got acquired and here we are.
On one hand I am glad that (hopefully) some people were rewarded for their hard work.
On the other hand, do we have to live in an oligarchy?
We just can't have nice things, can we?
Just like press freedom is for those who own press, nice things are for those who can buy nice things.
its open source, we can fork .. (i know for such a project it will require a very special group of "we", but in theory .. it can happen)
If you need a fork, I've already done most of the hard work for all of you.
https://query.farm/haybarn/
Or
https://github.com/Query-farm-haybarn
I've been releasing the versions all the way since 1.5.3 and all community extensions.
2 replies →
Buying nice things should not be underestimated :)
such a disappointing outcome
[flagged]
[dead]
[dead]
[flagged]
I'm glad I stuck with SQLite. Governance is an important part of any open source project. SQLite has kept things narrow and focused, while DuckDB's philosophy is to do more and more, making it a general-purpose data science tool. I am old-fashioned in that I believe in the philosophy that software should "do one thing and do it well"