--- title: "Datawarehouse voor het MKB: PostgreSQL, BigQuery of Snowflake? | Coding Agency" description: "Wanneer heb je een datawarehouse nodig, en wanneer volstaat een rapportagedatabase in PostgreSQL? De tussenstappen, de rol van Power BI en de keuze voor BigQuery of Snowflake." url: https://coding.agency/kennisbank/datawarehouse-mkb-postgresql-bigquery-snowflake source: Coding Agency (https://coding.agency) language: nl --- Architectuur 12 min leestijd # Datawarehouse voor het MKB: PostgreSQL, BigQuery of Snowflake?. Wanneer heb je een datawarehouse nodig, en wanneer volstaat een rapportagedatabase in PostgreSQL? De tussenstappen, de rol van Power BI en de keuze voor BigQuery of Snowflake. [ Jasper Koers ](https://coding.agency/over/jasper-koers) · 7 okt. 2026 ## In het kort - Een datawarehouse is geen product maar een aparte plek waar data uit meerdere systemen samenkomt, met historie en vaste definities - Voor de meeste MKB-bedrijven is een rapportagedatabase in PostgreSQL met nachtelijke verversing de juiste eerste stap - BigQuery en Snowflake lonen pas bij veel bronnen, grote volumes of veel gelijktijdige analisten, en rekenen af op gebruik - Power BI is de laag waarin je kijkt, niet de plek waar je data hoort te wonen - De meeste rapportageproblemen zijn definitieproblemen: leg eerst vast wat omzet, klant en marge betekenen ## Wat is een datawarehouse, en heb je er een nodig? Kort antwoord Een datawarehouse is een aparte database waarin je data uit meerdere systemen samenbrengt om erover te rapporteren, los van de systemen waarin je dagelijks werkt. De meeste MKB-bedrijven hebben daar geen BigQuery of Snowflake voor nodig: een rapportagedatabase in PostgreSQL met een nachtelijke verversing volstaat, tot het aantal bronnen, het volume of het aantal analisten dat ontgroeit. Het begint bijna altijd met dezelfde vraag: "Kunnen we de omzet per klant naast de uren uit het projectsysteem zetten?" De cijfers zitten in het boekhoudpakket, de uren in een ander systeem, de offertes in het CRM. Iemand maakt een export, plakt die in Excel en bouwt er een draaitabel op. Een maand later doet iemand anders hetzelfde, en komen er twee omzetcijfers op tafel die niet gelijk zijn. Op dat moment valt het woord datawarehouse. En vrijwel direct daarna de namen van grote platformen, met een architectuurplaat die doet vermoeden dat je een datateam nodig hebt. Dat is meestal niet zo. In dit artikel leg ik uit wat een datawarehouse wel en niet is, welke tussenstappen er bestaan, en waar de grens ligt waarop een platform als BigQuery of Snowflake zijn geld waard wordt. ## Waarom je niet rapporteert op de database waarin je werkt De database onder je applicatie is ingericht voor het dagelijkse werk: een order opslaan, een factuur boeken, een voorraadstand aanpassen. Dat zijn veel kleine handelingen die elk een paar rijen raken. Een rapport stelt een heel ander soort vraag: tel alle orderregels van de afgelopen drie jaar op, gegroepeerd per productgroep en per maand. Dat is één vraag die miljoenen rijen leest. Die twee soorten werk zitten elkaar in de weg, om drie redenen. - **Belasting:** een zwaar rapport vertraagt de applicatie waar je collega's op dat moment in werken. Hoe groter de dataset, hoe merkbaarder. - **Vorm:** een applicatiedatabase is opgeknipt in veel kleine tabellen om dubbele gegevens te voorkomen. Voor een rapport moet je er daarvan soms tien aan elkaar knopen. Dat is foutgevoelig en voor niet-ontwikkelaars nauwelijks te doen. - **Historie:** een applicatie bewaart de huidige stand. Verhuist een klant naar een andere regio, dan staat hij daarna in die regio, ook voor de omzet van vorig jaar. Wil je weten hoe het toen was, dan moet iemand dat apart vastleggen. Daar komt bij dat je bij standaardpakketten vaak helemaal niet bij de database kunt. Een boekhoudpakket in de cloud biedt een API, en die kent limieten op het aantal verzoeken. Daar kun je geen dashboard live op laten draaien dat bij elke klik honderden verzoeken doet. Je moet de data dus hoe dan ook eerst ophalen en ergens neerzetten. Die "ergens" is het begin van je datawarehouse. > Een datawarehouse is geen product dat je koopt. Het is de afspraak dat rapportages hun data van één plek halen, en niet elk voor zich uit de bron. ## De vier treden: van kopie tot dataplatform Tussen "Power BI rechtstreeks op de productiedatabase" en "een dataplatform in de cloud" zitten meer stappen dan de meeste verkooppraatjes laten zien. Het helpt om ze als een trap te zien. Je neemt de volgende trede pas als de huidige knelt. ### Trede 1: een leeskopie van je database Heb je één eigen applicatie en is belasting het enige probleem, dan is een leeskopie de eenvoudigste oplossing. PostgreSQL kan een tweede server continu laten meelopen met de hoofdserver. Op zo'n [hot standby](https://www.postgresql.org/docs/current/hot-standby.html) kun je alleen lezen, en dat is precies de bedoeling: rapporten draaien daar, de applicatie merkt er niets van. De kopie loopt een fractie achter op het origineel, wat voor rapportage zelden een bezwaar is. Dit lost de belasting op, maar niet de vorm en niet de historie. Je kijkt nog steeds naar tabellen die voor de applicatie zijn ontworpen. ### Trede 2: voorberekende overzichten De volgende stap is rapportagetabellen maken die al de vorm hebben waarin je wilt kijken. In PostgreSQL doe je dat met een [materialized view](https://www.postgresql.org/docs/current/rules-materializedviews.html): je schrijft de query één keer, de database slaat de uitkomst op als tabel, en je ververst die volgens een schema. De documentatie zegt het zelf treffend: toegang is veel sneller, maar de gegevens zijn niet altijd actueel, en vaak is dat ook niet nodig. Voor veel bedrijven met één kernapplicatie is dit al genoeg. De omzet per maand, de openstaande orders per regio, de doorlooptijd per team: het staat klaar als kant-en-klare tabel waar een dashboard of een Excel-koppeling op kan aansluiten. ### Trede 3: een aparte rapportagedatabase Zodra er een tweede bron bij komt, heb je een neutrale plek nodig. Dat is een aparte PostgreSQL-database waarin een nachtelijk proces de data uit je applicatie, je boekhoudpakket en je CRM neerzet, opschoont en aan elkaar knoopt. Functioneel is dit een datawarehouse. Technisch is het gewoon een database die je al kent, op een server die je al kunt beheren. Dit is de trede waar de meeste MKB-bedrijven jarenlang goed op zitten. PostgreSQL kan flink wat aan; de grens ligt in de praktijk eerder bij het aantal bronnen en mensen dan bij de hoeveelheid data. ### Trede 4: een cloud-datawarehouse Platformen als BigQuery en Snowflake zijn van de grond af gebouwd voor grote leesvragen. Ze slaan data per kolom op in plaats van per rij, zodat een vraag over drie kolommen de andere veertig niet hoeft te lezen. En ze scheiden opslag van rekenkracht, zodat je het ene kunt laten groeien zonder het andere. Meer daarover verderop. ## Hoe de data erin komt: ETL, ELT en waarom de volgorde uitmaakt Welke trede je ook kiest, er moet een proces zijn dat de data ophaalt en klaarzet. Daarvoor bestaan twee volgordes. - **ETL (extract, transform, load):** je haalt data op, bewerkt die onderweg, en laadt alleen het eindresultaat in. De ruwe data bewaar je niet. - **ELT (extract, load, transform):** je laadt de ruwe data eerst ongewijzigd in, en doet de bewerking daarna in de database, met SQL. ELT is tegenwoordig de gangbare keuze, en om een praktische reden. Rekenregels veranderen. De directie besluit dat creditnota's voortaan in de maand van de oorspronkelijke factuur tellen, of dat een bepaalde productgroep anders wordt ingedeeld. Heb je de ruwe data bewaard, dan pas je de query aan en reken je alles opnieuw door. Heb je alleen het bewerkte resultaat, dan moet je terug naar de bron, en die geeft niet altijd meer wat hij drie jaar geleden gaf. In de praktijk levert dat drie lagen op in je rapportagedatabase. 1. **Ruw:** een een-op-een kopie van wat de bron aanleverde, met het moment van ophalen erbij. Hier verander je niets. 2. **Opgeschoond:** dezelfde gegevens met consistente namen, datumnotaties en sleutels. Hier leg je vast dat klant 1042 in het CRM dezelfde is als debiteur 30517 in de boekhouding. 3. **Rapportage:** de tabellen waar dashboards op aansluiten, in de vorm waarin mensen denken: omzet per klant per maand, uren per project per week. Voor het beheren van die bewerkingsstappen is [dbt](https://docs.getdbt.com/docs/introduction) de bekendste tool: je schrijft de bewerkingen als gewone SQL-queries, en dbt zorgt dat ze in de juiste volgorde draaien, getest worden en in versiebeheer staan. Dat laatste is belangrijker dan het klinkt. Een rekenregel die in een Git-geschiedenis staat, kun je uitleggen aan je accountant. Een rekenregel die in een dashboardformule verstopt zit niet. ### Feiten en dimensies Voor de rapportagelaag bestaat een beproefde indeling die je in vrijwel elk datawarehouse terugziet: het sterschema. [De Kimball Group omschrijft het](https://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/star-schema-olap-cube/) als feitentabellen die via sleutels aan dimensietabellen hangen. Een feit is iets wat gebeurde en wat je kunt tellen: een orderregel, een geboekt uur, een betaling. Een dimensie is de context eromheen: wie, wat, waar, wanneer. Je hoeft daar geen theorie van te maken. Het komt neer op één vraag per tabel: tel ik hierin, of filter en groepeer ik hierop? Houd die twee uit elkaar en je rapportages blijven begrijpelijk, ook voor iemand die het model niet zelf heeft gebouwd. ## Waar Power BI past, en waar niet Power BI wordt vaak gezien als het datawarehouse zelf. Dat is begrijpelijk: je kunt er bronnen mee koppelen, data mee bewerken en modellen in bouwen. Maar het is in de kern de laag waarin je kijkt. Power BI kent twee manieren om aan data te komen. In de importmodus laadt het een kopie van de data in en ververst die volgens een schema. Volgens [de documentatie van Microsoft](https://learn.microsoft.com/en-us/power-bi/connect-data/service-dataset-modes-understand) kan dat op gedeelde capaciteit acht keer per dag, en op een Premium-capaciteit 48 keer. In de DirectQuery-modus haalt het niets binnen en stuurt het bij elke klik een vraag naar de bron. Dat is actueler, maar het legt de belasting precies daar waar je hem niet wilt: op het systeem waarin gewerkt wordt. Zolang je één of twee bronnen hebt en de bewerkingen eenvoudig zijn, werkt importeren prima. Het gaat wringen in drie situaties. - **Dezelfde regel op meerdere plekken:** staat de definitie van omzet in een Power BI-bestand, dan geldt hij alleen in dat bestand. Het tweede rapport, de export voor de accountant en de AI-assistent die vragen over je cijfers beantwoordt, hebben er niets aan. - **Historie:** Power BI laadt wat de bron nu teruggeeft. Wil je weten in welke regio een klant vorig jaar zat, dan moet een tussenlaag die wijzigingen hebben vastgelegd. Microsoft schrijft zelf dat je daarvoor een tussensysteem zoals een datawarehouse nodig hebt. - **Volume en complexiteit:** in [de eigen richtlijn over sterschema's](https://learn.microsoft.com/en-us/power-bi/guidance/star-schema) raadt Microsoft aan om bij grote volumes of ingewikkelde bewerkingen eerst een datawarehouse met laadprocessen te bouwen en het Power BI-model daarop aan te sluiten. De gezonde verdeling is dus: de data woont in je rapportagedatabase, met de definities erbij. Power BI, een [dashboard op maat](https://coding.agency/kennisbank/dashboards-op-maat) of een export sluit daarop aan en laat zien wat er staat. Dan kun je de kijklaag later vervangen zonder je rekenregels kwijt te raken. ## BigQuery en Snowflake: wanneer loont de stap? Beide platformen doen in grote lijnen hetzelfde, met een andere insteek. **BigQuery** is het datawarehouse van Google Cloud. Er is geen server die je beheert of groter maakt; je laadt data in en stelt vragen. [BigQuery slaat tabellen per kolom op](https://docs.cloud.google.com/bigquery/docs/storage_overview) en scheidt opslag van rekenkracht, zodat beide los van elkaar kunnen groeien. Je kunt kiezen waar je data staat: er is [een regio in Nederland](https://docs.cloud.google.com/bigquery/docs/locations) (`europe-west4`) en een EU-brede locatie waarbij Google zelf bepaalt of de data in België of Nederland terechtkomt. **Snowflake** is een zelfstandige leverancier die bovenop de grote cloudaanbieders draait. [De architectuur bestaat uit drie lagen](https://docs.snowflake.com/en/user-guide/intro-key-concepts): opslag in een eigen gecomprimeerd kolomformaat, rekenkracht in zogeheten virtual warehouses, en een beheerlaag die het geheel aanstuurt. Elk virtual warehouse is een eigen rekencluster dat de andere niet beïnvloedt. Het financiële team en de data-analisten kunnen dus elk hun eigen rekenkracht krijgen op dezelfde data. Ook hier kies je [zelf de regio](https://docs.snowflake.com/en/user-guide/intro-regions), met Europese opties bij alle drie de grote cloudaanbieders. | Kenmerk | PostgreSQL | BigQuery | Snowflake | | Opslagvorm | Per rij | Per kolom | Per kolom | | Beheer | Eigen server of beheerde dienst | Geen servers | Rekenclusters die je aan- en uitzet | | Afrekenmodel | Vaste servercapaciteit | Per gelezen hoeveelheid data, of gereserveerde capaciteit | Per tijd dat een rekencluster draait | | Sterk in | Een handvol bronnen, bekende techniek, voorspelbare kosten | Grote volumes, wisselend gebruik, Google-omgeving | Veel teams naast elkaar, meerdere clouds | | Let op | Zware analysevragen worden traag bij groei | Een slordige query leest, en kost, meer dan nodig | Een cluster dat blijft draaien, blijft tellen | ### Het afrekenmodel verandert je gedrag Het grootste verschil met een eigen database zit niet in de techniek maar in de rekening. Bij PostgreSQL betaal je voor een server, of je hem nu gebruikt of niet. Bij een cloud-datawarehouse betaal je naar gebruik, en dat maakt elke query een kostenpost. Bij BigQuery geldt in het standaardmodel dat [je betaalt voor het aantal gelezen bytes](https://docs.cloud.google.com/bigquery/docs/best-practices-costs). Dat heeft een gevolg dat veel mensen verrast: een `LIMIT` aan het eind van je query maakt hem op een gewone tabel niet goedkoper. De documentatie is daar duidelijk over: je betaalt voor het lezen van alle bytes die de query aanwijst, ook als je maar tien rijen terugkrijgt. Wie gewend is om even `SELECT * … LIMIT 10` te doen om te zien wat er in een tabel zit, leert dat hier snel af. Dat is geen reden om deze platformen te mijden. Het is wel een reden om er pas aan te beginnen als iemand in de organisatie het verbruik in de gaten houdt. Hetzelfde patroon zie je bij [AI-tools die op verbruik afrekenen](https://coding.agency/kennisbank/meter-shock-ai-tools-kosten): het model is eerlijk, maar het straft onoplettendheid. ### Signalen dat je PostgreSQL ontgroeit - **Rapporten duren minuten:** ook na het toevoegen van indexen en voorberekende tabellen. - **De nachtelijke verversing haalt de ochtend niet:** het laadproces is nog bezig als de eerste collega's inloggen. - **Veel mensen stellen tegelijk zware vragen:** analisten zitten elkaar in de weg op dezelfde server. - **Er komen bronnen bij met heel veel regels:** klikgedrag, sensordata, logbestanden. Dat is een ander soort volume dan orders en facturen. Herken je er geen van, dan is trede 3 de juiste plek. En goed nieuws: wie zijn bewerkingen als SQL in lagen heeft opgezet, verhuist later zonder alles opnieuw te bedenken. De overstap is dan een migratie, geen herbouw. ## Persoonsgegevens: een datawarehouse is een nieuwe verwerking Een datawarehouse nodigt uit om alles mee te nemen, want je weet nooit wat je later wilt weten. Juist dat botst met de AVG. [Artikel 5 van de AVG](https://eur-lex.europa.eu/legal-content/NL/TXT/?uri=CELEX:32016R0679) eist dat je persoonsgegevens alleen verwerkt voor een vastgelegd doel dat past bij het doel waarvoor ze zijn verzameld, dat je niet meer verwerkt dan daarvoor nodig is, en dat je ze niet langer bewaart dan nodig. Voor je rapportagedatabase betekent dat een paar concrete keuzes. - **Laat weg wat een rapport niet nodig heeft:** voor omzet per regio heb je een postcodegebied nodig, geen naam, e-mailadres of telefoonnummer. - **Vervang namen door een sleutel:** in de rapportagelaag volstaat een klantnummer. Wie mag weten wie erachter zit, zoekt dat op in het bronsysteem. - **Neem verwijderingen mee:** wordt een klant in de bron verwijderd of geanonimiseerd, dan moet dat doorwerken in alle drie de lagen, ook in de ruwe. - **Regel toegang per laag:** de ruwe laag is voor wie het laadproces beheert, de rapportagelaag voor wie rapporten maakt. - **Kies bewust een locatie:** bij een cloudplatform bepaal je bij het aanmaken waar de data staat. Dat is achteraf lastig te veranderen. Meer over die afweging lees je in [hosting binnen de EU](https://coding.agency/kennisbank/aws-hosting-binnen-de-eu). ## Valkuilen die ik het vaakst zie - **Beginnen bij het platform:** eerst een dataplatform inrichten en dan pas bedenken welke vragen je wilt beantwoorden. Begin bij drie rapporten die iemand elke maand met de hand maakt. - **Geen eigenaar van definities:** techniek lost niet op dat verkoop en finance iets anders verstaan onder omzet. Dat is een besluit, geen query. - **Rekenregels in het dashboard:** elke formule die alleen in de kijklaag staat, bestaat de volgende keer in een iets andere versie ergens anders. - **Alleen het eindresultaat bewaren:** zonder ruwe laag kun je een fout in een bewerking niet met terugwerkende kracht herstellen. - **Een laadproces zonder bewaking:** een verversing die stilletjes mislukt, levert een dashboard op dat er prima uitziet en cijfers van vorige week toont. Laat elk rapport zien van wanneer de data is. - **Vastlopen in één leverancier:** bewerkingen die in een eigen formuletaal van een tool zijn geschreven, neem je niet mee. SQL wel. Zie ook [vendor lock-in bij low-code](https://coding.agency/kennisbank/low-code-nadelen-vendor-lock-in). ## Mijn kijk op datawarehouses in het MKB Ik heb nog nooit een rapportageproject zien mislukken omdat de database te klein was. Wel omdat niemand had vastgelegd wat een klant is. Telt een prospect met een offerte mee? Een vestiging van een bestaande klant? Een debiteur die drie jaar niets heeft besteld? Zolang die vragen open staan, levert elk platform dezelfde discussie op, alleen sneller. Daarom begin ik liever klein en saai. Een aparte PostgreSQL-database, een nachtelijke taak die ophaalt, een paar SQL-bestanden in versiebeheer die van ruw naar rapportage werken, en drie rapporten die iemand echt mist. Dat is overzichtelijk, en het dwingt de gesprekken af die ertoe doen. Blijkt het daarna te krap, dan weet je precies waarom, en kies je een platform op basis van een echt knelpunt in plaats van een architectuurplaat. Er is nog een reden om de definities in de database te leggen en niet in een dashboard. Steeds vaker wil je niet alleen kijken, maar ook vragen: een AI-assistent die antwoord geeft op "welke klanten bestelden dit kwartaal minder dan vorig jaar?" Zo'n assistent is precies zo betrouwbaar als de tabellen waar hij op aansluit. Een nette rapportagelaag met duidelijke namen is daarmee ook de beste voorbereiding op [praten met je data](https://coding.agency/kennisbank/praten-met-je-data-mcp-ai). > — Jasper ## Zo helpt Coding Agency hierbij Wij bouwen de laag tussen je systemen en je rapportages: koppelingen die data ophalen uit je applicatie, boekhoudpakket en CRM, een rapportagedatabase in lagen met de rekenregels in versiebeheer, bewaking op het laadproces en een [dashboard op maat](https://coding.agency/kennisbank/dashboards-op-maat) of een aansluiting voor Power BI erbovenop. Meestal op [PostgreSQL](https://coding.agency/kennisbank/postgresql-vs-mysql), omdat dat voor de meeste organisaties ruim volstaat, en zo opgezet dat een latere stap naar een cloud-datawarehouse een verhuizing is en geen herbouw. Maakt iemand bij jullie elke maand dezelfde rapportage met de hand, of liggen er twee omzetcijfers op tafel die niet gelijk zijn? Neem [contact](https://coding.agency/contact) op voor een vrijblijvend gesprek. ## Veelgestelde vragen Een gewone database is ingericht om je dagelijkse werk te verwerken: orders opslaan, facturen maken, voorraad bijwerken. Een datawarehouse is een aparte omgeving waarin je data uit meerdere systemen samenbrengt, opschoont en bewaart om er vragen over te stellen. De eerste is gebouwd voor veel kleine schrijfacties, de tweede voor grote leesvragen over lange periodes. Vaak niet in de zware vorm. Zolang je data uit een handvol systemen komt en in een gewone database past, volstaat een aparte rapportagedatabase in PostgreSQL met een nachtelijke verversing. Een platform als BigQuery of Snowflake wordt pas zinvol bij veel bronnen, grote volumes of veel gelijktijdige analisten. Dat kan, en voor een eerste rapport is dat prima. Het gaat wringen zodra je meerdere bronnen combineert, historie wilt bewaren of rekenregels op meerdere plekken nodig hebt. Microsoft raadt in dat geval zelf aan om eerst een datawarehouse met laadprocessen te bouwen en Power BI daarop aan te sluiten. Bij ETL haal je data op, bewerk je die onderweg en laad je het eindresultaat in. Bij ELT laad je de ruwe data eerst ongewijzigd in en doe je de bewerking daarna in de database zelf, meestal met SQL. ELT is tegenwoordig de gangbare keuze, omdat je de ruwe data bewaart en een rekenregel achteraf kunt aanpassen zonder alles opnieuw op te halen. Niet zomaar. Een datawarehouse is een nieuwe verwerking waarvoor dezelfde AVG-beginselen gelden: je hebt een doel nodig dat past bij het doel waarvoor de gegevens zijn verzameld, je neemt niet meer mee dan nodig is en je bewaart niet langer dan nodig. In de praktijk betekent dat: namen en contactgegevens weglaten of vervangen door een sleutel, tenzij een rapport ze echt nodig heeft. Gerelateerde expertise — Maatwerk Software **Maatwerk software laten maken?** Bekijk onze aanpak, werkwijze en referentieprojecten. Vanaf € 3.000, 16+ jaar ervaring, 150+ projecten opgeleverd. [ Bekijk onze aanpak ](https://coding.agency/expertises/maatwerk-software-laten-maken) [ Gratis prijsindicatie ](https://coding.agency/prijsindicatie) Onderwerpen Datawarehouse PostgreSQL BigQuery Snowflake Power BI ETL Rapportage MKB ## Gerelateerde artikelen [ 14 feb. 2026 Webapplicaties ### Dashboard op maat laten bouwen — Kosten, voordelen & aanpak Waarom standaard rapportagetools tekortschieten en hoe een dashboard op maat je de inzichten geeft die je organisatie echt nodig heeft. ](https://coding.agency/kennisbank/dashboards-op-maat) [ 1 aug. 2024 Hosting ### PostgreSQL vs MySQL Welke database past bij jouw project? De technische afweging en praktische gevolgen van deze keuze. ](https://coding.agency/kennisbank/postgresql-vs-mysql) [ 18 mei 2026 AI ### Praten met je data: hoe MCP en AI je bedrijfsdata toegankelijk maken Dankzij Model Context Protocol kun je in natuurlijke taal vragen stellen aan je CRM, ERP, database of spreadsheet — en krijg je antwoord zon... ](https://coding.agency/kennisbank/praten-met-je-data-mcp-ai) ## Hulp nodig? Vragen over dit onderwerp? Laten we het erover hebben. [ Neem contact op ](https://coding.agency/contact) --- *Bron: [Coding Agency](https://coding.agency/kennisbank/datawarehouse-mkb-postgresql-bigquery-snowflake)*