Akvorado turns sampled flow records into operational network memory

Summary

• Akvorado is an active open-source flow-analysis project started by Vincent Bernat, supported in Free’s operational environment and developed by a public community of contributors, not an independent company.
• The 2.x architecture separates UDP intake, transport through Kafka, enrichment and storage in ClickHouse, allowing each stage to scale independently without remedying loss before ingestion or poor source data.
• The platform’s value emerges when it turns addresses, interface indexes and counters into context for peering, capacity and incident investigation, but the results remain dependent on metadata, classifiers and timing.

A maintenance release reveals a broader redesign

On 14 July 2026, Akvorado’s maintainers released version 2.4.1. The release itself was an ordinary sign of continued maintenance. The more important fact lay behind it: the current generation no longer asks one tightly coupled collector to receive every flow export, decode and enrich it, then push it directly into the analytical store. Akvorado 2.0 divided that journey into independent operational units: the inlet receives datagrams, Apache Kafka carries a compact representation, outlet processes add context, and ClickHouse retains the result for search and aggregation.

This architecture offers a practical answer to a familiar operator problem. A large network can produce far more evidence about traffic than engineers can inspect packet by packet. Routers and switches can summarise what they see in NetFlow, IP Flow Information Export, or IPFIX, and sFlow records. These exports retain enough information to answer many questions about volume, direction, interfaces and connected parties without preserving every application payload. Akvorado gathers this evidence, attaches network meaning to it, then makes its history available through a web interface and filtering language.

The apparent simplicity of the diagram conceals a chain of decisions. The exporting device chooses which packets or flows will be represented. Sampling may exclude short connections. UDP datagrams can be lost before the collector records them. Templates may change, or interface identifiers may be reused. A routing feed may describe a path that changed after the traffic passed. An autonomous-system or geolocation database may misclassify an address. A human-written rule may label traffic as customer, peer or transit even though that attribute never existed inside the packet.

Akvorado matters because it exposes much of this chain in open source code rather than presenting the chart as an opaque result from a closed appliance. The project gives operators control over collection, retention, enrichment, querying and access. It also makes them responsible for weaknesses in every component they choose. The governing question is therefore practical rather than promotional: how far can a self-hosted flow system turn partial exports into trustworthy operational memory without a polished dashboard outrunning what the evidence proves?

The answer depends on the task. In capacity planning, a sample-based trend may be useful even when it is not an exact packet count. In peering, broad traffic direction and autonomous-system context may show where demand is moving. During an incident, a historical record may narrow the time, interface and counterpart involved. None of these uses requires exhaustive packet-level knowledge, but each requires the operator to know what the record represents, what it omits and how later enrichment changed its meaning.

Flow records exist because storing every packet is too expensive

Full packet capture can retain headers, ordering and sometimes payload at a level that permits detailed forensic reconstruction. It also creates enormous storage, access-control and privacy burdens on busy links. Flow measurement accepts a different trade-off. The exporter aggregates or samples traffic, then exports records containing selected fields such as source and destination addresses, ports, protocol, counters, timestamps and ingress or egress interfaces. The result is smaller, easier to retain and better suited to long-term aggregation, but it is no longer a literal replay of the packets that crossed the network.

NetFlow and IPFIX usually describe conversations through flow records created when a cached entry expires or a flow ends. IPFIX defines a formal structure involving exporters, collectors, templates and data records. The collector needs the template to interpret later values; a field’s position alone does not carry a fixed meaning. Vendor-specific elements and differing cache policies may cause two devices to describe similar traffic in non-identical ways. Akvorado’s decoders therefore sit at the boundary between a family of standards and the reality of their implementation in devices.

sFlow usually approaches the problem through packet and counter sampling. The device selects packets at a configured rate, exports information about the sample and can report interface statistics. At sufficiently large volumes, samples reveal broad patterns without requiring the hardware or collector to process every packet as a separate event. The cost appears at the edges: a short flow may never be selected, a sudden burst may be under-represented, and every estimated value needs its sampling rate and denominator before it can be read responsibly.

This distinction matters because the word “flow” does not refer to one homogeneous kind of evidence. A sampled packet header, an aggregated conversation record and an interface counter answer different questions. They can reinforce one another, but they should not be merged into a single claim of absolute precision. Akvorado can store and display the fields that reach it; it cannot force an exporter to reveal packets that were not selected or fields that were never sent.

Long retention is the central operational attraction. An interface counter can show that a link carried more traffic at a particular moment, but it does not usually identify the networks or services involved. Packet capture may answer that question in detail, yet many operators cannot retain it for weeks or months on every high-capacity link. Flow records occupy the middle ground. They preserve enough dimensions to revisit an event later, provided that sampling and export policies remain known.

Because of this intermediate position, flow analytics belongs to the infrastructure layer rather than serving as marginal dashboard decoration. The collector is part of a system that produces evidence. Its output can guide procurement, peering changes, traffic engineering and investigations. Decisions with those consequences need a documented path from device configuration to query result.

The exporter determines what Akvorado can know

Akvorado’s first dependency lies outside its repository. Routers and switches determine whether flow export is enabled, which interfaces participate, how records are defined, when cached entries expire, the sampling rate and which fields appear. Hardware forwarding paths may expose different levels of detail. An operator can deploy a flawless collector and still receive a partial account because source devices were configured inconsistently or could not export the required evidence.

Template handling is a point of fragility. IPFIX and several NetFlow versions use templates so the exporter can define the structure of later records. If the collector misses a template, receives data before the related definition or encounters a changed enterprise field, it may be unable to decode the record correctly. In some cases it can request or wait for a fresh template, but measurements lost during the gap do not return automatically. Safe practice treats template state as a monitored dependency, not an invisible protocol conduit.

Sequence information can reveal some gaps. An exporter may number datagrams or records, allowing the collector to notice a reset or interruption. This is a diagnostic signal, not recovery. A missing number proves that evidence has a gap, but it does not reconstruct the missing traffic. An exporter restart, loss along the path, a full socket buffer or host scheduling can produce similar symptoms, so a loss counter begins an investigation rather than naming the cause.

Sampling adds another kind of uncertainty. One packet in several thousand may be enough to estimate large, sustained traffic for some planning tasks while offering almost no confidence about a rare connection. The error is not a fixed percentage that applies everywhere; it depends on the distribution of flows, the sampling method, the time window and the question itself. A chart of overall transit trends and a security judgement about one short connection require different standards of evidence.

Calibration keeps this ambiguity visible. Teams can compare byte totals estimated from flow records with interface counters for the same period. A persistent difference may point to sampling assumptions, export coverage, packet loss or classification error. The two sources measure through different mechanisms, so exact agreement is not expected; the comparison instead reveals whether the flow system is stable enough for its purpose.

This is the first limit on Akvorado’s authority. The project can decode, enrich and query only what actually arrives. It does not control the measuring instrument at the observation point. If the operator treats exporter configuration as another team’s problem, every later analysis is built on an unknown denominator.

Vincent Bernat designed the project around operators’ real questions

Akvorado emerged around 2019 from genuine flow-analysis needs. Public articles and code history identify network engineer Vincent Bernat as the principal initiator and most prominent overall maintainer. The software is also closely associated with the operational environment of the French ISP Free, which supplied production context and significant support. The evidence does not, however, support describing Akvorado as a commercial product owned by Free, an independent company or a service that Free runs for every user.

This distinction helps explain the nature of the project. Its public materials focus on problems operators recognise: receiving multiple flow formats, translating interface indexes, adding autonomous-system and routing context, distinguishing peering from transit, retaining wide datasets and allowing engineers to ask specific questions. The interface is useful because it sits above the operator’s own data model, not because it displays a generic collection of colourful charts.

The early chronology is less complete than the current architecture. Repository history points to sustained development in the early 2020s, with collection, classification and web exploration maturing before the 2.0 redesign. In 2023, Vincent Bernat publicly explained the SQL-like filtering language and dynamic Protocol Buffers, and releases continued in 2024. There is no public count of the first production deployments, a precise starting date or user growth. The account should preserve those gaps rather than invent a founding legend.

Free’s most important role is providing an operational environment. A high-traffic ISP exposes problems that laboratory demonstrations do not: bursts of UDP exports, huge numbers of interfaces, great address diversity, constantly changing routes and a need to connect traffic volume with commercial relationships. That context influences design priorities, but it does not prove that every feature is implemented in the same way inside Free, that the company funds every contributor or that it controls the project’s future.

The public repository gives external operators another route to trust. They can inspect the code, issues, release notes and configuration documentation, run the system in their own environment, keep sensitive metadata under their control and modify the software under the terms of the GNU Affero General Public License version 3. Transparency does not replace support, however. An organisation still needs people who understand exporters, Kafka, ClickHouse, routing data and the consequences of upgrades.

Akvorado’s origin therefore creates the central tension rather than resolving it. Software driven by operator needs may embody the right questions more precisely than a general analytical product. It may also carry the risk of concentration in a small maintainer community and the operational assumptions of the environments that shaped it.

Version 2.0 separated intake from interpretation

The appeal of a single integrated collector is easy to understand. One process, or one tightly connected system, receives records, decodes and enriches them, then writes them to storage. The deployment is easier to explain and has fewer moving parts. The weakness appears when input and analysis no longer proceed at the same speed. A burst of UDP datagrams does not wait for a stalled database merge to finish or for an external metadata query to recover. If the receiving path becomes blocked, the oldest evidence may be lost at the entrance, where it is hardest to replace.

Akvorado 2.0 separated these responsibilities. The inlet focuses on receiving flow datagrams and publishing an encoded, compact representation to Kafka. Outlet processes consume the stream, decode records, add metadata, apply classifiers and insert batches into ClickHouse. Reception capacity, enrichment capacity and database throughput can then be scaled as related but independent problems.

The separation changes failure behaviour. Temporary slowness in ClickHouse no longer has to stop a UDP listener immediately; Kafka can carry a backlog within the limits of its retention and available storage. More outlet processes can be added when enrichment falls behind. Partitions distribute the work, while the inlet remains small enough to focus on sockets and exporter state.

The design also provides clearer operational language. Engineers can separately ask whether datagrams reached the inlet, whether it published them, whether consumers caught up, whether enrichment succeeded and whether ClickHouse accepted the batch. A monolithic service may hide all those stages behind one health indicator. Separate components make the hand-offs visible, provided that the deployment collects and retains the necessary measurements.

Additional components mean additional ways to fail. Kafka brokers need capacity, replication choices, a retention policy and maintenance. Consumer lag may grow silently. Partitions affect distribution and ordering. Outlet results may differ if their data definitions or enrichment settings diverge. ClickHouse may remain able to answer old queries while fresh data waits elsewhere. The 2.0 architecture improves control by exposing the processing path, but it does not make that path self-managing.

Migration is another boundary. A redesign that changes message representation, service roles and storage behaviour creates compatibility and operational work for existing users. The release record shows active maintenance through version 2.4.1, but it does not provide an independent count of how many users moved from earlier versions, how long migrations took or what kinds of failure appeared at the largest scales.

The best way to understand the 2.0 change is as a distribution of responsibility. The inlet protects the moment of arrival. Kafka absorbs differences in pace after publication. The outlet turns raw records into the structure Akvorado expects. ClickHouse retains the analytical history. Each stage can be improved and tested separately, and each leaves a specific kind of gap when it fails.

Kafka absorbs processing delays after data arrives

Kafka is the hinge in Akvorado’s current architecture because it turns a burst-sensitive receiving path into a stream that later processes can handle at a different pace. Messages are placed into topics and partitions, retained for a configured period and then consumed by outlet processes. This intermediate store prevents slow enrichment or expensive storage work from feeding directly back into the socket facing the exporter.

The time boundary is precise. Kafka can protect data only after the inlet receives and publishes it. A datagram dropped in the network, discarded by the exporter, lost in a full socket buffer or rejected before publication never enters the stream that Kafka buffers. Calling the path “lossless” merely because Kafka is present erases its weakest section.

Even after publication, durability depends on choices. Replication across brokers, acknowledgements, disk capacity, retention and recovery determine how much protection the queue provides. Short retention can turn a long ClickHouse outage into data loss. Partitioning that concentrates the heaviest exporters can create uneven lag. A broker failure during a period of weak replication may also remove records that the inlet had already accepted.

Ordering requires care as well. Kafka guarantees order within one partition, not a total order across every partition in the cluster. Flow analysis often cares more about bounded timestamps and aggregation windows than a single universal order, but template state, exporter sequencing and enrichment updates may still depend on how records relate to one another. The operator needs to understand the outlet’s ordering assumptions and how restarts or rebalancing affect them.

Consumer lag is the most important operational signal because it translates the architecture into time. A queue containing ten million records means little without arrival and processing rates. Lag measured in seconds or minutes shows how far analytical visibility trails the network. When a capacity or incident team believes it is looking at current traffic, that lag becomes part of the evidence and should appear in the service’s own health model.

Kafka also changes the skills required to operate Akvorado. A small network team that once managed a collector and database now operates a distributed messaging system. Capacity and flexibility may justify the additional burden, but it remains a cost borne by the operator rather than a free property of open software.

The accurate claim is narrow and useful: Kafka reduces coupling between reception and later work and provides room to survive a temporary imbalance. It does not recover records lost before the inlet, guarantee the durability of every deployment or remove the need to monitor the queue as production infrastructure.

ClickHouse makes long traffic history queryable

Flow measurements suit a column-oriented database because many questions scan a small number of fields across an enormous number of rows. A peering engineer may aggregate bytes by destination autonomous system and time. A capacity planner may compare interfaces or sites across weeks. An incident responder may filter a small set of addresses and ports within a short interval. Columnar storage reads the relevant columns, compresses repeated values and aggregates without rebuilding every complete record for every query.

Akvorado inserts data into ClickHouse in batches and organises it for time-bounded analytical work. Derived or precomputed fields may make common dimensions easier to query. The database provides the persistence that turns transient exports into memory: an engineer can revisit a traffic shift after device counters have moved beyond that moment and the original routing state has changed.

This memory has a physical cost. Addresses, ports, metadata and high-cardinality labels consume space and affect compression. Partitions, sorting keys and merge behaviour determine query time and insertion stability. Retention policies also decide whether the system preserves days, months or longer. A deployment that retains every available dimension indefinitely may exhaust its disks or spend more on storage than its questions justify.

Background work in ClickHouse matters because new data and historical queries compete for the same system. Merging, compression and replication can consume input and output capacity while outlet processes write fresh batches. The database may remain technically available while falling behind operationally. Disk pressure may first appear as slower merges, then delayed insertion and finally an absence of recent evidence from the user’s perspective.

Query design can create a similar illusion. A fast chart may rely on precomputed or derived fields whose meaning differs from the original record. A broad query across a very high-cardinality dimension may require an expensive scan. Operators need query limits and monitoring, as well as a clear distinction between full-fidelity data and any aggregation or retention rules applied in the deployment.

The SQL-like filtering language helps users avoid direct database syntax, but it does not remove the underlying data model. Fields must exist, retain a stable meaning and be organised or indexed appropriately for the task. Changes to the data model may add dimensions while also creating migration and compatibility work. Dynamic Protocol Buffers make the transport representation more flexible, but ClickHouse still needs a coherent analytical structure at the other end.

ClickHouse is therefore more than a hidden dependency beneath the web interface. It is part of the product’s operational contract. Storage health, merge performance, query time and retention policy determine whether Akvorado can answer an operator’s question when it becomes important.

Enrichment turns interface indexes into a business map

A raw record may say that traffic entered through interface 287 and left through interface 914. Those numbers have meaning for the exporting device, but they do not tell the engineer whether the path used a customer port, private interconnection, transit supplier, backbone link or maintenance interface. Akvorado enriches records so queries can be expressed in the language of the network rather than the language of the exporter.

Polling through Simple Network Management Protocol, or SNMP, is one source of this context. Akvorado can cache interface names, descriptions, speeds and addresses, turning numerical indexes into intelligible links. This makes a chart useful for capacity review or incident investigation. It also creates a temporal problem: an index may be reused, a description may change and polling may fail. A record created on Monday could be displayed with metadata collected later unless the application preserves the historical relationship carefully.

Address and autonomous-system databases add another layer. They can connect an IP prefix with an organisation, autonomous system or location, allowing a peering team to aggregate traffic by network and geography. They are useful references, not complete ownership records. Prefix origins change, organisations merge, anycast complicates geolocation, and commercial datasets use methods that may conflict. A label should retain enough provenance for an analyst to challenge it.

Border Gateway Protocol context connects traffic to the control plane. Akvorado’s current architecture supports routing information, including data through BGP Monitoring Protocol, or BMP. Prefix, peer and next-hop information helps explain the apparent path and the relationship that may have carried the traffic. The strongest limitation is time: a routing snapshot collected after the flow may not describe the path selected when the packets crossed the network.

Enrichment therefore creates value and new kinds of evidence. Device data describes local interfaces. Routing data describes control-plane state. IP and ASN databases supply external associations. Geolocation data estimates place. None should be treated as an intrinsic property of the packet. Akvorado combines them so the operator can ask better questions, but the result inherits the timing and error model of every source.

This distinction becomes especially important when an organisation uses the same data for technical and commercial work. An outdated interface description may be merely inconvenient during diagnosis. The same error can place traffic in the wrong customer or transit category, affecting settlement, investment or sales. Through enrichment, the collector becomes an operational system, and an innocent metadata mistake can become an organisational fact.

With classification, technical records become commercial evidence

Networks do not place a “peer”, “customer” or “transit” bit in every packet. These categories come from contracts, routing relationships, interface design and operator policy. Akvorado classifiers can combine interfaces, autonomous systems, prefixes, BGP communities and other data to give traffic commercially meaningful labels.

The value appears immediately. A total utilisation chart may show that a link is filling, but not whether growth comes from paying customers, settlement-free peers, upstream transit or internal backbone traffic. Classification separates those flows and allows teams to ask which relationship is driving the change. Peering teams can look for candidates whose volume has grown, while capacity planners can decide whether a new port, path or circuit is justified.

A classifier is also a policy document written in code. A rule that assigns an interface to the “customer” category records an assumption about how the network is organised. A prefix list may encode a commercial boundary. A BGP community may stand in for a contractual category. When inputs change but rules do not, the dashboard can retain an accurate appearance while its meaning drifts.

Review should match the consequence. Classifiers used for internal exploration may be tested informally. Those supporting capacity budgets, partner negotiations or billing-adjacent analysis need change control, peer review and calibration against independent data. A small edit may reclassify months of history or change the apparent economics of a route.

Historical consistency is another problem. If a classifier changes today, do old records retain the label that applied when they were collected, or are they reinterpreted under the new policy? Both approaches are useful. The first preserves what the organisation believed at the time; the second allows comparable reporting under the current definition. The system and analyst must know which one a chart represents.

Akvorado makes such decisions visible enough to manage because the rules and data remain under the operator’s control. It does not choose the correct commercial ontology for the network. The most important review of a dashboard may occur outside the interface, when engineering, peering and finance teams agree on what the categories mean.

A SQL-like language shortens the distance between data and operator

A flow database is useful only if engineers can ask questions quickly enough to affect operations. Direct SQL offers great power, but it exposes storage details and can produce dangerous or expensive queries. Akvorado’s SQL-like language gives users familiar conditions, groupings and operators, then maps them onto the project’s own query model.

The language matters because operational questions are iterative. An engineer may begin with one interface, then narrow the result by autonomous system, address family, protocol, port or direction. A peering analyst may compare a network before and after a routing change. An incident responder may move from an aggregate spike to a short list of counterparts. When the query interface keeps these steps close to domain language, the time between suspicion and evidence falls.

Abstraction has a limit. A field can be queried only if it exists in the data and has been populated correctly. A convenient alias may conceal whether a value came from the exporter or an enrichment database. Group membership may be fast or expensive depending on its implementation. The language shields users from part of the database’s complexity, but it does not make a poorly defined field precise.

Evolution of the data model was one reason Vincent Bernat documented the use of dynamic Protocol Buffers in 2023. Flow formats and enrichments change, and a fixed, compiled definition may force all producers and consumers to move together. A dynamic representation allows new fields to be carried more flexibly while keeping inlet messages compact. Compatibility rules, field numbers and meanings still require discipline, especially while older consumers or stored records remain in service.

The web interface completes the path by turning filters into tables and charts. Visualisation helps because people detect shifts, periodicity and outliers faster than they can read raw rows. It can also create false confidence. A smooth line may rest on sampled traffic, a delayed queue and an updated classifier. The design should expose the relevant time window, aggregation and evidence limits rather than hiding them behind the presentation.

A good query layer performs two jobs. It makes complex data accessible and preserves enough of the model for the operator to review the answer. Akvorado’s open implementation gives teams an opportunity to inspect that path. Whether they actually do so is a matter of operational culture, not the software licence.

Classification gives traffic volume its commercial meaning

Flow analysis justifies its place inside the network when it changes a decision. Capacity planning is one of the clearest examples. Interface counters can show utilisation, but flow history can divide demand by destination network, region, protocol, customer category or other dimensions. Those details can help an operator decide whether to upgrade an existing link, add a peering session, move traffic or investigate a sudden change.

The decision remains conditional on the evidence chain. A sampled dataset may represent large, sustained flows well while missing many short ones. An incomplete set of exporters may make part of the network look quieter than it is. A classifier can assign the wrong relationship. A later routing change may confuse interpretation if the relevant control-plane state was not preserved. The value of data in planning comes from consistent measurement over time, not from treating one number as billing-grade truth.

Peering analysis illustrates the difference between technical reach and commercial meaning. An autonomous system that appears frequently in destination data may be a candidate for direct interconnection, but traffic volume alone does not prove mutual benefit or determine location, port availability, policy or contract terms. Akvorado can reveal a pattern worth examining. The peering decision remains with operators who understand routes, cost, resilience and the other party’s willingness.

Capacity forecasting has a similar limit. Historical growth can guide investment, but new application launches, customer losses, caching changes and routing events may alter the pattern. A long retention window helps teams see seasonality and structural shifts. It does not make the future an inevitable extension of the past. Data is used more responsibly when it defines scenarios and thresholds rather than one categorical forecast.

Flow history can also test whether an intervention worked. After a routing-policy change, engineers can compare traffic distribution before and after the event. If transit-link traffic falls while peer traffic rises, the result is consistent with the intended shift. BGP records and interface counters can strengthen that interpretation. None of these signals alone proves that every packet followed the intended path or that the user experience improved.

It is easy both to overstate and understate Akvorado’s value here. It does not automate the commercial decision. It gives the network a durable, queryable record of observations around which the decision can be debated. In organisations where peering and capacity knowledge remains spread across spreadsheets, temporary scripts and individual memory, that shared record can become infrastructure in its own right.

Flow history narrows an incident without proving its cause

The first operational benefit of retained flow data during an incident is time. Engineers can ask when the traffic pattern changed, which interfaces participated, which endpoints or autonomous systems dominated and whether the event is still continuing. These questions can narrow a general report of an outage or congestion to a smaller set of systems and relationships.

The evidence becomes stronger when combined. Interface counters can confirm the scale of a change on a link. BGP or BMP records may show a control-plane event. Device logs may reveal a restart or policy update. Packet capture can provide detail for a short interval. Endpoint monitoring may show whether the application failed. Akvorado’s flow history connects these sources through time and network identity, but it does not replace them.

A large traffic spike does not automatically mean an attack. It may be a popular release, backup, cache failure, routing change or measurement error. Flow metadata can show sources, destinations, ports and volume, but it usually lacks application payload and endpoint state. Security teams can use it to identify candidates for blocking or deeper investigation. Attribution and intent require additional evidence.

A calm chart can also mislead. If an exporter stops, disappearing records may look like recovery. If Kafka lag increases, the interface may display an old state. If a classifier changes, traffic may move between categories without moving on the wire. Incident procedures should explicitly check data freshness, exporter health, sequence gaps and end-to-end processing delay before interpreting the traffic.

Retention provides an advantage after the immediate pressure has passed. Teams can reconstruct the minutes before an alert, compare the event with earlier baselines and test competing explanations. This becomes more valuable after the original device state has been overwritten. A post-incident review may also reveal weaknesses in the evidence system itself: missing interfaces, outdated SNMP descriptions, limited public evidence sampling or a retention window that ended too soon.

The precise description of Akvorado’s incident role is that it “supports investigation”. It can make a failure intelligible and reduce the search space. The chart nevertheless remains an observation that passed through exporters and metadata, not a causal judgement.

An IPv6-first case shows portability and the limits of one example

On 9 April 2026, the APNIC Blog published an operational article about configuring Akvorado for an IPv6-first network. The case is useful because it comes from outside the project’s primary narrative and places the software in a specific deployment context. It shows that the system can be adapted to an environment in which IPv6 is central rather than a later addition.

The weight of one case remains limited. It does not establish the number of active Akvorado installations, its market share, IPv6 behaviour in every environment or its suitability for every operator. The devices, exporters, traffic profile, staff expertise and retention goals in that deployment may differ from those of a large carrier, enterprise or content network. A case study is evidence of use, not a comprehensive statistic.

Its broader importance lies in portability. Akvorado is distributed as open software rather than a service managed from one centre. An external team can install it, connect its exporters, define its classifiers and retain its own data. This separates the project from being merely an internal Free tool and gives the repository a life beyond the environment that helped shape it.

Portability also tests documentation. Adoption is easier when an operator can understand the roles of the inlet, Kafka, outlet and ClickHouse without private guidance. Public installation materials and a demonstration environment reduce the first barrier. They cannot anticipate every vendor-specific template, scaling problem or security policy. External case studies reveal where the documented model holds up when applied to a different network.

Additional independent deployment accounts would materially strengthen the evidence base. Useful reports should state exporter types, sampling rates, record volumes, retention periods, infrastructure costs, loss measurements, migration experience and the relationship between flow estimates and interface counters. They should also describe failures, because successful screenshots say little about how the system behaves under pressure.

The public record of Akvorado adoption is therefore credible but incomplete. Repository activity, releases and the APNIC-published case show a living project used beyond one maintainer’s immediate environment. They do not support a precise installation count or a claim that the system has become the default choice for flow analytics.

Self-hosting keeps sensitive metadata close

Flow records usually omit application payload, but they can reveal a great deal about relationships. Addresses, ports, timing, volumes and interfaces may show which systems communicated, how often and through which part of the network. Long retention turns these observations into behavioural history. For a carrier, enterprise or public body, the dataset may be operationally valuable and sensitive at the same time.

Akvorado’s self-hosted model allows an organisation to keep collection, Kafka, ClickHouse and the web interface inside infrastructure it controls. The operator can decide where data resides, how long it is retained, who may query it and which enrichment services are used. This is an important advantage for teams that cannot send detailed network measurements to an external service.

Local control is no stronger than local practice. The web interface, APIs, database credentials, Kafka access and underlying hosts all become part of the security boundary. A broad analytical role may reveal relationships beyond a user’s need. Backups and replicas can preserve data beyond the nominal retention period. Exporting query results may also move sensitive information into less controlled systems.

Retention needs a purpose. Capacity planning may work with aggregated history, while incident response may require more detailed records for a shorter period. One indefinite policy increases both investigative capability and the impact of a breach. Access tiers, aggregation, deletion and audit logs should follow the questions the organisation has decided it is entitled and prepared to answer.

Enrichment may increase privacy risk as much as operational value. Connecting an address to an organisation or location makes a record easier to understand and easier to misuse. An inaccurate association may also direct suspicion towards the wrong party. Analysts should be able to tell which fields came from the exporter, which came from internal metadata and which came from external databases.

The AGPLv3 gives users access to the code under its terms, but it does not design an organisation’s data governance. Self-hosting removes one supplier from the chain of custody. It does not remove the need for least privilege, secure maintenance, retention limits and clear accountability for who can turn traffic metadata into decisions.

The open licence leaves operating costs with operators

Akvorado does not require a traditional software licence fee when used under the terms of the AGPLv3. That may make the platform attractive to operators seeking control over cost, data and customisation. It does not make operation free. A production deployment consumes servers or virtual machines, storage, network capacity, staff time and on-call response.

Kafka and ClickHouse are substantial systems in their own right. Their capacity must be planned, upgrades tested and failures repaired. Exporter coverage needs continual maintenance as network devices and firmware change. SNMP credentials and metadata must be protected. Classifiers need review, and security updates must be applied. The largest cost may be the engineering time required to keep the evidence trustworthy.

Commercial platforms such as Kentik distribute these costs differently. A managed service can combine hosting, support, integrations and a broader product surface in one contract. ElastiFlow and other open or commercial systems offer different storage, licensing and support options. pmacct, ntopng, FastNetMon, general monitoring tools and packet systems solve adjacent parts of the problem. Comparisons should be based on operating model and evidence requirements, not a count of dashboard features.

A self-hosting operator retains more control over original records, the data model, retention period and query logic. It also carries the risk that a specialist leaves, a dependency changes or an upgrade fails. A managed-service customer transfers some infrastructure and support responsibility to a supplier in exchange for accepting dependencies on contract terms, data location, pricing and the product roadmap. Neither model removes supplier or system lock-in; each places it somewhere different.

The absence of a certified commercial support company for the project as a whole therefore matters. Consultancies may assist with individual deployments, but the reviewed evidence does not establish a single supplier that guarantees migration, security response or service levels across the entire project. An organisation adopting the system should decide whether it can operate independently, contract for expertise or contribute enough upstream to reduce its support risk.

Total cost also depends on the value of retained history. A smaller network with modest flow volume may find the system economical on ordinary infrastructure. A large operator retaining detailed, high-cardinality records may face substantial storage and database costs. The useful denominator is not cost per server but the cost of producing evidence reliable enough to change an operational decision.

This economic boundary is easy to overlook because open projects do not publish revenue or valuation. Akvorado’s sustainability depends on maintainer work, Free’s operational support, outside contributions and each user’s willingness to operate the dependencies. The project can create substantial downstream value without a balance sheet that measures it.

A maintainer-led project can be transparent and concentrated at once

Vincent Bernat is the principal initiator and overall maintainer publicly associated with Akvorado. The repository records contributions from others, while releases, issues and merge requests make development visible. The reviewed materials did not identify a separate foundation, elected board, formal membership body or complete funding arrangement.

Repository-centred governance has genuine strengths. Decisions leave a public trace. Users can propose changes, inspect discussions and fork the code if they reject its direction. The licence and source availability provide a technical exit that a closed service does not. The project can also respond quickly when maintainers share a clear operational model.

The same structure concentrates practical authority. Maintainers decide which changes enter official releases, how compatibility is handled and which bugs receive priority. Expertise in the inlet, dynamic data definitions, classifiers and migration paths may be concentrated among a small number of people. Forking is legally possible but operationally expensive when the breakaway group lacks that knowledge.

Free’s support reduces some continuity risk by anchoring the project in a production environment. It also creates dependence on priorities that are not fully documented in public. If the company’s needs change, maintainers move to other roles or support declines, external users will need to know whether the broader contributor community can continue releases, security fixes and dependency upgrades.

Upstream projects add another layer of distributed control. Kafka and ClickHouse determine their own roadmaps. Hardware vendors change export behaviour. Standards bodies develop the work around IPFIX and BMP. External databases alter their data structures and licences. Akvorado can adapt, pin versions or replace components, but it cannot veto those decisions.

A mature governance account does not require Akvorado to become a large institution. It does require continuity to be understandable. A documented release policy, a broader maintainer group, a security process, compatibility commitments and a succession plan would tell operators what happens when current informal relationships come under pressure. These elements were not visible as a complete public framework at the end of the research.

The project’s openness should therefore be described precisely. The code and much of the decision path are public. Funding, allocation of time and succession are less clear. Transparency reduces dependence on trust, but it does not remove dependence on people.

The best dashboard is the one that reveals its denominator

Akvorado’s contribution does not lie in claiming to see the entire network. It lies in preserving selected observations and interrogating them long after the devices that produced them have changed. The project connects router exports, queuing, enrichment, storage and querying in a form that operators can inspect and run themselves.

Its strongest uses accept uncertainty rather than hiding it. Capacity teams can follow sustained trends while calibrating flow totals against counters. Peering teams can discover traffic relationships while reviewing classification rules. Incident responders can narrow time and scope while seeking evidence from routing, logs, packets and endpoints. Privacy teams can keep data local while restricting who reads it and how long it remains.

The main failure mode is epistemic before it is technical: a clean chart can make an unknown denominator look precise. Missing exporters, packet sampling, UDP loss, consumer lag, old interface data and later labels can all produce a convincing line. The system becomes safer when these conditions are measured alongside the traffic rather than treated as implementation details.

This is also the most useful test for Akvorado’s next stage. Release frequency after version 2.4.1 will show whether the 2.x architecture remains maintainable. Independent deployments can reveal migration cost, data loss, query performance and total operational burden. Better time-aware handling of routing and metadata may improve historical analysis. A broader security and governance process could also reduce continuity risk.

Success does not require Akvorado to replace every managed platform or become a global standard. It requires the project to remain good at the narrower task it chose: turning incomplete flow exports into honest, durable working memory. The decisive evidence will be whether operators can trace a line on the screen back to the devices, sampling, queues, metadata and rules that produced it.