Dziesięć lat, jeden podpis
Hannes Muhleisen i Mark Raasveldt spędzili blisko dekadę na budowie DuckDB, najpierw jako projektu badawczego w amsterdamskim Centrum Wiskunde en Informatica, zanim wydzielili go jako niezależną firmę DuckLabs. 26 sierpnia 2026 roku Amazon ogłosił ostateczną umowę o przejęciu tej firmy.
DuckDB zdobyło swoich zwolenników, robiąc dokładnie odwrotnie niż większość dostawców baz danych: działa wewnątrz własnej aplikacji, na własnym laptopie lub serwerze, bez konta w chmurze, bez wywołania sieciowego i bez dostawcy naliczającego opłaty za zapytanie. To podejście uczyniło je domyślnym wyborem dla zespołów z UE budujących samodzielnie hostowane potoki analityczne, które mogły audytować, przenosić lub wyłączać bez pytania kogokolwiek o zgodę.
Co naprawdę kupiło AWS
AWS kupiło firmę, nie kod. Ogłoszenie Amazona jest jednoznaczne: DuckLabs, licząca około 30 osób jednostka komercyjna, w całości dołącza do AWS, podczas gdy otwartoźródłowy projekt DuckDB pozostaje na licencji MIT i jest zarządzany osobno przez niezależną, non-profit DuckDB Foundation. Nie ujawniono warunków finansowych, a transakcja ma zostać sfinalizowana w ciągu kilku tygodni, z zastrzeżeniem zwyczajowych warunków.
Muhleisen i Raasveldt nadal kierują techniczną ścieżką projektu open source, a według AWS nic się nie zmienia dla obecnych użytkowników DuckDB przed zamknięciem transakcji. Andy Warfield, wiceprezes i distinguished engineer w Amazon, opisał dwa lata wcześniejszej współpracy z zespołem DuckLabs poprzedzające przejęcie.
Rywal nazywa ten schemat wprost
Jordan Tigani kieruje MotherDuck, firmą, która zbudowała komercyjny produkt chmurowy bezpośrednio na DuckDB i teraz konkuruje z tym, co AWS zbuduje następnie. Opisał przejęcie jako przewidywalny ruch: czekać, aż projekt open source stanie się wystarczająco popularny, a potem wchłonąć osoby nim kierujące, by przekształcić tę popularność w zarządzaną usługę chmurową.
Odczyt Tiganiego nie jest całkowicie wrogi. Twierdzi, że Amazon ma teraz bezpośredni interes finansowy w utrzymaniu DuckDB otwartego, dobrze utrzymanego i szeroko stosowanego, ponieważ każda nowa instalacja DuckDB jest z czasem potencjalnym źródłem przychodów obliczeniowych AWS. Obie rzeczy mogą być prawdziwe naraz: interes w utrzymaniu zdrowia projektu jest realny, podobnie jak interes w kształtowaniu jego przyszłości w kierunku AWS.
Luka, której nie widzi lista zakupowa
Wybór otwartoźródłowego, samodzielnie hostowanego narzędzia zamiast dostawcy chmury to standardowy krok suwerenności cyfrowej dla zespołów z UE ważących rezydencję danych zgodną z RODO, prawo do audytu czy koszty wyjścia. Ten wybór chroni kod, który działa dzisiaj. Nie mówi nic o tym, kto zatrudnia niewielką grupę, która faktycznie pisze kod jutra.
DuckLabs była bliska ideału firmy bazodanowej przyjaznej suwerenności: z siedzibą w Amsterdamie, zarejestrowana w UE, na licencji MIT, z modelem biznesowym opartym na wsparciu i hostingu, a nie na uzależnianiu klienta. Mimo to trafiła do amerykańskiego hiperskalowca, gdy tylko jej baza użytkowników uczyniła przejęcie opłacalnym komercyjnie. Lista zakupowa pytająca jedynie o licencję i miejsce hostingu nigdy nie zapytała, gdzie opiekunowie projektu odbierają wypłatę.
Co naprawdę chroni Fundacja
Licencja MIT i niezależna DuckDB Foundation to realna, egzekwowalna ochrona, a nie język marketingowy. Każda organizacja może dziś zrobić fork DuckDB, dowolnie długo utrzymywać obecny kod i nie być z tego tytułu nic winna AWS.
To, czego licencja nie chroni, to rozpęd. Fork to prawo, z którego w praktyce prawie nikt nie korzysta, ponieważ wartość projektu open source tkwi w jego aktywnych opiekunach, a nie w zamrożonym kodzie źródłowym. Dopóki Muhleisen i Raasveldt wyznaczają mapę drogową DuckDB, to ryzyko pozostaje teoretyczne. Przejęcie to moment, w którym zespoły z UE uruchamiające DuckDB produkcyjnie powinny spisać, co faktycznie zrobiłyby, gdyby to się kiedykolwiek zmieniło.
Czytaj dalej: Amazon buduje własną elektrownię gazową 7,65 GW | OpenAI zostawia agentów jednej chmurze
