Google Sheets w automatyzacjach: kiedy arkusz wystarczy, a kiedy się zemści

Prawie każde wdrożenie, które zaczynamy w MŚP, gdzieś po drodze dotyka arkusza. Raz jest źródłem danych, raz miejscem, gdzie automatyzacja dopisuje wyniki, a raz panelem, w którym ktoś przełącza flagi sterujące workflow. To nie jest wstyd ani obejście: arkusz bywa najrozsądniejszym wyborem, bo działa od pierwszej minuty i każdy w firmie potrafi go otworzyć.

Kłopot zaczyna się później. Ten sam arkusz, który obsługiwał trzysta wierszy i jeden proces, po roku ma osiem zakładek, cztery workflow piszące do niego równocześnie, kolumnę z datami w trzech formatach i dopisek „NIE SORTOWAĆ" w komórce A1. Potem ktoś dodaje kolumnę w środku i połowa automatyzacji przestaje trafiać w odpowiednie pola.

Poniżej: co Google Sheets naprawdę wytrzymuje (z liczbami z dokumentacji), które wzorce bronią się na dłuższą metę, siedem sposobów, na jakie arkusz się mści przy skali, i jak przejść na bazę bez zatrzymywania firmy.

TL;DR: Arkusz wystarczy przy jednym procesie, kilku tysiącach wierszy, jednym systemie piszącym i danych, które ktoś ma czytać oczami. Zemści się przy równoczesnych zapisach, danych bez typów, relacjach między tabelami i uprawnieniach per wiersz. Twarde granice: 10 mln komórek na plik, 60 zapisów przez API na minutę na użytkownika, 6 minut na wykonanie skryptu Apps Script.

Dlaczego arkusz jest domyślnym startem

Google Sheets ma przewagi, których żadna baza nie daje za darmo. Zerowy próg wejścia: nie ma schematu do zaprojektowania ani serwera do postawienia. Czytelność dla człowieka: właściciel wchodzi, filtruje i widzi, co się dzieje, a baza bez zbudowanego interfejsu jest dla niego czarną skrzynką. Do tego konektory: node Google Sheets w n8n obsługuje dopisanie wiersza, odczyt, aktualizację, czyszczenie zakładki oraz operację „Append or Update Row", która dopisuje wiersz albo aktualizuje istniejący, jeśli znajdzie dopasowanie we wskazanej kolumnie. W Make wygląda to podobnie.

Dlatego przy pierwszej automatyzacji prawie zawsze mówimy: zacznij od arkusza. Sensowniej w tydzień uruchomić proces i sprawdzić, czy ktokolwiek z niego korzysta, niż przez miesiąc projektować bazę pod proces, który za kwartał będzie wyglądał inaczej (pierwsza automatyzacja w 30 minut niemal na pewno będzie miała arkusz po jednej ze stron).

Trzy wzorce, które naprawdę działają

Nie każde użycie arkusza jest długiem technicznym. Te trzy zostawiamy w firmach na stałe.

Arkusz jako log. Automatyzacja zrobiła swoje i dopisuje jeden wiersz: data, kto, co, wynik, ewentualny błąd. Nikt go nie edytuje ani nie kasuje, dane tylko przyrastają. To najbezpieczniejszy możliwy sposób użycia arkusza, bo przy dopisywaniu na końcu tabeli miejsce zapisu wyznacza Google, więc dwa procesy piszące równocześnie nie walczą o ten sam wiersz. Klient sam sprawdzi, czy nocny import przeszedł, bez logowania się do n8n.

Arkusz jako panel sterowania. Reguły przypisania, mapowanie kodów produktów na kategorie, progi kwotowe, przełącznik „wysyłaj / nie wysyłaj". Workflow czyta ten arkusz na starcie i zachowuje się według jego zawartości, więc zmiana reguły biznesowej nie wymaga wchodzenia do automatyzacji ani nikogo technicznego. Ten sam wzorzec stosujemy u siebie, tylko na tabeli w bazie (automatyzacje wokół ClickUpa).

Arkusz jako bufor między systemami, które się nie znają. Eksport z systemu A ląduje w arkuszu, workflow czyta go co godzinę i wrzuca do systemu B. Prowizorka z definicji, ale przy narzędziach bez API bywa jedynym rozwiązaniem wykonalnym w rozsądnym czasie (jak automatyzować, gdy narzędzie nie ma API).

Wspólny mianownik: arkusz jest albo wyłącznie do zapisu, albo wyłącznie do odczytu, i pisze do niego jedno źródło. Kłopoty zaczynają się wtedy, gdy ten warunek przestaje być spełniony.

Twarde limity: liczby z dokumentacji

Poniższe liczby pochodzą z dokumentacji Google Drive, Google Sheets API i Apps Script (stan na sierpień 2026).

Co	Limit
Komórki w jednym pliku	10 mln (albo 18 278 kolumn, kolumna ZZZ)
Odczyty przez Sheets API	300/min na projekt, 60/min na użytkownika w projekcie
Zapisy przez Sheets API	300/min na projekt, 60/min na użytkownika w projekcie
Limit dzienny API	brak, o ile mieścisz się w limitach minutowych
Pojedyncze zapytanie API	zalecane maks. 2 MB, maks. 180 sekund przetwarzania
Apps Script: jedno wykonanie	6 minut (funkcja niestandardowa: 30 sekund)
Apps Script: triggery na dobę	90 minut (konto darmowe), 6 godzin (Google Workspace)
Apps Script: URL Fetch na dobę	20 000 (konto darmowe), 100 000 (Workspace)
IMPORTRANGE	do 10 MB odebranych danych na jedno zapytanie
Import z Excela	komórka powyżej 50 000 znaków znika przy konwersji

Dwie liczby z tej tabeli robią najwięcej szkody.

60 zapisów na minutę na użytkownika, czyli jeden na sekundę. Workflow przetwarzający dwieście zamówień i dopisujący je pojedynczo dostaje po kilkunastu sekundach 429: Too many requests, a dokumentacja Google każe wtedy ponawiać zapytania z rosnącym odstępem (exponential backoff). Rozwiązanie jest banalne: zbierz wiersze i zapisz je jednym zapytaniem zamiast dwustu. Większość workflow, które naprawiamy, robi odwrotnie, bo tak wychodzi naturalnie z pętli w n8n czy Make.

6 minut na wykonanie skryptu Apps Script. Skrypt, który przy 500 wierszach chodził 40 sekund, przy 5000 przekracza limit i przerywa się w połowie: bez błędu biznesowego, zostawiając część danych przetworzoną, a część nie.

Limit 10 mln komórek wygląda na nieosiągalny, dopóki nie policzysz: arkusz z 30 kolumnami przekracza go przy około 330 tysiącach wierszy. Dużo wcześniej plik zaczyna się otwierać kilkanaście sekund i przeliczać przy każdej zmianie.

Siedem sposobów, na jakie arkusz się mści

1. Równoczesne zapisy i nadpisywanie

Dopisywanie na końcu tabeli jest bezpieczne, aktualizacja konkretnego wiersza nie. „Znajdź wiersz, gdzie kolumna A równa się 1234, i zaktualizuj kolumnę F" to w rzeczywistości odczyt numeru wiersza, a potem zapis pod ten numer. Między jednym a drugim ktoś może posortować arkusz albo wstawić wiersz, więc zapis trafia w cudze dane. Nie zostaje po tym żaden ślad, bo automatyzacja raportuje sukces.

Osobna pułapka siedzi w ustawieniach zapisu. Sheets API dopisuje dane w trybie INSERT_ROWS, który wstawia nowe wiersze, albo OVERWRITE, który nadpisuje to, co znajdzie w docelowym obszarze. Konektor ustawia to za Ciebie, a mało kto zagląda w opcje zaawansowane.

2. Brak typów, czyli daty i liczby jako tekst

W bazie kolumna „data zamówienia" ma typ daty i nic innego się tam nie zmieści. W arkuszu jest komórka, a w komórce może być cokolwiek. Sheets API ma na to parametr valueInputOption: przy RAW wartość „nie zostanie sparsowana i zostanie zapisana taka, jaka jest", przy USER_ENTERED wartości „zostaną sparsowane tak, jakby użytkownik wpisał je w interfejsie".

Obie opcje bolą, tylko inaczej. Przy RAW data „2026-08-12" zostaje tekstem, więc sortowanie chronologiczne przestaje działać, a formuła licząca dni zwraca błąd. Przy USER_ENTERED arkusz interpretuje wartości według swojej lokalizacji: numer klienta „0048123" traci wiodące zero, numer katalogowy „5-2" zamienia się w datę, a kwota „1,5" bywa czytana jako tysiąc pięćset albo jako półtora. Efekt ten sam: raport pokazuje liczby niezgodne z rzeczywistością i nikt nie wie, od kiedy.

3. Brak relacji, czyli piekło VLOOKUP-a

Arkusz nie ma relacji między tabelami, więc firmy budują je funkcjami wyszukującymi: „Zamówienia" ciągną nazwę klienta z „Klientów", „Rozliczenia" z „Zamówień", a „Raport" ze wszystkiego naraz. Psuje się to przewidywalnie. Nie ma klucza obcego, więc zamówienie może wskazywać na klienta, którego już nie ma w tabeli, i widać to dopiero jako #N/D w raporcie. Nie ma ograniczenia unikalności, więc ten sam klient istnieje w trzech wariantach zapisu, każdy z własną historią. A automatyzacja czytająca komórkę z formułą dostaje albo jej wynik, albo wartość sprzed przeliczenia.

4. Kruchość IMPORTRANGE

Dokumentacja Google radzi ograniczać łańcuchy IMPORTRANGE, unikać cykli (arkusz A ciągnie z B, a B z A), ograniczać liczbę arkuszy odbierających dane oraz rozmiar importowanych zakresów, bo każdy odbiorca musi odczytać źródło. Jedno zapytanie ma limit 10 MB odebranych danych.

Do tego dochodzi rzecz spoza dokumentacji, widoczna przy każdym audycie: IMPORTRANGE wymaga jednorazowej autoryzacji dostępu do pliku źródłowego. Gdy właściciel tego pliku odchodzi z firmy albo ktoś porządkuje uprawnienia na Dysku, połączenie się rozłącza. Arkusz pokazuje błąd, a automatyzacja, która go czyta, dostaje puste dane i grzecznie zapisuje pustkę dalej.

5. Uprawnienia działają na cały plik, nie na wiersz

Dostęp w Google Sheets nadaje się do pliku. Możesz ukryć zakładkę i chronić zakres, ale to zabezpieczenie interfejsu, nie danych: kto ma dostęp do pliku, ma dostęp do wszystkiego, także przez API i przez pobranie kopii.

Handlowiec ma widzieć swoje leady, ale nie cudze, księgowa kwoty, a koordynator nie. Każdy taki scenariusz kończy się w arkuszu rozbiciem danych na kilka plików, czyli powrotem do problemu z punktu czwartego, albo pogodzeniem się z tym, że wszyscy widzą wszystko. A jeśli siedzą tam dane osobowe, robi się z tego również rozmowa o RODO (gdzie trzymać dane firmowych automatyzacji).

6. Ciche zmiany struktury

Automatyzacje wskazują na kolumny. Gdy ktoś wstawi kolumnę w środku tabeli, zmieni nagłówek z „Telefon" na „Nr telefonu" albo przemianuje zakładkę, workflow trafia w złe pole lub zatrzymuje się z błędem. Wersja z błędem jest lepsza, bo widać ją od razu. Gorszy scenariusz to workflow, który dalej działa i zapisuje adresy e-mail do kolumny z numerem telefonu, nie wysyłając alertu, bo technicznie wszystko się powiodło. Ryzyko da się zmniejszyć (praca na nazwach nagłówków zamiast na literach kolumn, sprawdzanie nagłówków w workflow, blokada edycji struktury), ale to obejścia, nie rozwiązanie.

7. Audyt zmian, którego praktycznie nie ma

Historia wersji odpowie na pytanie „kto to zmienił w zeszłym tygodniu", ale jest zapisem edycji pliku, a nie zmian rekordu. Nie zbudujesz na niej raportu ani nie podepniesz jej pod alert, nie wyciągniesz z niej też sprawnie wszystkich zmian statusu jednego zamówienia w kolejności. Starsze wersje z czasem są łączone w większe bloki, więc ziarnistość maleje, a wszystkie zapisy z automatyzacji figurują jako zmiany jednego konta serwisowego. Baza rozwiązuje to jedną tabelą historii: co, kto, kiedy, z jakiej wartości na jaką.

„Arkusz w automatyzacji rzadko wywala się z hukiem. On zaczyna po cichu kłamać: jedna data zapisana jako tekst, jeden zapis w cudzym wierszu i raport pokazuje liczby, w które wszyscy wierzą. Awarię naprawiasz tego samego dnia, a błędne dane odkrywasz po kwartale, gdy ktoś porówna je z fakturami." — Mikołaj Brunka, założyciel NoCodeWork

Kiedy arkusz w zupełności wystarczy

Nie każdą sytuację trzeba przenosić do bazy. Arkusz zostaje na miejscu, gdy spełniona jest większość poniższych warunków:

Danych jest do kilku tysięcy wierszy i przyrastają wolno.
Pisze do niego jeden system albo jedna osoba, nie kilka naraz.
To jeden proces, nie kilka powiązanych ze sobą tabel.
Dane mają być czytane oczami: zestawienie, log wykonania, prosty raport.
Wszyscy z dostępem do pliku mogą widzieć wszystkie dane.
Nie musisz odtwarzać historii zmian pojedynczego rekordu.
To prototyp albo proces, który wciąż się zmienia.

Ostatni punkt jest ważniejszy, niż wygląda. Projektowanie bazy pod proces, którego jeszcze nie rozumiecie, kosztuje więcej niż późniejsza migracja z arkusza, bo najpierw i tak trzeba zmapować proces.

Sygnały, że czas na bazę danych

Wystarczą dwa lub trzy naraz, żeby zacząć planować.

Sygnał	Co to znaczy
Arkusz otwiera się kilkanaście sekund	jesteś przy granicy wydajności, nie objętości
Więcej niż jeden system pisze do tego samego pliku	prędzej czy później dojdzie do nadpisania
Powtarzają się duplikaty klienta albo zlecenia	brak ograniczenia unikalności
Zakładki łączą się formułami wyszukującymi	potrzebujesz relacji, nie arkusza
Ludzie mają widzieć różne wycinki danych	uprawnienia per wiersz są w arkuszu niewykonalne
Padło pytanie „kto i kiedy to zmienił"	potrzebujesz historii rekordu
Ktoś dopisał w A1 „NIE SORTOWAĆ"	struktura jest już krucha, tylko nikt tego nie nazwał
Workflow dostaje `429` albo skrypt kończy się po 6 minutach	przekroczyłeś limity techniczne, nie da się ich obejść

Wybór celu zależy od tego, czego brakuje najbardziej. Airtable daje typy pól, relacje i widoki bez żadnej infrastruktury, ale płacisz za użytkownika, a dane leżą u dostawcy. NocoDB robi bardzo podobnie, tylko na Twoim serwerze i bez opłat za każdą osobę, co przy większych zespołach i danych osobowych bywa decydujące. PostgreSQL wybierasz, gdy liczą się wolumen, wydajność zapytań i integralność danych, a interfejs budujesz osobno. Pełne porównanie czterech dróg: Airtable vs SQL vs Excel vs open source.

Migracja bez big-bangu

Najgorszy scenariusz to weekend, w którym wszystko zostaje przełączone, a w poniedziałek połowa firmy nie wie, gdzie wpisywać dane. Robimy to w pięciu krokach.

1. Baza staje się źródłem prawdy, arkusz zostaje na miejscu. Przenosisz dane i przepinasz automatyzacje, żeby zapisywały do bazy. Arkusz nadal istnieje, ale przestaje być miejscem, z którego systemy cokolwiek odczytują.

2. Arkusz zamienia się w widok. Workflow co godzinę albo co noc czyści zakładkę i wpisuje aktualny stan z bazy. Nikt nie musi zmieniać nawyków: ludzie dalej wchodzą do znanego pliku, filtrują, robią tabele przestawne. Zmienia się tylko kierunek, bo arkusz czyta, a nie zapisuje. To zdejmuje większość oporu przed zmianą.

3. Wejścia przechodzą na formularz. Miejsca, w których ludzie wpisywali dane ręcznie, zastępujesz formularzem albo widokiem edycyjnym w bazie. Tu pierwszy raz pojawiają się walidacja i typy: data jest datą, kwota liczbą, status wartością z listy.

4. Uprawnienia i historia. Ustawiasz, kto co widzi, i włączasz zapis historii zmian. Dopiero teraz firma dostaje rzeczy, których w arkuszu nie było w ogóle.

5. Arkusz-widok znika albo zostaje. Jeśli nikt do niego nie zagląda, kasujesz. Jeśli ktoś zbudował na nim własne raporty, zostaje. Nie ma nagrody za usunięcie pliku, w którym ktoś ma wygodny widok danych.

Ten sam schemat, z perspektywy Excela i z kosztami czterech dróg budowy, opisaliśmy w tekście o aplikacji wewnętrznej zamiast Excela.

Na co uważać

Nie zapisuj wierszy w pętli. Zbieraj dane w workflow i zapisuj jednym zapytaniem. Przy jednym zapisie na wiersz limit 60 zapisów na minutę kończy się po minucie pracy, a automatyczne ponawianie zapytań potrafi zduplikować dane.
Ustaw świadomie sposób interpretacji wartości i przetestuj go na numerach z wiodącym zerem, kwotach z przecinkiem i datach. Sprawdź też lokalizację pliku, bo to ona decyduje o interpretacji.
Nie rób z arkusza kolejki zadań. Wzorzec „workflow czyta wiersze ze statusem do zrobienia, przetwarza i zmienia status" wygląda niewinnie, a przy dwóch równoległych uruchomieniach przetwarza te same wiersze dwa razy.
Zablokuj strukturę. Chroń wiersz nagłówków, nie pozwalaj wstawiać kolumn w środku i pracuj na nazwach nagłówków zamiast na literach kolumn.
Dodaj alert o pustym odczycie. Zero wierszy to nie „dziś nic nie było", tylko najczęstszy objaw zerwanego IMPORTRANGE albo zmienionej nazwy zakładki.

FAQ

Ile wierszy wytrzyma Google Sheets w automatyzacji?

Twardy limit to 10 mln komórek na plik (albo 18 278 kolumn), co przy 30 kolumnach daje około 330 tysięcy wierszy. Problemy pojawiają się dużo wcześniej: przy kilkudziesięciu tysiącach wierszy z formułami arkusz otwiera się kilkanaście sekund i przelicza przy każdej zmianie. W praktyce granicą użyteczności jest kilka do kilkunastu tysięcy wierszy, a nie limit Google.

Jakie są limity Google Sheets API przy automatyzacji?

Sheets API pozwala na 300 odczytów i 300 zapisów na minutę na projekt oraz 60 odczytów i 60 zapisów na minutę na użytkownika w projekcie. Limitu dziennego nie ma, o ile mieścisz się w minutowych. Przekroczenie zwraca 429: Too many requests i wymaga ponawiania z rosnącym odstępem. Pojedyncze zapytanie powinno mieścić się w 2 MB i 180 sekundach przetwarzania. Wniosek praktyczny: zapisuj paczkami, nie wiersz po wierszu.

Czy dwa workflow mogą pisać do tego samego arkusza jednocześnie?

Dopisywanie nowych wierszy na końcu tabeli jest względnie bezpieczne, bo miejsce zapisu wyznacza Google, a nie Twój workflow. Aktualizowanie istniejących wierszy bezpieczne nie jest: między odczytem numeru wiersza a zapisem dane mogą się przesunąć, więc zapis trafia w cudzy wiersz. Jeśli kilka procesów musi aktualizować te same rekordy, to sygnał, żeby przenieść dane do bazy.

Jakie są limity Apps Script przy arkuszach?

Jedno wykonanie skryptu ma limit 6 minut, funkcja niestandardowa 30 sekund. Łączny czas pracy triggerów to 90 minut na dobę na koncie darmowym i 6 godzin w Google Workspace. Do tego 20 triggerów na użytkownika na skrypt, 30 równoczesnych wykonań i 20 000 wywołań URL Fetch na dobę (100 000 w Workspace). Skrypt przetwarzający duży arkusz przerwie się w połowie, gdy przekroczy 6 minut.

Kiedy przenieść dane z arkusza do bazy danych?

Gdy pojawią się dwa lub trzy z tych sygnałów: pisze do niego więcej niż jeden system, powtarzają się duplikaty rekordów, zakładki łączą się formułami wyszukującymi, różne osoby mają widzieć różne wycinki danych, potrzebujesz historii zmian rekordu albo automatyzacje dostają błędy limitów. Migrację rób etapami: najpierw baza jako źródło prawdy, potem arkusz jako widok tylko do odczytu, na końcu formularze i uprawnienia.

Podsumowanie

Google Sheets jest dobrym miejscem startu automatyzacji i to się nie zmienia. Uruchamiasz proces w tydzień, ludzie widzą dane bez szkolenia, a każda platforma automatyzacji ma gotowy konektor. Przy jednym procesie, kilku tysiącach wierszy i jednym systemie piszącym arkusz nie jest kompromisem, tylko rozsądnym wyborem.

Mści się dopiero wtedy, gdy zaczyna udawać bazę danych: bez typów, bez relacji, bez uprawnień per wiersz i bez historii rekordu. Limity techniczne są przy tym twarde i nie obejdziesz ich dobrą konfiguracją. Samo przejście na bazę bywa za to łagodniejsze, niż firmy się spodziewają. Baza wchodzi pod spód, arkusz zostaje jako widok zasilany eksportem, a ludzie pracują dalej w pliku, który znają.

Nie masz pewności, czy Wasz arkusz jeszcze wystarcza, czy już cicho kłamie? Umów bezpłatną konsultację — przejrzymy proces i powiemy wprost, jeśli najlepszym rozwiązaniem jest zostawienie arkusza tam, gdzie jest.